Kubernetes RBAC Verbs: The Complete List, Including the Five Nobody Documents

RBAC reviews keep surfacing the same pattern: teams are precise about resources ("only Secrets in namespace X") and sloppy about verbs (verbs: ["*"], because enumerating them felt tedious). That asymmetry is backwards. The obscure verbs are where the privilege escalations live, and a wildcard verb grant hands them all out at once.

Here is the complete list — the standard eight, then the special ones that don't map to CRUD at all.

The Standard Verbs

get — read a single named object. kubectl get pod foo, and also what most controllers use to fetch their own resources.

list — read collections. Critically: list returns full object contents, not just names. Granting list on Secrets is granting the ability to read every Secret's data in scope — a fact that surprises people during their first audit. There is no "list names only" verb.

watch — subscribe to changes. Same data-exposure caveat as list: a watch on Secrets streams secret contents. In practice list and watch travel together (informers need both).

create — make new objects. Remember that create on pods is effectively quite powerful on its own: a pod can mount ServiceAccount tokens and Secrets available in the namespace.

update — replace an object via PUT. Requires the full object.

patch — partial modification via PATCH. From a security standpoint update and patch are equivalent — grant both or neither; tools differ in which they use (kubectl edit → patch, most controllers → update via informer-cached objects, kubectl apply → patch).

delete — remove a single named object.

deletecollection — remove all objects matching a selector in one call (kubectl delete pods --all uses it). This is the most commonly accidentally-granted destructive verb, because verbs: ["*"] includes it. A role that should clean up individual jobs rarely needs to be able to wipe every object of a kind in one request. Grant it deliberately or not at all.

The Special Verbs

These don't correspond to HTTP methods on the resource — they gate specific high-risk operations.

use — only meaningful for one thing in modern clusters: referencing specific resources that policy engines check, like securitycontextconstraints on OpenShift (and historically PodSecurityPolicies). Pod Security Admission replaced the PSP use-case upstream — see Pod Security Standards.

bind — permits creating RoleBindings/ClusterRoleBindings to a role even if you don't hold the role's permissions yourself. Without bind, Kubernetes only lets you bind roles whose permissions you already have (escalation prevention). With it, a user who can create bindings can grant cluster-admin to anyone. Treat bind on clusterroles as cluster-admin-adjacent.

escalate — permits editing a Role/ClusterRole to contain more permissions than you hold. Same escalation-prevention bypass as bind, but for modifying roles instead of binding them. Almost nothing legitimate needs this outside of RBAC-managing operators.

impersonate — act as another user, group, or ServiceAccount (kubectl --as=admin). Useful for testing RBAC (kubectl auth can-i --as=system:serviceaccount:app:deployer ...); catastrophic when granted broadly, since impersonating a privileged group is holding its power. Audit logs do record both identities, which is the only saving grace.

approve / sign (certificates.k8s.io) — gate CSR approval and signing. The chain from "can approve CSRs" to "can mint a client cert for any identity" is short; these belong to cluster machinery, not humans.

The Escalation Cheat Codes (What Auditors Look For)

If a subject holds any of the following, they can likely become cluster-admin:

1. bind or escalate on clusterroles
2. create on rolebindings/clusterrolebindings plus an existing powerful role to point at
3. impersonate on users/groups (especially system:masters)
4. update/patch on clusterroles they're bound to
5. create on pods in kube-system (mount the right ServiceAccount token)
6. list on secrets cluster-wide (read every token in the cluster)

I walk through real-world versions of these in RBAC misconfigurations that break production and the detection side in insider threat detection on Kubernetes.

Practical Verb Sets

Check effective permissions with kubectl auth can-i --list --as=<subject>, and generate least-privilege roles instead of hand-writing them — that's exactly what our Kubernetes RBAC Generator is for.

Frequently Asked Questions

What are all the Kubernetes RBAC verbs?

The standard set: get, list, watch, create, update, patch, delete, deletecollection. The special-purpose set: use (policy resources), bind and escalate (RBAC escalation controls), impersonate (identity assumption), and approve/sign for certificate signing requests. Subresources (like pods/exec, pods/log, <resource>/status) take the same verbs but are granted separately — create on pods/exec is what permits kubectl exec.

What's the difference between update and patch in RBAC?

Mechanically, update is a full-object PUT and patch is a partial modification. From a security perspective they're the same grant — anyone with patch can change anything update could. Grant them together; splitting them only causes confusing tool breakage (kubectl edit and apply use patch; many controllers use update).

Why is the list verb on Secrets dangerous?

Because list returns complete objects, including data. A subject with list on secrets cluster-wide can dump every credential in the cluster in one request — no get required. If something only needs to know which secrets exist, it still receives their contents; scope list on secrets as tightly as any read of the values themselves.

How do I check which verbs a user or ServiceAccount actually has?

kubectl auth can-i --list --as=<user> (or --as=system:serviceaccount:<ns>:<name>) prints the effective permission set; kubectl auth can-i delete pods -n prod --as=... answers a single question. For ongoing review, audit RoleBindings for the escalation verbs above — that short list finds most of what matters.

Want your cluster's RBAC audited against these patterns, or least-privilege roles designed for your teams? Get in touch.

Official References

• RBAC authorization — Role, ClusterRole and binding semantics
• Configure service accounts — token projection and the default service account