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時間
- マージ済み PR（30日）
- 192
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- 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 が 4 日前に担当しました。 オープン
coder/coder-k8s#353 · コメント 4 件 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
coder/coder-k8s の issue をすべて見る
似ている issue
-
ViewData can pair the in-flight proposal with the prepared flag of another proposal対応中かも @HagarMeir が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
hyperledger/SmartBFT#710 ·
メンテナーはふだん 1 日以内に返信
-
agent-butler-finding chore
難易度 1/5 1時間未満 初心者へのやさしさ 90/100
jordansmall/spindrift#5575 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
open-telemetry/opentelemetry-go-compile-instrumentation#1512 ·
メンテナーはふだん 3 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 85/100
slavakurilyak/awesome-ai-agents#805 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
JakeChampion/lang#12684 ·
メンテナーはふだん 1 日以内に返信