Abstract

Kubernetes RBAC policies accumulate permissions the same way firewall rules do: incrementally, under deadline pressure, and rarely with a cleanup pass. Production clusters routinely carry ClusterRoles granting wildcard verbs on all resources, service accounts with cluster-admin bindings, and namespace-scoped roles that exceed any reasonable least-privilege interpretation. Systematic RBAC auditing is not a one-time exercise - it requires tooling, defined criteria, and a repeatable remediation workflow integrated into the platform engineering lifecycle.

Mapping the Permission Graph

The first challenge is visibility. kubectl get clusterrolebindings,rolebindings -A -o yaml produces the raw data, but parsing effective permissions for every subject - users, groups, and service accounts - requires aggregating across role inheritance and group membership. Tools like rbac-tool (from Alcide, now maintained by the community) and rakkess generate subject-to-permission matrices that make over-permission visible at a glance. kubectl-who-can inverts the query: given a resource and verb, it lists every subject that can perform that action, which is useful for auditing sensitive operations like secrets:get or pods/exec.

Identifying wildcard roles should be the first filter. Any Role or ClusterRole with verbs: ["*"] or resources: ["*"] is a candidate for decomposition. The legitimate uses are narrow: cluster-admin for break-glass accounts, and aggregated ClusterRoles used as base templates. Everything else warrants review.

Service Account Hygiene

Service accounts are the most common RBAC attack surface in production clusters. Default service account tokens are mounted automatically in every pod unless automountServiceAccountToken: false is set on the pod spec or the service account itself. Many workloads that make no Kubernetes API calls carry a token that could be used by a compromised container to query the API server.

The remediation pattern is straightforward: set automountServiceAccountToken: false on the default service account in every namespace, create dedicated service accounts per workload with the minimum required permissions, and audit token usage against API server audit logs to confirm which service accounts are actually making API calls. The Kubernetes audit log (audit.k8s.io/v1) records the userAgent and user.name for every API server request, making it possible to identify service accounts with zero API activity - candidates for token disabling or role stripping.

Admission Control and Policy Enforcement

Auditing without enforcement is incomplete. OPA Gatekeeper and Kyverno both support policies that reject or warn on RBAC configurations violating defined constraints - for example, blocking creation of ClusterRoles with wildcard resource verbs, or requiring that new RoleBindings in production namespaces pass a review annotation. These policies run as admission webhooks, catching violations before they reach etcd.

For clusters already carrying legacy over-permission, a progressive approach works better than bulk remediation: flag existing violations as warnings in the admission controller, require that any new or modified RBAC object meets the policy, and address existing violations on a rolling schedule tied to service team reviews. Tracking open violations as OPA Gatekeeper ConstraintViolation resources provides a queue that can be surfaced in a security dashboard alongside remediation ownership.