Component · deploy/

deploy

The Kubernetes manifests that enforce the containment. These are the cluster-level guarantees the control plane relies on, plus the per-session objects it creates and reclaims for every run.

Role in the architecture#

The control plane provisions per-session objects at runtime, but the standing cluster posture — the gVisor runtime, the service account's permissions, the resource backstops — is declared here and applied with kustomize.

Source
deploy/kustomization.yaml · deploy/README.md (deploying on k3s) · plus docs/phase0-gvisor-k3s-runbook.md.

Standing manifests#

FieldTypeDescription
RuntimeClassgvisorDelegates pods to containerd's runsc handler — the syscall-intercepting sandbox runtime.
RBACleast-privilegeAn enclave-control-plane ServiceAccount with a namespace-scoped role that can manage only Jobs, pods, logs, configmaps, secrets, and networkpolicies.
NetworkPolicydefault-denyThe baseline egress posture for session pods.
LimitRangebackstopDefault + max CPU/memory caps as a safety net beneath per-session limits.
Deploymentcontrol-planeThe control-plane service itself, plus its namespace.

Per-session objects#

For each run, the Kubernetes backend creates a set of objects and reclaims all of them on teardown — no residue:

  • ConfigMap — the code blob.
  • Secret — only for a private-repo git source: the brokered git token, mounted via env secretKeyRef on the clone init-container only. No secret is placed in the workload container.
  • NetworkPolicydeny_all (empty egress) or an allowlist of CIDRs, with the metadata IP always excepted.
  • Job — the gVisor pod: non-root, all caps dropped, read-only rootfs, no service-account token.