Kubernetes Resource Verb Access

Kubernetes Resource Verb Access is the model by which RBAC expresses permitted actions against API resources as a fixed vocabulary of verbs, each corresponding to a specific HTTP method and semantic operation on the Kubernetes API. Understanding exactly what each verb permits, and how verbs map onto the underlying REST operations, is essential for granting access that is neither more nor less than what a subject actually needs.

The Standard Verb Set

Read Verbs: get, list, watch

get retrieves a single object by name; list retrieves a collection of objects, optionally filtered by label or field selector; watch opens a long-lived connection that streams create, update, and delete events for a collection as they happen. A read-only client typically needs all three, since list alone provides only a point-in-time snapshot with no mechanism to observe subsequent changes.

kubectl auth can-i list pods --namespace payments
kubectl auth can-i watch pods --namespace payments

Write Verbs: create, update, patch, delete, deletecollection

create corresponds to an HTTP POST creating a new object; update to a PUT replacing an object's entire spec; patch to a PATCH applying a partial modification (strategic merge, JSON merge, or JSON patch, depending on content type); delete removes a single named object; deletecollection removes every object matching a list query in one call. Because kubectl apply uses patch semantics internally, a role granting only update without patch will block kubectl apply even though it appears to grant write access.

Verbs Beyond CRUD

deletecollection as a Distinct Risk

deletecollection allows removing an entire set of matching objects — every pod in a namespace, for instance — in a single API call, which is materially more consequential than delete and should not be granted merely because delete is already present in a rule.

rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["delete"]        # single-object deletion only

The impersonate Verb

impersonate permits a subject to act as another User, Group, or ServiceAccount by setting impersonation headers on a request, effectively borrowing that identity's authorization for the duration of the call — a powerful capability typically reserved for automation tooling operating on behalf of other identities, not general-purpose grants.

The escalate and bind Verbs

escalate allows a subject to create or modify Role/ClusterRole objects that grant permissions beyond what the subject itself currently holds, bypassing RBAC's default privilege-escalation prevention; bind allows a subject to create bindings referencing a role even if the subject lacks that role's permissions themselves. Both are narrow, high-consequence verbs intended for platform-administration tooling rather than typical operator roles.

Verb Access on Subresources

Subresource Verbs Are Independent

A subresource such as pods/exec supports create (to open an exec session) and behaves as its own resource entirely separate from the parent pods resource; a role with get, list, and watch on pods grants no ability whatsoever to exec, attach, or port-forward into those same pods.

rules:
- apiGroups: [""]
  resources: ["pods/portforward"]
  verbs: ["create"]

Status and Scale Subresources

deployments/status and deployments/scale are separately gated subresources allowing status updates or replica-count changes without granting full write access to the deployment's pod template, which is useful for building narrowly scoped autoscaling or status-reporting automation.

Verifying Effective Verb Access

Programmatic Checks

The SubjectAccessReview API allows checking any specific verb-resource-subresource combination for any subject programmatically, which is the authoritative way to confirm what a role actually grants rather than inferring it from the YAML definition alone.

kubectl auth can-i create pods/exec --namespace payments --as system:serviceaccount:payments:debug-tool

Verb Access Is Purely Additive

Because RBAC has no explicit deny mechanism, a subject's effective verb access on any resource is the union of every rule across every role bound to them; removing an unwanted verb requires finding and modifying every rule that grants it, not simply adding a more restrictive rule elsewhere.