Kubernetes RBAC Audit Checklist: Find Overprivileged Accounts in 30 Minutes

Kubernetes RBAC is configured at deployment and rarely revisited. Helm charts grant overly broad permissions for ease of installation. Debugging sessions add temporary bindings that become permanent. The result: most production clusters have at least one service account that can read all secrets or patch deployments cluster-wide. The 2022 Twistlock / Palo Alto Cloud-Native Security Report found that 58% of Kubernetes clusters had at least one service account with cluster-admin or equivalent. A compromised pod with an overprivileged service account becomes immediate cluster compromise.

You need kubectl configured with cluster-admin access and jq installed for JSON parsing. Confirm access: kubectl auth can-i '' '' --all-namespaces should return 'yes'. For large clusters, run the audit commands against a read-only kubeconfig to avoid accidental writes. Estimated time: 30 minutes for a cluster with fewer than 50 namespaces.

This is the highest-severity check. Anything with cluster-admin can read all secrets, delete workloads, and escalate to node compromise.

List all cluster-admin principals:

kubectl get clusterrolebindings -o json | \
  jq -r '.items[] | select(.roleRef.name=="cluster-admin") | 
    "Binding: " + .metadata.name + 
    "  Subjects: " + ([.subjects[]? | .kind + "/" + .name] | join(", "))'

Expected output: Only your break-glass admin users and the system:masters group for control plane components. Flag anything else immediately.

List all RoleBindings and ClusterRoleBindings that reference the cluster-admin role:

kubectl get rolebindings,clusterrolebindings \
  --all-namespaces -o json | \
  jq '.items[] | select(.roleRef.name=="cluster-admin") | 
    {binding: .metadata.name, namespace: .metadata.namespace, subjects: .subjects}'

Wildcard verbs ('') or wildcard resources ('') grant more than almost any legitimate workload needs.

Find all ClusterRoles with wildcard verbs:

kubectl get clusterroles -o json | \
  jq '.items[] | select(.rules[]?.verbs[]? == "*") | .metadata.name'

Find all ClusterRoles with wildcard resources:

kubectl get clusterroles -o json | \
  jq '.items[] | select(.rules[]?.resources[]? == "*") | .metadata.name'

Find Roles (namespace-scoped) with wildcards:

kubectl get roles --all-namespaces -o json | \
  jq '.items[] | select(.rules[]?.verbs[]? == "*" or .rules[]?.resources[]? == "*") | 
    {name: .metadata.name, namespace: .metadata.namespace}'

For each result, enumerate what service accounts or users are bound to that role:

kubectl get clusterrolebindings,rolebindings \
  --all-namespaces -o json | \
  jq '.items[] | select(.roleRef.name=="ROLE_NAME_HERE") | 
    {binding: .metadata.name, subjects: .subjects}'

Any role with get, list, or watch on secrets can read credentials across namespaces. This is the most commonly exploited misconfiguration in container breakout scenarios.

Find roles that can read secrets cluster-wide:

kubectl get clusterroles -o json | \
  jq '.items[] | select(
    .rules[]? | 
    (.resources[]? == "secrets" or .resources[]? == "*") and 
    (.verbs[]? == "get" or .verbs[]? == "list" or .verbs[]? == "*")
  ) | .metadata.name'

Check if the default service account in a namespace can read secrets:

kubectl auth can-i get secrets \
  --as=system:serviceaccount:NAMESPACE:default \
  -n NAMESPACE

This should return 'no' for every namespace. If it returns 'yes', remove or restrict the default service account binding immediately.

Service accounts accumulate over time. Each unused account is an attack surface if a token is extracted from a compromised node.

List all service accounts across namespaces:

kubectl get serviceaccounts --all-namespaces \
  -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name'

Find service accounts with no running pods using them:

# Get all SA names in use
kubectl get pods --all-namespaces -o json | \
  jq -r '.items[] | .metadata.namespace + "/" + .spec.serviceAccountName' | \
  sort -u > /tmp/sa_in_use.txt

# Get all SA names that exist
kubectl get serviceaccounts --all-namespaces -o json | \
  jq -r '.items[] | .metadata.namespace + "/" + .metadata.name' | \
  sort -u > /tmp/sa_all.txt

# Find orphans
comm -23 /tmp/sa_all.txt /tmp/sa_in_use.txt

Filter out the default, kube-system, and cert-manager service accounts, then review the remainder for deletion.

Some permissions don't look dangerous in isolation but enable privilege escalation.

Dangerous permission combinations to check for:

Check if any service account can create pods (potential secret exfiltration):

for ns in $(kubectl get ns -o jsonpath='{.items[*].metadata.name}'); do
  for sa in $(kubectl get sa -n $ns -o jsonpath='{.items[*].metadata.name}'); do
    result=$(kubectl auth can-i create pods \
      --as=system:serviceaccount:$ns:$sa -n $ns 2>/dev/null)
    [ "$result" = "yes" ] && echo "$ns/$sa can create pods"
  done
done

Check for bind/escalate/impersonate permissions:

kubectl get clusterroles -o json | \
  jq '.items[] | select(
    .rules[]?.verbs[]? == "bind" or 
    .rules[]?.verbs[]? == "escalate" or 
    .rules[]?.verbs[]? == "impersonate"
  ) | .metadata.name'

Remove a ClusterRoleBinding:

kubectl delete clusterrolebinding BINDING_NAME

Remove a subject from a ClusterRoleBinding (edit in place):

kubectl edit clusterrolebinding BINDING_NAME
# Remove the subject entry from the subjects: array

Restrict a wildcard ClusterRole to specific verbs:

kubectl edit clusterrole ROLE_NAME
# Change verbs: ["*"] to verbs: ["get", "list", "watch"]

Delete an unused service account (after confirming no pods use it):

kubectl delete serviceaccount SA_NAME -n NAMESPACE

Disable automounting of service account tokens for a deployment:

# In pod spec or service account spec
automountServiceAccountToken: false

Create a dedicated service account instead of using default:

kubectl create serviceaccount my-app-sa -n my-namespace
# Update deployment to reference it
kubectl set serviceaccount deployment/my-app my-app-sa -n my-namespace

A one-time audit decays quickly. Implement these controls to maintain a clean RBAC posture:

Admission control: Use OPA/Gatekeeper or Kyverno policies to block creation of ClusterRoleBindings granting cluster-admin outside approved namespaces. Example Kyverno policy:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-cluster-admin
spec:
  validationFailureAction: Enforce
  rules:
    - name: no-cluster-admin-binding
      match:
        resources:
          kinds: [ClusterRoleBinding]
      validate:
        message: "cluster-admin bindings require approval"
        deny:
          conditions:
            - key: "{{request.object.roleRef.name}}"
              operator: Equals
              value: cluster-admin

Alerting: Use Falco rule k8s_cluster_admin_binding to alert on runtime creation of cluster-admin bindings.

Quarterly re-audit: Schedule a recurring audit using this checklist. Any new binding added since the last audit that grants wildcard or cluster-admin permissions requires documented justification.

Copy this table into a Google Sheet or Confluence page after completing the audit:

Target: zero Critical findings, High findings remediated within 7 days, Medium within 30 days.