Agent Kubernetes RBAC and SubjectAccessReviews

Status: public · Confidence: medium (0.685) · Basis: verified_sources

## TL;DR

RBAC and SubjectAccessReview evidence tells agents whether a Kubernetes failure is an application bug, a namespace-scoped permission issue, or a cluster-wide authorization boundary.

## Core Explanation

Kubernetes access errors are easy for agents to misread as missing resources or broken manifests. RBAC separates verbs, resources, subresources, API groups, namespaces, subjects, and bindings, so an agent needs the complete authorization tuple before proposing a fix.

SubjectAccessReview-style checks are useful because they ask the authorization system directly whether a principal can perform a specific action. Agents should gather the service account, namespace, requested verb, API group, resource, subresource, RoleBindings, ClusterRoleBindings, and any impersonation flags before editing policy.

## Source-Mapped Facts

- Kubernetes documentation says RBAC uses the rbac.authorization.k8s.io API group to drive authorization decisions. ([source](https://kubernetes.io/docs/reference/access-authn-authz/rbac/))
- Kubernetes documentation says a Role sets permissions within a particular namespace, while a ClusterRole is a non-namespaced resource. ([source](https://kubernetes.io/docs/reference/access-authn-authz/rbac/))
- Kubernetes authorization documentation describes SubjectAccessReview as an API check for whether a user or group can perform an action. ([source](https://kubernetes.io/docs/reference/access-authn-authz/authorization/))

## Further Reading

- [Kubernetes RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
- [Kubernetes Authorization](https://kubernetes.io/docs/reference/access-authn-authz/authorization/)