Skip to content

feat(sandbox): add gVisor runtime adapter - #3367

Draft
drew wants to merge 2 commits into
3361-backend-neutral-confirmation/drewfrom
codex/gvisor-runtime-adapter
Draft

drew wants to merge 2 commits into
3361-backend-neutral-confirmation/drewfrom
codex/gvisor-runtime-adapter

Conversation

@drew

@drew drew commented Sep 16, 2026

Copy link
Copy Markdown
Collaborator

Summary

Add a gVisor adapter beneath the existing OpenShell Sandbox Protocol so Kubernetes sandboxes can run with GKE Sandbox on COS nodes without relying on Landlock or seccomp user notification. The native Linux adapter remains the default and retains its existing enforcement model.

This PR is intentionally a reduced-fidelity backend: gVisor provides the workload boundary, Kubernetes NetworkPolicy provides zero direct egress, and proxy-aware HTTP/HTTPS traffic is mediated through an authenticated reverse tunnel.

Related Issue

Related to #3361.

Stacked on #3366; review and merge that PR first.

Changes

  • Carry a native-linux or gvisor adapter choice through the protected runtime descriptor and bind confirmation evidence to the selected mechanism.
  • Reuse OpenShellRuntimeBackend and the authenticated Sandbox Protocol while adding an explicit HTTP/CONNECT proxy stream for gVisor.
  • Infer the adapter from an admitted Kubernetes Pod with runtimeClassName: gvisor, inject loopback proxy environment variables, and omit the seccomp profile and unprivileged-port sysctl that GKE Sandbox does not support.
  • Use endpoint-only policy evaluation for gVisor because transparent TCP interception and trusted per-binary attribution are unavailable.
  • Preserve native Landlock, seccomp-notify, transparent TCP, DNS mediation, and binary attribution behavior.
  • Document the operational model and limitations in the architecture, Kubernetes driver, compute-driver reference, and cluster-debugging skill.

Testing

  • mise run pre-commit passes
  • Focused Rust suite passes for the isolation interface, sandbox backend/runtime, supervisor, supervisor network, and Kubernetes driver (1,272 supervisor-network tests; all selected tests passed)
  • Workspace-wide cargo clippy --workspace --all-targets -- -D warnings passes
  • Unit tests added for adapter-bound audit evidence, unfiltered workload launch, explicit proxy acceptance, and gVisor Kubernetes provisioning/security context
  • mise run ci completes: all relevant code checks passed, but the pre-existing deterministic test:e2e-parity fixture failed because both its baseline and candidate fake wrappers emitted no manifests or reports
  • GKE Sandbox end-to-end validation (requires a gVisor-enabled GKE node pool)

Known limitations

  • Only proxy-aware HTTP/HTTPS clients are mediated. Direct TCP, UDP, and direct DNS remain blocked by the outer NetworkPolicy.
  • Filesystem enforcement is limited to the gVisor sentry plus OCI mounts; Landlock path allowlists are unavailable.
  • Process attribution is sandbox/session plus requested endpoint, not executable identity.
  • The workload UID model is unchanged in this PR.

Checklist

@drew
drew added this pull request to stack #3368 September 16, 2026 07:43
@copy-pr-bot

copy-pr-bot Bot commented Sep 16, 2026

Copy link
Copy Markdown

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

@github-actions

Copy link
Copy Markdown

Signed-off-by: Drew Newberry <anewberry@nvidia.com>
@drew
drew force-pushed the codex/gvisor-runtime-adapter branch from a786dfb to fd21261 Compare September 16, 2026 19:04
Signed-off-by: Drew Newberry <anewberry@nvidia.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant