Ownership proof for Coder IDs recorded in controller status (D11 B)
维护者通常 1 天内回复
@ThomasK33 已经在做这个了。
开始于 2026年10月14日。
评估
这个 Issue 还没有评估数据。
描述
Problem
Several controllers record a Coder resource ID in the status subresource and then treat that resource as their own. Examples: CoderMCPServer status.configID, CoderAIProvider status.providerID and status.keyID, CoderTemplateTest status.templateID and status.workspaceID, and the IDs in the CoderAIGatewayKey status.
A subject with write access to the status subresource can set such an ID to another Coder resource. The controller then updates that resource to the subject's spec and deletes it with the subject's object. For CoderMCPServer this is threat T19 in the #155 plan: any config in an organization that the control plane lists.
Today only an RBAC contract protects these fields. The docs Roles never grant the status subresource, and the docs warn that resources: ["*"] also grants subresources. The #155 activation (M9) adds an opt-in admission policy that denies codermcpservers/status writes from every subject except the operator ServiceAccount (#155 decision D11, option A).
Proposal (D11 option B)
Record ownership in a form that a status writer cannot forge, for every controller kind at once. One option: an HMAC of the object UID and the Coder resource ID with an operator-held key, checked before the controller acts on a recorded ID.
Open questions:
- Where the key lives, and how it rotates.
- The recovery path when the key is lost or rotated: re-adopt by the ownership markers that the controllers already write (for example the
CoderMCPServernonce), or require a spec edit. - Migration of objects that already hold an unsigned ID.
Why a follow-up
Option B adds key storage, rotation and a recovery path, and it belongs in all controllers at once, the #154 kinds included. The #155 plan chose option A for v1 and this issue as the follow-up.
Refs #155
Refs #154
Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high • Cost: $211.58
- 主要语言
- Go
- 星标
- 5
- 派生
- 3
- 平均合并
- 3 小时
- 30 天内合并 PR
- 192
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
coder/coder-k8s 的其他 Issue
-
CoderWorkspacePoolMember checkCreate: trust only Coder's own 404 on the name lookup (before PR 12)未关闭
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复
-
TestReconcile_LicenseRotationUploadsNewSecretValue fails at -count=3 (reuses a control plane name)未关闭
难度 2/5 1-3 小时 新手友好度 62/100
维护者通常 1 天内回复
-
CoderMCPServer Kind E2E follow-ups可能已有人在做 @ThomasK33 于 3 天前认领。 未关闭
coder/coder-k8s#390 · 已指派 1 人 ·
维护者通常 1 天内回复
-
CoderMCPServer delete and RBAC test follow-ups可能已有人在做 @ThomasK33 于 3 天前认领。 未关闭
coder/coder-k8s#378 · 已指派 1 人 ·
维护者通常 1 天内回复
-
Namespace deletion leaves AI Gateway keys and AI providers in Coder可能已有人在做 @ThomasK33 于 3 天前认领。 未关闭
coder/coder-k8s#353 · 4 条评论 · 已指派 1 人 ·
维护者通常 1 天内回复
相似的 Issue
-
triage
难度 2/5 1-3 小时 新手友好度 86/100
wakatime/wakatime-cli#1649 ·
维护者通常 1 天内回复
-
PathBuffer.Pop corrupts later error locations when a key contains "." or "["可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭
难度 2/5 1-3 小时 新手友好度 68/100
danielgtaylor/huma#1135 ·
维护者通常 1 天内回复
-
needs-triage
难度 2/5 1-3 小时 新手友好度 68/100
stacklok/toolhive-catalog#1734 ·
维护者通常 1 天内回复
-
documentation priority:p1
难度 2/5 1-3 小时 新手友好度 78/100
yeixio/toskar-core#697 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
keyxmakerx/Chronicle#1532 ·
维护者通常 1 天内回复