User Story
As an operator using the OpenShell SPIRE CI/dev overlay as a reference for provider token grants on Kubernetes, I want the sandbox SPIFFE ID configuration to work across workspace modes and to anchor identity on Kubernetes-enforced attributes, so that sandbox pods reliably receive locatable, hard-to-spoof SVIDs regardless of workspace layout.
Problem Statement
The SPIRE overlay (deploy/helm/openshell/ci/values-spire-stack.yaml) assumes a single, fixed sandbox namespace and derives identity from a self-asserted pod annotation:
spiffeIDTemplate: 'spiffe://{{ .TrustDomain }}/openshell/sandbox/{{ index .PodMeta.Annotations "openshell.io/sandbox-id" }}'
namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: openshell
Two problems:
- Workspaces may break the selector. Sandbox namespaces depend on WorkspaceMode. Only Shared mode uses the fixed openshell namespace. Managed mode creates namespaces named openshell-{gateway_id}-{workspace}; Operator mode uses the workspace name as the namespace. In both, kubernetes.io/metadata.name is not openshell, so the namespaceSelector misses those pods and they receive no SVID — provider token grants silently stop working outside Shared mode. The template also carries no namespace/workspace or pod name, so an SVID can't be located or distinguished across workspaces.
- Identity rests on self-asserted metadata. The discriminating segment is the pod annotation openshell.io/sandbox-id, which the pod author controls. Any pod matching the selectors that sets the same annotation value receives an identical SVID; uniqueness relies entirely on cluster RBAC restricting who can stamp it. Because this overlay is the reference operators copy, it should model anchoring identity on Kubernetes-enforced attributes rather than a free-form annotation.
Impact / Why This Matters
- Consequence of current behavior: SPIFFE-based provider token grants only work in Shared workspace mode; enabling Managed/Operator workspaces deprives sandbox pods of SVIDs and breaks token-grant/token-exchange flows. Separately, the shipped reference config teaches operators to base identity on a self-asserted annotation gated only by RBAC — a single-layer control with no defense-in-depth.
- Current workaround: Restrict SPIFFE to Shared mode, or hand-edit the overlay per deployment.
- Why insufficient: It couples the identity plane to one workspace mode, requires per-deployment overlay surgery, and propagates a weaker-than-necessary identity pattern to everyone who starts from this overlay.
Acceptance Criteria
Reproduction Steps
- Use the in tree overlay to configure SPIRE
- Token exchange or dynamic token grants for sandboxes in pods other than 'openshell' will fail
Environment
Logs
User Story
As an operator using the OpenShell SPIRE CI/dev overlay as a reference for provider token grants on Kubernetes, I want the sandbox SPIFFE ID configuration to work across workspace modes and to anchor identity on Kubernetes-enforced attributes, so that sandbox pods reliably receive locatable, hard-to-spoof SVIDs regardless of workspace layout.
Problem Statement
The SPIRE overlay (deploy/helm/openshell/ci/values-spire-stack.yaml) assumes a single, fixed sandbox namespace and derives identity from a self-asserted pod annotation:
spiffeIDTemplate: 'spiffe://{{ .TrustDomain }}/openshell/sandbox/{{ index .PodMeta.Annotations "openshell.io/sandbox-id" }}'
namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: openshell
Two problems:
Impact / Why This Matters
Acceptance Criteria
.../token-issuer.js, .../README.md.
Reproduction Steps
Environment
Logs