Everything so far granted whole resources. Real policies are narrower, and RBAC has three tools for that.
resourceNames
yaml
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get"]
resourceNames: ["db-creds"]sh
kubectl create role read-db-creds --verb=get --resource=secrets --resource-name=db-credsThe subject may get that one Secret. It may not get tls-cert, and it may not list Secrets at all: a list has no name to match, so names can only restrict get, update, patch and delete.
Subresources
Some actions are not the object itself:
| Action | Resource to grant |
|---|---|
kubectl logs | pods/log |
kubectl exec | pods/exec (verb create) |
kubectl scale | deployments/scale |
| reading status | pods/status |
A rule on pods grants none of them. That is deliberate: a log reader does not need to run commands in the container.
sh
kubectl create role log-reader --verb=get --resource=pods/logSeeing the result
sh
kubectl auth can-i --list --as system:serviceaccount:citadel:market-api -n citadeltext
Resources Non-Resource URLs Resource Names Verbs
secrets [] [db-creds] [get]
pods/log [] [] [get]This is the effective set, whatever mix of Roles, ClusterRoles and bindings produced it. Run it before and after a change.
The cost of a wildcard
every credential in the namespace
the power to grant yourself more
resource types that did not exist when you wrote the rule
A credential leaks eventually. A rule that names three resources limits what the leak is worth; * makes it worth the namespace.