auditing-kubernetes-cluster-rbac

# 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. ```bash # 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'...