Skip to content

rfc-0005: propose sandbox proxy egress adapter model#1511

Draft
johntmyers wants to merge 4 commits into
mainfrom
0004-sandbox-proxy-egress-adapter/jm
Draft

rfc-0005: propose sandbox proxy egress adapter model#1511
johntmyers wants to merge 4 commits into
mainfrom
0004-sandbox-proxy-egress-adapter/jm

Conversation

@johntmyers

Copy link
Copy Markdown
Collaborator

Summary

Proposes an RFC for remodeling sandbox proxy egress around transport adapters, a shared egress intent/decision boundary, and relay-owned protocol parsing/dialing.

Related Issue

None.

Changes

  • Adds RFC 0004 for the sandbox proxy egress adapter model.
  • Documents current proxy shape, including nftables bypass enforcement and current forward-proxy mitigation behavior.
  • Splits technical details and implementation phases into appendix files.
  • Covers CONNECT, forward HTTP, policy DNS, transparent TCP, local service adapters, WebSocket handling, and request-body credential rewrite.

Testing

  • mise run pre-commit passes
  • Unit tests added/updated
  • E2E tests added/updated (if applicable)

Not run; RFC/documentation draft only. A pre-commit run was started and then intentionally stopped because this is a draft RFC.

Checklist

  • Follows Conventional Commits
  • Commits are signed off (DCO)

Signed-off-by: John Myers <johntmyers@users.noreply.github.com>
@copy-pr-bot

copy-pr-bot Bot commented May 21, 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.

@pimlock pimlock added the rfc label Jun 5, 2026
@pimlock pimlock mentioned this pull request Jun 9, 2026
4 tasks
@drew drew changed the title docs(rfc): propose sandbox proxy egress adapter model docs(rfc): propose sandbox proxy egress adapter model (rfc-0005) Jun 16, 2026
@drew drew changed the title docs(rfc): propose sandbox proxy egress adapter model (rfc-0005) rfc-0005: propose sandbox proxy egress adapter model Jun 16, 2026
jganoff added a commit to jganoff/OpenShell that referenced this pull request Jun 24, 2026
Specify the Isolation Backend that RFC 0001 declared but left unspecified: the
contract by which a pluggable backend establishes an agent's isolation boundary
and the supervisor operates it, instead of the supervisor building the boundary
inline with logic hardcoded for one environment.

Why now: OpenShell is already building boundary placements other than in-pod (a
microVM driver on main, open work for a node enforcer and an outer gVisor
sandbox). Without a shared contract each one wires its own privileged setup and
supervisor mode into the codebase. The interface makes them backends behind one
contract instead of supervisor forks, and keeps open the path to a placement that
runs the supervisor outside the agent's kernel without rewriting the supervisor.

Contents:
- Two-faces model: a provisioning contract the driver realizes on the control
  plane and a runtime contract the supervisor drives on the data plane, handing
  off through the provisioned environment.
- An 8-call runtime contract with ordering as a security property; five calls
  stable, three (exec, port_forward, identity) provisional, validated only where
  the supervisor shares the agent's kernel.
- A Scope-and-status section stating what is stable vs in flight, which
  placements share the kernel, that Phase 1 ships a consistency check rather than
  cryptographic verification, and a falsifiability clause.
- Trust defined as a contract (four MUSTs); the cryptographic mechanism deferred
  to a Phase 2 trust RFC. Capability-gated identity with an assurance ladder.
- A kernel-sharing 2x2 with the forbidden cell (one pod plus a kernel-separated
  supervisor is not expressible on stock Kubernetes), grounded in the CRI shape.
- An in-pod-first, behavior-preserving implementation plan; the nft fail-open fix
  is a hard prerequisite for Phase 1.
- Security disclosures (shared-kernel residual risk, init-container exposure) and
  explicit non-goals (control-plane authorization, the trust mechanism, one-to-N
  supervisors).

Supporting files: topology-matrix.md (placement catalog + selection matrix),
codebase-grounding.md (file:line verification against main).

Refs NVIDIA#1737, NVIDIA#899, NVIDIA#981, NVIDIA#1511, NVIDIA#1650, NVIDIA#1680.
Signed-off-by: John Myers <johntmyers@users.noreply.github.com>
Signed-off-by: John Myers <johntmyers@users.noreply.github.com>
Signed-off-by: John Myers <johntmyers@users.noreply.github.com>
@copy-pr-bot

copy-pr-bot Bot commented Jun 26, 2026

Copy link
Copy Markdown

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

@github-actions

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

Status: Todo

Development

Successfully merging this pull request may close these issues.

3 participants