Write-only RBAC

No get, no list, no watch. The deployer can install a tenant’s database credential, registry pull secret or TLS key, and cannot read any of them back — not its own, not another tenant’s.

State the consequence precisely, because the precision is the lesson. A stolen deployer token is an integrity and availability problem: an attacker can overwrite credentials and break things. It is not a confidentiality problem: it does not hand over every tenant secret in the cluster. Those are different incidents with different disclosure obligations, and the difference is this one line.

Most deploy tooling holds get on Secrets because a read-modify-write needs it. Not needing it is a design achievement, and the next annotation is how.

This is the part people miss, and it is what makes write-only workable rather than merely aspirational.

update is a PUT: it replaces the whole object, so you must send every field — which means you must first have read it. update without get is nearly useless, because any change you make clobbers the keys you could not see.

patch is different. A JSON-merge or strategic-merge patch is applied by the API server, so you send only the keys you are changing and the server merges them into an object you never saw. "Set this one key, leave the rest alone" becomes possible without a read.

So the verb choice is not stylistic. Swap patch for update here and either the deployer breaks or somebody adds get back to fix it — and the property is gone.

Here is the third reading, and the reason this file is worth thirty minutes rather than five.

Anything that can create a Deployment can create a pod. A pod can mount any Secret in its namespace and print it to a log, or ship it anywhere. So a compromised deployer can obtain Secret values — not by asking the API for them, but by asking the kubelet to hand them to a container it controls.

The property this role actually provides is: the API server will not return a Secret to this identity. It is not: this identity cannot obtain a Secret. The first is real and worth having — it defeats the cheap smash-and-grab, it is visible in audit logs as a conspicuous pod creation rather than an ordinary read, and it raises the noise floor of an attack considerably. But it is not the second, and a slide that claims the second is teaching something false.

Closing the gap needs a different mechanism: a validating admission policy constraining which Secrets a workload may mount, or splitting workload creation onto a separate identity from secret installation. Ask a class which they would choose and why before you say.

Read this next to allowExternalNameServices: true in the Traefik values. Because that setting is on, creating a Service is enough to point the ingress controller at an arbitrary host. This rule grants exactly that.

It is not obviously wrong — the deployer has to create Services for the workloads it deploys — but it does mean the two files have to be read together, and neither one mentions the other. That is the thing to point at: a trust boundary that only exists in the intersection of two manifests is a boundary nobody will notice when they change one of them.

A Certificate is a request, not a key — the private key lands in a Secret that this role cannot read. So full read access to Certificates leaks nothing, and the deployer needs it to know whether issuance succeeded.

Worth a minute in class as a contrast: the split between "the object describing the credential" and "the credential" is what lets one be readable and the other not. Designs that conflate the two cannot make this distinction.

An RBAC file records what was granted. It cannot record what was considered and refused, which means the next person to hit a permission error cannot tell a deliberate omission from an oversight — and the path of least resistance is to add the verb.

This comment block is the cheapest control in the repository. It converts "the deployer cannot exec into pods" from an accident into a decision, and it makes a pull request that adds pods/exec a conversation instead of a typo.

RBAC is additive and a subject can hold several roles, so reading one file does not tell you what an identity can do. Ask the API server instead:

kubectl auth can-i get secrets \
  --as=system:serviceaccount:platform:deployer
# no

kubectl auth can-i create deployments \
  --as=system:serviceaccount:platform:deployer
# yes   ← and that is the gap in the annotation above

Run both in front of a class. The second answer landing "yes" right after the first lands "no" is the moment the lesson sticks.