How do you scope Kubernetes RBAC so that a workload or a human can read only the Secrets it actually needs, and why is granting the list verb on Secrets almost as dangerous as granting read access to every one of them?

## The shape of a least-privilege Secret grant RBAC rules are additive and there are no deny rules, so a subject's access is the union of every rule bound to it. The tightest grant RBAC can express for Secrets is a namespaced `Role` with `verbs: ["get"]`, `resources: ["secrets"]`, and `resourceNames` listing exactly the Secrets involved, bound with a `RoleBinding` to a single ServiceAccount rather than to a group or to `system:authenticated`. Two consequences follow immediately. Because the Role is namespaced, the grant cannot reach Secrets in other namespaces even if names collide, which makes the namespace the practical unit of secret isolation. And because `resourceNames` is a static list, creating a new Secret requires updating the Role, which is friction but also the point. ## Why list and watch are the dangerous verbs A `get` returns one named object. A `list` returns a collection, and a `watch` streams the collection plus every subsequent change. In all three cases the API server returns the *full* object, including the decrypted `data` field. There is no projection that strips values, and no field-level RBAC. So `list secrets` is not metadata access, it is bulk read. The second, less-known part is that `resourceNames` has no effect on `list`, `watch`, `deletecollection`, or `create`. Those verbs act on a collection or on an object whose name is not known at authorization time, so the authorizer cannot match a name and the restriction is simply not applied: a rule granting `list` on `secrets` with `resourceNames` set still grants list over the whole namespace. This surprises people who believe they wrote a tight rule. Scope multiplies the damage. A `ClusterRole` granting `list secrets` bound with a `ClusterRoleBinding` reads every Secret in every namespace, and Kubernetes Secrets typically include ServiceAccount tokens, image-pull credentials, TLS private keys, and cloud IAM keys. That is a straight path to cluster-admin, which is why it belongs on the same shortlist as `escalate`, `bind`, and `impersonate`. ## The paths RBAC does not cover Tightening the `secrets` resource is necessary but not sufficient, because several other permissions grant indirect read: - **`create` on pods (or on any workload controller)** in a namespace: the subject writes a Pod that mounts any Secret in that namespace and prints it, or ships it out over the network. - **`pods/exec` and `pods/attach`**: the subject enters a running Pod and reads whatever credentials it already holds, including its projected ServiceAccount token. - **`pods/log`**: catches anything the application logged, which in practice is where credentials most often end up. - **`create` on `serviceaccounts/token`**: mints a token for another ServiceAccount and inherits its permissions. - **`impersonate`**: acts as another user, group, or ServiceAccount outright. This is why security reviews say the namespace, not the RBAC verb, is the real boundary for Secrets: if a subject can schedule workloads in a namespace, assume it can read every Secret there. ## Operating the model In practice: one ServiceAccount per workload, its Role listing only the Secrets that workload consumes, and no wildcard `resources: ["*"]` or `verbs: ["*"]` in any ClusterRole you author. Audit with `kubectl auth can-i --list --as=system:serviceaccount:ns:sa`, and periodically sweep for the dangerous shape: Also remember that most workloads never need the `secrets` verb at all, because the kubelet, not the Pod, reads the Secret to mount it. Only controllers, operators, and CSI-style integrations legitimately call the Secrets API. If an application ServiceAccount has `get secrets`, ask why the value is not simply mounted. Finally, the aggregated built-in roles matter: `view` deliberately excludes Secrets, but `edit` and `admin` include full Secret access within their namespace, so binding `admin` to a team is granting them every Secret in that namespace, which is usually intended but should be a conscious decision. ## What to say Open with the tight rule (namespaced Role, `get`, `resourceNames`, bound to one ServiceAccount). Then explain that `list`/`watch` return `data` and that `resourceNames` does not constrain them. Close with the indirect paths (Pod create, exec, logs, token creation, impersonation) and the conclusion that the namespace is the isolation unit.