fix(helm): improve spiffe id configuration in ci overlay
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 52/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- helm, kubernetes
- Ambito
- documentation, infrastructure, security
Direzione di ricerca
Inizia da deploy/helm/openshell/ci/values-spire-stack.yaml, quindi confronta la ricostruzione del subject negli script di esempio, nei workload, nel README e in docs/kubernetes/access-control.mdx elencati. Il lavoro è completo quando i namespace del workspace ricevono SVIDs, il template usa l’identità del namespace e del pod invece dell’annotazione auto-dichiarata, la validazione rimane compatibile e il requisito di labeling in modalità Operator e gli esempi sono documentati in modo coerente.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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
- Sandbox pods receive SVIDs in Managed and Operator workspace modes, not just Shared.
- namespaceSelector matches OpenShell-managed workspace namespaces via a stable label rather than a hardcoded name.
- SPIFFE ID template encodes namespace and pod name (optionally the sandbox UUID) and no longer depends on the self-asserted openshell.io/sandbox-id annotation as its discriminator.
- Gateway/supervisor SVID validation still passes (trust-domain match unchanged; no Rust changes required).
- Operator-mode namespace labeling requirement documented.
- Example overlays that reconstruct the subject stay consistent: examples/spiffe-token-exchange-demo/podman/spire/register-sandbox.sh, examples/spiffe-token-grant-demo/k8s/workloads.yaml,
.../token-issuer.js, .../README.md. - Docs updated: docs/kubernetes/access-control.mdx.
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
- OpenShell 0.0.117
Logs
- Lingua principale
- Rust
- Stelle
- 8.7k
- Fork
- 1.3k
- Merge medio
- 2g 6h
- PR unite (30g)
- 297
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di NVIDIA/OpenShell
-
area:docs
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
-
state:triage-needed
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
-
area:cli state:validated
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
-
state:triage-needed
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
-
area:build spike state:review-ready state:stale
Difficoltà 2/5 Mezza giornata Idoneità per principianti 68/100
Tutte le issue di NVIDIA/OpenShell
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
state:needs triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
zed-industries/zed#64680 · 2 commenti ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
RustPython/RustPython#8802 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
TheLarkInn/aipm#2390 ·