Least-privilege access to the aggregated API server serving-CA Secret

[ThomasK33]

The aggregated API server keeps its serving CA, including the CA private key, in the coder-k8s-apiserver-tls Secret in its own namespace (#140). Today it reads and writes that Secret through manager-role, which grants cluster-wide Secret access to the same ServiceAccount the controller uses.

Proposal: give the aggregated API server a namespaced Role that allows only get, create and update on the coder-k8s-apiserver-tls Secret (resourceNames; create cannot be limited by name, so it needs care). Consider running the aggregated API server under its own ServiceAccount so it does not inherit the controller's Secret access. That is where least privilege actually improves.

Acceptance:

1. The aggregated API server works with only the namespaced Role for this Secret, proven by an envtest or the Kind E2E.
2. The controller-only bundle (dist/install.yaml) is unchanged, or its change is intentional and documented.
3. The docs state which identity can read the CA key.

Owner: maintainer desk. Trigger: after #137 closes. Refs #137.

---

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: medium

[ThomasK33]

Done on main (8aadab6d). All three steps have landed.

1. docs: state who can read the aggregated API server CA key #145 (docs): the docs say who can read the serving-CA key, by deployment mode. For --app=all, a narrower Role would not help: one process runs the controller and the aggregated API server under one ServiceAccount, and the controller needs cluster-wide Secret access. That is stated plainly, with the mitigations.

2. feat: fill an empty placeholder serving-CA Secret instead of creating it #146: the aggregated API server fills an empty placeholder coder-k8s-apiserver-tls Secret instead of creating it, so it does not need create on Secrets.

   • A placeholder has the managed type, no data and is not immutable. Every other Secret still fails startup and is never overwritten.
   • The fill is an update guarded by resourceVersion.
   • A Secret's type is immutable (422), so update cannot turn it into another kind of Secret.

3. feat: run the standalone aggregated API server as its own ServiceAccount #147: a standalone --app=aggregated-apiserver server runs as its own ServiceAccount, coder-k8s-apiserver, using config/apiserver-standalone/. It gets only:

   • get/update on its own Secret;
   • delegated authentication and authorization;
   • its APIService.

   An envtest impersonating that account against a real kube-apiserver shows it works and is denied everything else. The docs cover moving an existing standalone server over; the CA is reused.

Acceptance criteria:

1. The aggregated API server works with only the namespaced Role for this Secret in standalone mode. The envtest proves it, and a Kind run showed 5 minutes without a permission error.
2. dist/install.yaml is unchanged.
3. The docs state which identity can read the CA key.

The default --app=all install is unchanged. #144 (bring-your-own certificate) stays open until someone asks for it.

---

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: medium