More Info:
The RBAC role cluster-admin provides wide-ranging powers over the environment and should be used only where and when needed.Risk Level
CriticalAddress
SecurityCompliance Standards
- CIS Kubernetes
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
List all clusterrolebindings that grant
cluster-admin- Run on: any machine with kubectl access
-
Identify which subjects truly require
cluster-admin- Run on: any machine with kubectl access
- Inspect each binding that references
cluster-adminand note its subjects and usage context:
- For each binding where
roleRef.name: cluster-admin, determine (by policy/with app owners) if the service account, user, or group truly needs full cluster-wide admin or can be restricted (for example: namespace-scoped admin, read-only, or limited custom roles).
-
Create or select a lower-privilege role for each subject that doesn’t need
cluster-admin- Run on: any machine with kubectl access
- To bind to the built-in
adminrole in a specific namespace (exampleteam-aand useralice):
- Or create a custom, least-privilege ClusterRole (edit rules as needed):
- Then bind that role to the subject instead of
cluster-admin(example service accountapp-sain namespaceteam-a):
-
Carefully migrate off
cluster-adminfor each subject- Run on: any machine with kubectl access
- For each subject currently bound to
cluster-admin, ensure its new binding (from step 3) is in place, then test access (have the subject’s workload or user confirm required operations still work). - Example: check current bindings for a given subject before deletion (replace
alice):
-
Remove unnecessary
cluster-adminclusterrolebindings- Run on: any machine with kubectl access
- Once a subject no longer needs
cluster-admin, delete its binding. Replace<binding-name>with the exact name from step 1 or 4:
- If multiple subjects share one
cluster-adminbinding and only some need it, recreate a narrower binding for those that still need it, and then delete the original broad binding.
-
Verification
- Run on: any machine with kubectl access
- Re-run the audit logic and confirm that no non-
cluster-adminrole name is bound to thecluster-adminClusterRole:
- The output should show no lines where
role_binding: cluster-adminis paired withis_compliant: false.
Using kubectl
Using kubectl
On any machine with kubectl access:Apply it:Repeat steps 2–4 for every ClusterRoleBinding where
- List all ClusterRoleBindings that reference
cluster-adminand see their subjects
- For each non‑
cluster-adminbinding that grantscluster-admin, inspect details to decide if it really needs full privileges:
- If a subject should have reduced privileges, first bind it to a less‑privileged ClusterRole (example:
view; adjust role/subject to your needs):
- Example manifest to create a safer ClusterRoleBinding:
- Once you have confirmed the replacement access works, remove the unnecessary
cluster-adminbinding:
.roleRef.name == cluster-admin and the subject is not supposed to be fully privileged.- Verification (same logic as the audit, to ensure no non‑
cluster-adminbinding grantscluster-admin):
Automation
Automation

