fix(helm): improve spiffe id configuration in ci overlay
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 52/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- helm, kubernetes
调研方向
从 deploy/helm/openshell/ci/values-spire-stack.yaml 开始,然后对比所列示例脚本、工作负载、README 和 docs/kubernetes/access-control.mdx 中的 subject 重构。完成的标准是 workspace namespace 能够接收 SVIDs,模板使用 namespace 和 pod identity,而不是 self-asserted annotation,验证仍保持兼容,并且 Operator-mode labeling 要求及示例得到一致的文档说明。
由索引模型根据 Issue 内容生成。
描述
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
- 主要语言
- Rust
- 星标
- 8.7k
- 派生
- 1.3k
- 平均合并
- 2 天 6 小时
- 30 天内合并 PR
- 297
贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
NVIDIA/OpenShell 的其他 Issue
-
area:docs
难度 1/5 1 小时以内 新手友好度 88/100
-
state:triage-needed
难度 2/5 1-3 小时 新手友好度 82/100
-
area:cli state:validated
难度 2/5 1-3 小时 新手友好度 72/100
-
state:triage-needed
难度 1/5 1 小时以内 新手友好度 90/100
-
area:build spike state:review-ready state:stale
难度 2/5 半天 新手友好度 68/100
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 75/100
-
state:needs triage
难度 2/5 1-3 小时 新手友好度 70/100
zed-industries/zed#64680 · 2 条评论 ·
-
难度 2/5 1-3 小时 新手友好度 70/100
-
难度 2/5 1-3 小时 新手友好度 70/100
RustPython/RustPython#8802 ·
-
难度 2/5 1-3 小时 新手友好度 75/100
TheLarkInn/aipm#2390 ·