Repository navigation
feat: delegate stable sandbox SPIFFE identities from the shared supervisor #4731
Description
User Story
I am prototyping OpenShell's shared Kubernetes supervisor and need it to obtain provider credentials using a sandbox's stable SPIFFE identity, without adding SPIFFE components or credentials to the sandbox workload.
Problem Statement
The experimental shared supervisor cannot currently obtain a distinct SPIFFE JWT-SVID for each sandbox. A normal Workload API call identifies the shared supervisor process, and the gateway topology currently rejects provider SPIFFE configuration.
Impact / Why This Matters
Sandbox-specific provider token exchange cannot be used with shared supervision. Moving SPIFFE sockets or SVIDs into sandbox workloads would violate the intended separation between workloads and credential handling.
Proposed Design
Allow the shared supervisor to use the gateway-issued session JWT as evidence of the sandbox it supervises, obtain a sandbox-specific JWT-SVID through SPIRE delegation, and use it for the existing provider exchange flow. The SPIFFE ID represents the immutable sandbox ID and stays the same across stop/start or runtime replacement. Current generation and credential epoch still control authorization, renewal, and credential caching.
Keep SVIDs, SPIRE API access, and provider credentials on the supervisor. Provide configuration and an operational path for registering sandbox identities in SPIRE, scoped to the supervisor's agent. Fail closed on invalid, expired, mismatched, or revoked authorization and unavailable/mismatched SPIRE identities.
Suggested UX
Use experimental_supervisor_topology = "gateway" with a supervisor-side delegated identity configuration. Operators configure the trusted SPIRE delegate and the mapping from verified gateway/sandbox identity to SPIRE registration entries. The sandbox workload receives no SPIFFE API socket, SVID, or provider access token.
Acceptance Criteria
- Two sandbox sessions obtain distinct expected SPIFFE IDs and exchange them for their own provider credentials.
- A sandbox preserves its SPIFFE ID across stop/start while old generation credentials cannot authorize new acquisition.
- Invalid or mismatched JWTs cannot select another sandbox's identity.
- Session removal prevents further acquisition and use of the session's cached credentials.
- Delegation uses a private supervisor-side SPIRE endpoint; the sandbox receives no SPIFFE credentials or components.
- Existing dedicated Workload API and topology-unset behavior remain compatible.
- Configuration and SPIRE registration/setup requirements are documented and verified with focused integration coverage.
Alternatives Considered
Using the supervisor's ordinary Workload API identity conflates tenants. Running a SPIRE agent or acquiring an SVID inside every sandbox violates the desired credential boundary. Existing provider token grants remain the exchange mechanism; this work adds sandbox identity acquisition underneath them rather than replacing provider behavior with a separate credential system.
Activity
grs commentedon Oct 20, 2026
@drew this is a nice approach! However it does make the overall picture quite complicated.
What about keeping the same idea but with the gateway as the trusted delegate for sandbox SVID retrieval rather than the supervisor? It already controls sandbox identity and mints the tokens used to authenticate sandboxes to supervisors, so it is the natural place to enforce which sandbox identity a session may obtain.
Supervisors would request an SVID from the gateway using their gateway-issued session credentials. The gateway would validate the current session, derive the sandbox’s identity from authoritative state, and retrieve the corresponding SVID. This keeps SPIRE delegation privileges and configuration at the gateway, while dedicated, gateway-shared, and any future workspace-shared supervisors all use the same mechanism.
This same approach could be used by every topology which would simplify the code. Every topology would use the same stable identity form, such as …/gateway//sandbox/, which resolves directly to a gateway-owned sandbox record without depending on pod placement or supervisor topology (avoiding the concerns raised in #3037 and its implications) and makes it much easier to base decisions on those identities. Every topology would also use the same SPIRE configuration. Explicit sandbox registrations would still be required, but their management would follow sandbox lifecycle rather than supervisor scheduling.
Dedicated SPIRE agents deployed alongside gateway replicas could keep delegation scoped to each logical gateway without requiring special node placement or changes to node-agent configuration as supervisors move or their sandbox assignments change.