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 ServiceAccounts currently bound to
cluster-admin(run on any machine with kubectl access): -
For each violating ServiceAccount, identify what access it truly needs by checking its namespace, name, and associated workloads (run on any machine with kubectl access):
-
Design least-privilege RBAC for that ServiceAccount by creating a dedicated
Role/ClusterRoleand binding (run on any machine with kubectl access). Example template (edit apiGroups, resources, verbs, and scope as required, then apply): -
After confirming the workload still functions with the new least-privilege Role/ClusterRole, delete the
cluster-adminbinding(s) that reference ServiceAccounts (run on any machine with kubectl access). For each violating ClusterRoleBindingCRB_NAMEfrom step 1: -
If a
cluster-adminClusterRoleBinding also includes non-ServiceAccount subjects (e.g., users/groups) that must be retained, recreate an equivalent binding without the ServiceAccounts before deleting the original (run on any machine with kubectl access): -
Verify no ServiceAccount is bound to
cluster-admin(run on any machine with kubectl access):The cluster is compliant when the output is exactly:
Using kubectl
Using kubectl
On any machine with kubectl access to the cluster:If you need to recreate least-privilege access, first define a narrowed ClusterRole and binding (example pattern, adjust rules to actual needs):Apply the least-privilege RBAC:Verification (cluster is compliant when this prints
- List ServiceAccounts bound to
cluster-admin:
- For each violating ClusterRoleBinding, delete it. Example (replace the name with each one you found):
is_compliant=true):Automation
Automation

