Auditing Kubernetes Cluster RBAC

When to Use

• When performing security assessments of Kubernetes clusters (EKS, GKE, AKS, or self-managed)
• When validating that RBAC policies enforce least privilege for users and service accounts
• When investigating potential lateral movement or privilege escalation within a Kubernetes cluster
• When compliance audits require documentation of access controls and permissions
• When onboarding new teams to a shared cluster and defining appropriate RBAC policies

Do not use for network policy auditing (use Cilium or Calico network policy tools), for container image scanning (use Trivy or Grype), or for runtime security monitoring (use Falco or Sysdig Secure).

Prerequisites

• kubectl configured with cluster-admin or equivalent read permissions to the target cluster
• rbac-tool installed (kubectl krew install rbac-tool or binary from GitHub)
• KubiScan installed (pip install kubiscan)
• Kubeaudit installed (brew install kubeaudit or from GitHub releases)
• Access to the cluster's audit logs for correlating RBAC findings with actual API access

Workflow

Step 1: Enumerate ClusterRoles and Roles with Dangerous Permissions

Identify roles with wildcard permissions, secret access, pod exec, or escalation capabilities.

# List all ClusterRoles with wildcard verb access
kubectl get clusterroles -o json | python3 -c "
import json, sys
data = json.load(sys.stdin)
for role in data['items']:
    name = role['metadata']['name']
    for rule in role.get('rules', []):
        verbs = rule.get('verbs', [])
        resources = rule.get('resources', [])
        if '*' in verbs or '*' in resources:
            print(f'ClusterRole: {name}')
            print(f'  Verbs: {verbs}')
            print(f'  Resources: {resources}')
            print(f'  API Groups: {rule.get(\"apiGroups\", [])}')
            print()
"