fix(helm): improve spiffe id configuration in ci overlay
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 52/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- helm, kubernetes
- Área
- documentation, infrastructure, security
Línea de trabajo
Comienza con deploy/helm/openshell/ci/values-spire-stack.yaml y, después, compara la reconstrucción del subject en los scripts de ejemplo, workloads, README y docs/kubernetes/access-control.mdx indicados. Se considera terminado cuando los namespaces del workspace reciben SVIDs, la plantilla usa la identidad del namespace y del pod en lugar de la anotación autoafirmada, la validación sigue siendo compatible y el requisito de etiquetado en modo Operator y los ejemplos están documentados de forma coherente.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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
- Lenguaje dominante
- Rust
- Estrellas
- 8.7k
- Forks
- 1.3k
- Merge medio
- 2 d 6 h
- PR fusionados (30 d)
- 297
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de NVIDIA/OpenShell
-
area:docs
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
-
state:triage-needed
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
-
area:cli state:validated
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
-
state:triage-needed
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
-
area:build spike state:review-ready state:stale
Dificultad 2/5 Medio día Aptitud para principiantes 68/100
Todos los issues de NVIDIA/OpenShell
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
state:needs triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
zed-industries/zed#64680 · 2 comentarios ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
RustPython/RustPython#8802 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
TheLarkInn/aipm#2390 ·