Kubernetes Access Review Management

Kubernetes Access Review Management is the practice of using Kubernetes' built-in review APIs — SubjectAccessReview, SelfSubjectAccessReview, LocalSubjectAccessReview, and SelfSubjectRulesReview — to verify, both proactively and retrospectively, exactly what a given identity is authorized to do within a cluster. These APIs turn authorization from something that can only be inferred by reading YAML into something that can be directly queried and tested, which is the foundation for both everyday troubleshooting and formal periodic access audits.

The Review API Family

SubjectAccessReview

SubjectAccessReview checks whether an arbitrary named subject — a user, group, or service account — is authorized to perform a specific verb on a specific resource, and is the API underlying kubectl auth can-i --as. It requires the caller to hold permission to create SubjectAccessReview objects, since it exposes information about other identities' access.

apiVersion: authorization.k8s.io/v1
kind: SubjectAccessReview
spec:
  user: system:serviceaccount:payments:billing-worker
  resourceAttributes:
    namespace: payments
    verb: delete
    resource: pods

SelfSubjectAccessReview and SelfSubjectRulesReview

SelfSubjectAccessReview performs the same check but implicitly for the caller's own identity, requiring no special permission beyond the ability to create the review object itself, which makes it safe to expose broadly. SelfSubjectRulesReview goes further, returning the full set of rules the caller's identity holds within a given namespace, useful for building UIs that adapt to a user's actual permissions.

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

LocalSubjectAccessReview

LocalSubjectAccessReview mirrors SubjectAccessReview but is scoped to a single namespace, useful when the reviewer itself only holds namespace-scoped permission to perform reviews and should not be able to query access outside that namespace.

Using Access Reviews for Verification

Confirming a Role Grants What Was Intended

After creating or modifying a Role or ClusterRole, running kubectl auth can-i for each verb and resource the role was designed to grant — and, just as importantly, for verbs it was designed to exclude — is the most direct way to confirm the change behaves as intended before relying on it in production.

kubectl auth can-i create secrets --namespace payments --as system:serviceaccount:payments:billing-worker
kubectl auth can-i delete secrets --namespace payments --as system:serviceaccount:payments:billing-worker

Investigating Access-Denied Incidents

When a workload or user reports an unexpected permission error, reconstructing the exact call that failed (verb, resource, subresource, namespace) and reviewing it against the identity's actual bindings using SubjectAccessReview isolates whether the issue is a missing rule, a missing subresource grant, or a binding pointing at the wrong role.

Periodic Access Review Processes

Enumerating Rather Than Spot-Checking

While can-i checks are ideal for verifying a single specific permission, periodic governance reviews are better served by enumerating all RoleBinding and ClusterRoleBinding objects and their subjects directly, then cross-referencing against a current roster of active users, groups, and workloads, catching stale grants that a targeted can-i check would never surface because nobody thought to ask about them.

kubectl get rolebindings,clusterrolebindings --all-namespaces -o json | \
  jq '.items[].subjects[]?.name' | sort -u

Automating Review Cadence

Because manual review does not scale well against a growing number of bindings, many organizations script periodic exports of all bindings and their subjects, diffing against the previous review to highlight only what has changed since the last cycle, rather than re-reviewing the entire binding set from scratch each time.

Limitations of Access Review APIs

They Reflect Current State, Not Historical State

Access review APIs answer "what can this identity do right now," not "what did this identity do in the past" — that question belongs to audit logs, which record actual API calls and their authorization outcomes, and the two data sources are complementary rather than interchangeable.

They Do Not Account for Data-Level Authorization

A SubjectAccessReview confirms whether an identity can call a given API operation, but says nothing about application-level authorization layered on top — a service account permitted to get a ConfigMap object gives no information about whether the application logic consuming that config further restricts what any individual caller can see or change within it.