Skip to main content

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

Critical

Address

Security

Compliance Standards

  • Cloudanix Best Practice

Triage and Remediation

Remediation

Manual Steps

  1. List all ClusterRoleBindings that bind ServiceAccounts to cluster-admin (run on any machine with kubectl access):
  2. 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 NAMESPACE and SA_NAME from step 1 output):
  3. 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):
  4. 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):
  5. After confirming workloads function with the new least‑privilege bindings, delete each offending cluster-admin ClusterRoleBinding (run on any machine with kubectl access, substitute the name from step 1 output):
  6. Verify no ServiceAccount remains bound to cluster-admin (run on any machine with kubectl access):
    A compliant cluster prints:
On any machine with kubectl access:
  1. Identify ServiceAccounts bound to cluster-admin:
  1. For each violating ClusterRoleBinding, delete it (replace BINDING_NAME with the name from step 1):
If you need to recreate a narrower-scope binding for the same ServiceAccount, define a dedicated ClusterRole or Role and binding, for example:
Apply the narrowed permissions:
  1. Verification (on any machine with kubectl access):