Mastering Kubernetes RBAC: From Basics to Advanced Auditing Tools

1. RBAC Basics

Kubernetes authentication and authorization are critical for any security system. Even non‑security engineers need to know whether their clusters have appropriate access controls. Kubernetes supports Role‑Based Access Control (RBAC) since version 1.6, allowing administrators to define precise permissions for users and service accounts.

2. RBAC Practice

RBAC policies are expressed through Role and ClusterRole objects that bind to resources such as ServiceAccount or groups. Each role follows the CRUD model and uses verbs like get to grant read access. For example, a ClusterRole that can

get

Secrets

might be defined as follows:

3. Auditing Importance

Auditing RBAC configurations is essential to verify that each service account or user has only the permissions it truly needs. Two audit modes are common: resource‑level audit (identifying high‑risk resources and who can access them) and account‑level audit (checking each account’s effective permissions).

Resource audit: verify who can access a specific Secret and ensure the least‑privilege principle.

Account audit: enumerate all users, groups, service accounts, and role bindings to confirm correct permissions within a namespace.

4. Kubectl can‑i

When installing additional tools is not possible, the built‑in kubectl auth can-i command can check permissions. Examples:

$ kubectl auth can-i get pods
yes

$ kubectl auth can-i "*" "*"
yes

List all permissions in a namespace:

$ kubectl auth can-i --list -n <namespace>

5. Kubectl who‑can

The who-can plugin (installable via Krew) shows which accounts have access to a specific resource. Installation: $ kubectl krew install who-can Example – who can get a secret named cluster-admin-creds in the secure namespace:

$ kubectl who-can get secret cluster-admin-creds -n secure
ROLEBINDING   NAMESPACE   SUBJECT                     TYPE          SA-NAMESPACE
unpriv_sa_binding secure   unprivileged-service-account ServiceAccount secure

CLUSTERROLEBINDING   SUBJECT          TYPE   SA-NAMESPACE
cluster-admin        system:masters   Group

Note: the tool only supports create, update, and delete verbs, not use.

6. Rakkess

The rakkess plugin, also installable via Krew, lists all permissions for a given account. Example – show current user’s permissions: $ kubectl rakkess Show permissions for a specific service account:

$ kubectl access-matrix --as system:serviceaccount:kube-ovn:ovn -n kube-ovn

7. RBack

rback

visualizes kubectl output as Graphviz .dot or image files. Example:

$ kubectl get sa,roles,rolebindings -n monitoring -o json | rback > rback.dot
$ kubectl get sa,roles,rolebindings -n monitoring -o json | rback | dot -Tpng > rback.png

8. RBAC‑View

rbac-view

is a web application that visualizes the relationship between accounts and permissions. Run it with:

$ kubectl rbac-view
Serving RBAC View at http://localhost:8800

Open the URL in a browser to explore the RBAC graph.

9. Ultimate Test

To definitively verify whether an account has a specific permission, use the --as flag with the appropriate API call. Example – check if the service account unprivileged-service-account in the secure namespace can get secret:

$ kubectl get secrets --as system:serviceaccount:secure:unprivileged-service-account -o yaml

10. Simulated Attack

Simulating an attack helps validate RBAC effectiveness. Steps:

Create a service account.

Create a role with the desired permissions.

Bind the role to the service account.

Deploy a pod that uses the service account.

Exec into the pod and attempt the operation (e.g., kubectl get pod).

Example commands:

$ kubectl create serviceaccount ncc-sa
$ kubectl create role ncc-role --verb=get --resource=pods -n test
$ kubectl create rolebinding ncc-rb --role=ncc-role --serviceaccount=test:ncc-sa -n test
$ kubectl run test-pod --image=busybox --serviceaccount=ncc-sa -n test -- sleep 3600
$ kubectl exec -it test-pod -n test -- /bin/sh
$ kubectl get pod

11. Summary

As clusters grow, RBAC configurations become increasingly complex. Too many roles make management error‑prone; too few roles lead to over‑privileged pods. A balanced approach is to template RBAC policies with tools like Ansible or Terraform, reducing manual effort and improving security.