feat: support secure sandbox-to-sandbox communication #451
Description
Problem Statement
We need a supported way for one sandbox to communicate with another sandbox securely.
Today, sandboxes have cluster-internal DNS names, but exposing an application from one sandbox to another is not a first-class capability. We need a model for sandbox-to-sandbox communication that is explicit, secure, and policy-controlled.
Proposed Design
Introduce support for sandbox-to-sandbox communication with a minimal security model:
- Introduce some kind of sandbox identity so communication can be authorized securely.
- Require explicit enforcement on both sides:
- a sandbox must be explicitly allowed to expose a port
- a peer sandbox must be explicitly allowed by policy to talk to that sandbox
- Support dynamic configuration so exposure can happen during sandbox runtime.
- A broader generic solution for dynamic config is already being worked on, so this issue does not need to solve that part fully.
Alternatives Considered
- Continue relying only on host-side port forwarding. This helps local development, but it does not solve sandbox-to-sandbox communication inside the cluster.
- Expose sandbox ports without identity or policy controls. This would be too permissive.
Agent Investigation
We verified that sandboxes have stable cluster-internal DNS names of the form <sandbox>.<namespace>.svc.cluster.local, and that policy can allow traffic to those hostnames.
However, a typical user process started inside a sandbox is not automatically reachable from another sandbox through that DNS name, because the workload listens inside the inner sandbox network namespace rather than directly on the pod network. This means sandbox-to-sandbox communication needs an explicit product surface rather than just policy tweaks.