🤖 security: verify the aggregated API server certificate instead of insecureSkipTLSVerify

[ThomasK33]

deploy/apiserver-apiservice.yaml registers the aggregated API with insecureSkipTLSVerify: true, so kube-apiserver does not verify the aggregated API server's serving certificate. The docs already call this development-only, but it is what every documented install applies.

With authentication now required (#136), front-proxy mTLS still stops a network attacker from forging identities. But anyone who can hijack the coder-k8s-apiserver Service endpoints or sit on the network path could read relayed requests and the X-Remote-* identity headers.

Proposal: give the aggregated API server a serving certificate signed by a CA that the APIService trusts through caBundle, and drop insecureSkipTLSVerify. Options include cert-manager with a CA injector, or a self-managed CA Secret with an injected caBundle. Document the chosen path and keep a development shortcut only if it is clearly labelled.

Acceptance:

1. The documented install registers the APIService with a caBundle and no insecureSkipTLSVerify.
2. The Kind E2E shows the APIService Available with verification on, and failing with a wrong CA.
3. Docs describe certificate rotation.

Owner: maintainer desk. Trigger: after v0.1.1 is released.

---

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

[ThomasK33]

Progress: step 1 landed in #140 (650d1b22). In a cluster, the aggregated API server now serves a certificate signed by its own CA, which it keeps in the coder-k8s-apiserver-tls Secret and rotates without a restart. The APIService still uses insecureSkipTLSVerify: true for now.

Next: the server writes that CA into the APIService caBundle and turns verification on, with the manifest, RBAC, docs and a CI check in the same PR. A second PR adds the wrong-CA negative check. This issue stays open until both land.

---

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

[ThomasK33]

The acceptance criteria are met on main (6a2e09d9):

1. The documented install registers the APIService with a caBundle and no insecureSkipTLSVerify.
   • 🤖 feat: serve the aggregated API server certificate from a managed CA #140: in a cluster, the aggregated API server serves a certificate signed by its own CA, which it keeps in the coder-k8s-apiserver-tls Secret.
   • feat: verify the aggregated API server certificate through the APIService caBundle #141: the server sets the APIService caBundle from that Secret and turns insecureSkipTLSVerify off. deploy/apiserver-apiservice.yaml no longer sets it. RBAC is limited to that one APIService, and the opt-out annotation coder.com/manage-ca-bundle=false covers clusters where another tool owns the field.
2. The Kind E2E proves verification in both directions. It sends real requests through kube-apiserver, because Available=True does not reflect certificate verification.
   • "Verify the APIService trusts the serving CA" passes.
   • "Verify the APIService rejects a wrong CA" requires a 503 plus kube-apiserver's x509 error, then recovery.
   • Both steps passed in the merge-queue runs for feat: verify the aggregated API server certificate through the APIService caBundle #141 and on main.
3. The docs describe rotation. The serving certificate renews itself. feat: verify the aggregated API server certificate through the APIService caBundle #141 and docs: troubleshoot x509 503s and document CA replacement #142 document the CA replacement procedure, the expected 503 window, the upgrade order and rollback, and an x509 troubleshooting section.

Follow-ups:

• Least-privilege access to the aggregated API server serving-CA Secret #143: least-privilege access to the serving-CA Secret.
• Bring-your-own serving certificate for the aggregated API server #144: bring-your-own serving certificate.

---

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