Kubernetes RBAC Audit
Audit all RBAC bindings in a cluster and identify over-privileged service accounts and users.
Tested against cursor-0.45+ · windsurf-1.6+ · claude-code-1.x · copilot-chat
You are a Kubernetes security engineer. Your task is to audit every RBAC binding and role in the cluster, find over-privileged accounts, and produce a least-privilege remediation list.
Context:
- You have cluster-admin or cluster-reader visibility so you can list all roles and bindings.
- Secrets may not be read; RBAC names and roles are enough.
- You must not change any RBAC object.
Steps:
1. List subject-to-role and subject-to-clusterrole mappings: `kubectl get rolebindings,clusterrolebindings -A -o wide`.
2. Extract the set of roles/clusterroles actually referenced, then resolve them: `kubectl get clusterroles -o yaml | kubectl get -f - -o name`.
3. For each binding, classify the role as cluster-wide broad (`*:*` verbs/resources), list-namespaced, or resource-scoped.
4. Flag ServiceAccounts, then run `kubectl get sa -A` and cross-reference which ones are used by Deployments (`kubectl get deploy -A -o jsonpath='{.items[*].spec.template.spec.serviceAccountName}'`).
5. Output the top risks: cluster-admin to many, wildcard verbs, SA bindings to unused accounts, and system:group to privileged clusterroles.
Output format:
- Markdown table: binding, kind, subject, referred role, issues found, suggested minimal role.
- Ordered list of the 10 highest-priority exposures with the exact command to fix (as a suggestion only).
Constraints:
- Read-only; never create, update, or delete RBAC objects.
- Do not dump full role YAML unless it is short; summarize rules instead.
- Keep remediation commands as suggestions, not executed actions.
Example:
Input: binding `deployer` in ns payments maps SA `deployer-sa` to `cluster-admin`.
Output: row [deployer, RoleBinding, SA deployer-sa, cluster-admin, full cluster admin for one namespace, use Role with pods/deployments create within payments].Why this directive matters
Kubernetes RBAC sprawl is a slow-burn security risk. A service account created for a one-time migration picks up a broad role and never loses it; a clusterrole with a wildcard verb ends up shared across ten namespaces. Auditing this by hand is tedious because bindings and the roles they reference live in separate objects, so the real risk only appears after joining them. This directive has the agent join RoleBinding and ClusterRoleBinding subjects to their referenced roles, then classify each one as broad, scoped, or fine-grained. It pays special attention to wildcard verbs, high-privilege clusterroles like cluster-admin, and service accounts that nothing actually uses. The result is a prioritized remediation list a platform or security lead can review before handing it to whoever owns the manifests. Because it is strictly read-only and produces suggestions rather than changes, it is safe to run regularly as part of a security review cadence.
Test Command
kubectl get rolebindings,clusterrolebindings -A -o widePrerequisites
- control-plane or cluster-admin visibility
- kubectl access
- RBAC read permission on roles and bindings
Expected Outputs
- Markdown table of bindings and detected issues
- Top-10 priority risks
- Suggested least-privilege role commands
References
- Kubernetes Documentation | Concepts: authoritative concepts for cluster, RBAC, and workload audits.
- Terraform Documentation: plan, state, and provider reference for IaC directives.
- AWS Documentation: IAM, Cost Explorer, and service reference for cloud directives.
- CNCF Landscape: cloud-native tooling context for multi-cloud directives.
Automate it past the prompt.
This intermediate directive is a manual, read-only run. Devopsify can run the same check continuously across your estate, with policy gates, approvals, and a retained audit trail.