More Info:
The cluster-admin ClusterRole grants unrestricted superuser access. Bind it only to subjects that genuinely require full cluster control.Risk Level
CriticalAddress
SecurityCompliance Standards
- CIS Kubernetes
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
List all ClusterRoleBindings to
cluster-admin- Run on: any machine with kubectl access
-
Review each subject’s actual access needs (manual decision)
- Run on: any machine with kubectl access
For each ClusterRoleBinding identified in step 1, inspect details and note the subjects:
Manually determine, based on your org’s policies and the subject’s responsibilities, whether they truly require full cluster-wide admin, or only subset permissions (e.g., namespace admin, read-only, ops). - Run on: any machine with kubectl access
-
Identify or design least-privilege roles for subjects that do NOT need cluster-admin
- Run on: any machine with kubectl access
If a subject should have reduced permissions, either use an existing ClusterRole/Role or draft one. For example, create a more limited ClusterRole manifest file (edit rules according to your needs):
- Run on: any machine with kubectl access
-
Create appropriate RoleBindings/ClusterRoleBindings to the reduced-privilege role
- Run on: any machine with kubectl access
For each subject that should no longer usecluster-admin, bind them to the least-privilege role you chose or created. For example, to bind a user to therestricted-adminClusterRole cluster-wide:
Replace<subject>and<subject-name>with the actual subject identifier. - Run on: any machine with kubectl access
-
Remove unnecessary
cluster-adminClusterRoleBindings- Run on: any machine with kubectl access
After confirming the subject has appropriate alternative access and no longer needscluster-admin, delete the old binding:
Only retaincluster-adminbindings for subjects that you explicitly decided must keep full cluster control. - Run on: any machine with kubectl access
-
Verification
- Run on: any machine with kubectl access
Re-run the audit logic and confirm no non-cluster-adminrole names are bound tocluster-admin:
Manually check that any remainingcluster-adminbindings are only for subjects you intentionally approved for full cluster-admin access. - Run on: any machine with kubectl access
Using kubectl
Using kubectl
On any machine with Bind the subject to the lower‑privileged Role (fill in actual subject kind/name):Repeat for each unnecessary
kubectl access:- List all ClusterRoleBindings that reference
cluster-admin
- Inspect each non‑default binding to
cluster-adminand its subjects
- For each subject that does not truly need full cluster‑admin, create or use a less‑privileged ClusterRole/Role and bind that instead. Example – if a subject only needs namespace‑scoped access:
- Once all necessary replacement bindings are in place and validated, delete the unneeded
cluster-adminClusterRoleBindings:
cluster-admin binding.- Verification (adapted from the audit):
Automation
Automation

