Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Ownership proof for Coder IDs recorded in controller status (D11 B)

Open
  • Is something wrong?
#372 0 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@ThomasK33 is already working on this.

Since Oct 14, 2026.

Assessment

This issue has not been assessed yet.

Description

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:

  1. Where the key lives, and how it rotates.
  2. The recovery path when the key is lost or rotated: re-adopt by the ownership markers that the controllers already write (for example the CoderMCPServer nonce), or require a spec edit.
  3. 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

Dominant language
Go
Stars
5
Forks
3
Avg merge
2h 56m
Merged PRs (30d)
185

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from coder/coder-k8s

All issues in coder/coder-k8s

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.