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 ServiceAccounts currently bound to cluster-admin (run on any machine with kubectl access):
  2. 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):
  3. Design least-privilege RBAC for that ServiceAccount by creating a dedicated Role/ClusterRole and binding (run on any machine with kubectl access). Example template (edit apiGroups, resources, verbs, and scope as required, then apply):
  4. After confirming the workload still functions with the new least-privilege Role/ClusterRole, delete the cluster-admin binding(s) that reference ServiceAccounts (run on any machine with kubectl access). For each violating ClusterRoleBinding CRB_NAME from step 1:
  5. If a cluster-admin ClusterRoleBinding 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):
  6. Verify no ServiceAccount is bound to cluster-admin (run on any machine with kubectl access):
    The cluster is compliant when the output is exactly:
On any machine with kubectl access to the cluster:
  1. List ServiceAccounts bound to cluster-admin:
  1. For each violating ClusterRoleBinding, delete it. Example (replace the name with each one you found):
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 is_compliant=true):