More Info:
Verifies no ServiceAccount is bound to the cluster-admin ClusterRole. Such a binding hands full cluster control to any workload using that account.Risk Level
CriticalAddress
SecurityCompliance Standards
- Cloudanix Best Practice
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
List all ClusterRoleBindings that bind ServiceAccounts to
cluster-admin(run on any machine with kubectl access): -
For each violating ServiceAccount, inspect what it is used by so you can design a narrower Role/ClusterRole (run on any machine with kubectl access, replace
NAMESPACEandSA_NAMEfrom step 1 output): -
Create a least-privilege Role or ClusterRole with exactly the permissions the workload needs (example skeleton; edit rules before applying, run on any machine with kubectl access):
-
If the ServiceAccount truly requires cluster‑scope privileges (rare), create a narrowly scoped ClusterRole instead (edit rules before applying, run on any machine with kubectl access):
-
After confirming workloads function with the new least‑privilege bindings, delete each offending
cluster-adminClusterRoleBinding (run on any machine with kubectl access, substitute thenamefrom step 1 output): -
Verify no ServiceAccount remains bound to
cluster-admin(run on any machine with kubectl access):A compliant cluster prints:
Using kubectl
Using kubectl
On any machine with kubectl access:If you need to recreate a narrower-scope binding for the same ServiceAccount, define a dedicated Apply the narrowed permissions:
- Identify ServiceAccounts bound to
cluster-admin:
- For each violating
ClusterRoleBinding, delete it (replaceBINDING_NAMEwith the name from step 1):
ClusterRole or Role and binding, for example:- Verification (on any machine with kubectl access):
Automation
Automation

