feat(sandbox): add the Local and Kubernetes backends and the cloud bindings

[ItamarZand88]

Summary

Adds the code that actually runs a sandbox session: the Local and Kubernetes backends, and the bindings an application calls on AWS, Azure and GCP. Layer 4 rendered the infrastructure; this makes a session start, run a command, and stop.

When an application asks a Kubernetes sandbox to run something:

1. It presents the ServiceAccount token Kubernetes already mounted in its pod to the session broker.
2. The broker checks that token with a TokenReview, takes a warm pod from the pool, and labels it with the session.
3. It mints a capability signed with a key the application never sees, derived from the sandbox's own id rather than named by the caller.
4. The application drives the session over the agent port, presenting that capability on every call.

What I did

Three decisions are worth pointing at, each of which came out of a review finding rather than a plan:

• The broker derives the signing key; it does not accept one. The claim request used to carry the secret name. A workload holding one sandbox's handle could name a sibling's secret and get a capability minted under that sibling's key. The name is deterministic, so the field is gone from the wire format.
• Azure refuses what it cannot enforce. The Azure data plane takes no egress policy and no per-session ceiling, and the binding carries neither — so a declared deny was accepted and dropped, leaving a stack reading as restricted while the code ran with open egress. Azure now publishes false for both capabilities, which turns the declaration into a plan-time refusal. allow is still accepted: it asks for no restriction, so a backend that ignores it fails loudly on the first blocked connection rather than quietly under-protecting.
• Terminate reports failure. Both the Local and Azure paths discarded the result of their delete and returned success. Terminate is the containment kill switch — reporting success for a daemon error or a throttle tells the caller untrusted code has stopped when it has not. Only an absent session is success now.

A fourth is smaller but had the same cause: the Azure get treated any error whose rendered text contained 404 as "session gone", and the data plane formats the whole response body into that text. A throttle, or a path containing 404, read as gone — which starts a second sandbox while the first keeps running. The status is carried structurally now.

Files touched

• crates/alien-infra/src/sandbox/ — the Kubernetes controller, warm pool, session broker and its route.
• crates/alien-local/ — the Docker-backed local manager and its loopback route.
• crates/alien-bindings/src/providers/sandbox/ — the five backends behind one trait.
• crates/alien-k8s-clients/, crates/alien-aws-clients/, crates/alien-azure-clients/ — the API surfaces those call.

How I tested

• cargo test across the touched crates — the Kubernetes broker, warm pool, path confinement, capability minting and the five providers.
• Mutation-tested every fix above by breaking it and watching a test fail: flipping Azure's egress capability back to true, removing the chart's ingress rule, and reverting the 404 classifier to substring matching. Each fix has a test that fails without it.
• Live suites (#[ignore]d, run by hand): a real GKE Autopilot cluster for the Kubernetes backend, and Docker for the Local one.

Security review of this diff, since it mints the credential that reaches inside a session:

• A workload minting a capability under another sandbox's key — the broker derives the key name from the sandbox id, and a request naming one no longer deserializes (kubernetes_route.rs).
• A capability replayed against another session — the AWS token is scoped to its MicroVM by the platform, and the Kubernetes capability is bound to the claimed session and checked at the agent.
• A declared egress restriction silently dropped — refused at plan time on any backend that cannot enforce it, with the capability table as the single source of that answer.
• Untrusted code left running after terminate — every delete failure now propagates except an absent session.
• A rejected ServiceAccount token accepted — the apiserver answers 200 with authenticated: false, so the verdict is read rather than the status code, and namespace matching is a full-prefix check.

One thing this diff does not close, stated plainly rather than left to a reader: the broker authenticates the caller but does not check which sandbox it may claim from. claim verifies a ServiceAccount in the deployment's namespace and then takes the sandboxId from the request. Binding an authenticated identity to an entitled set of sandboxes needs state the broker does not have yet.

[greptile-apps]

Greptile Summary

The PR adds executable sandbox sessions across Local, Kubernetes, AWS, Azure, and GCP, including cloud API clients, lifecycle handling, command transport, and capability-based access.

• Adds Docker-backed Local and warm-pool Kubernetes session backends.
• Adds application-facing cloud sandbox providers and supporting AWS/Azure/Kubernetes client APIs.
• Enforces command deadlines, confirmed Azure termination, structured absence detection, and image-scoped AWS session ownership.

Confidence Score: 5/5

The PR appears safe to merge because no blocking failure remains from the previously reported issues.

No blocking failure remains.

Important Files Changed

Filename	Overview
crates/alien-bindings/src/providers/sandbox/azure.rs	Implements Azure session execution and lifecycle handling, including deadline-triggered deletion and polling until confirmed absence.
crates/alien-azure-clients/src/azure/sandbox_data_plane.rs	Adds the Azure sandbox data-plane client with structured HTTP errors that support reliable 404 classification.
crates/alien-bindings/src/providers/sandbox/aws.rs	Implements Lambda MicroVM sessions with image-scoped ownership checks, endpoint-token authorization, lifecycle operations, and preview capabilities.
crates/alien-bindings/src/providers/sandbox/kubernetes.rs	Adds the Kubernetes application binding for broker-mediated session claims and agent access.
crates/alien-infra/src/sandbox/kubernetes_broker.rs	Adds broker-side Kubernetes authentication, warm-pod claiming, and session capability minting.
crates/alien-local/src/sandbox_manager.rs	Adds Docker-backed local sandbox creation, isolation, execution, and teardown management.

Sequence Diagram

sequenceDiagram
  participant App as Application
  participant Binding as Sandbox binding
  participant Backend as Local/Cloud backend
  participant Agent as Sandbox agent
  App->>Binding: create/get session
  Binding->>Backend: allocate or claim sandbox
  Backend-->>Binding: session identity
  App->>Binding: run command with deadline
  Binding->>Agent: authenticated command
  Agent-->>Binding: output and exit status
  Binding-->>App: command stream/result
  App->>Binding: terminate
  Binding->>Backend: delete session
  Backend-->>Binding: absence confirmed

Loading

_{Reviews (11): Last reviewed commit: "feat(sandbox): add the Local and Kuberne..." | Re-trigger Greptile}