Skip to main content

More Info:

The RBAC role cluster-admin provides wide-ranging powers over the environment and should be used only where and when needed.

Risk Level

Critical

Address

Security

Compliance Standards

  • CIS Kubernetes

Triage and Remediation

Remediation

Manual Steps

  1. List all clusterrolebindings that grant cluster-admin
    • Run on: any machine with kubectl access
  2. Identify which subjects truly require cluster-admin
    • Run on: any machine with kubectl access
    • Inspect each binding that references cluster-admin and note its subjects and usage context:
    • For each binding where roleRef.name: cluster-admin, determine (by policy/with app owners) if the service account, user, or group truly needs full cluster-wide admin or can be restricted (for example: namespace-scoped admin, read-only, or limited custom roles).
  3. Create or select a lower-privilege role for each subject that doesn’t need cluster-admin
    • Run on: any machine with kubectl access
    • To bind to the built-in admin role in a specific namespace (example team-a and user alice):
    • Or create a custom, least-privilege ClusterRole (edit rules as needed):
    • Then bind that role to the subject instead of cluster-admin (example service account app-sa in namespace team-a):
  4. Carefully migrate off cluster-admin for each subject
    • Run on: any machine with kubectl access
    • For each subject currently bound to cluster-admin, ensure its new binding (from step 3) is in place, then test access (have the subject’s workload or user confirm required operations still work).
    • Example: check current bindings for a given subject before deletion (replace alice):
  5. Remove unnecessary cluster-admin clusterrolebindings
    • Run on: any machine with kubectl access
    • Once a subject no longer needs cluster-admin, delete its binding. Replace <binding-name> with the exact name from step 1 or 4:
    • If multiple subjects share one cluster-admin binding and only some need it, recreate a narrower binding for those that still need it, and then delete the original broad binding.
  6. Verification
    • Run on: any machine with kubectl access
    • Re-run the audit logic and confirm that no non-cluster-admin role name is bound to the cluster-admin ClusterRole:
    • The output should show no lines where role_binding: cluster-admin is paired with is_compliant: false.
On any machine with kubectl access:
  1. List all ClusterRoleBindings that reference cluster-admin and see their subjects
  1. For each non‑cluster-admin binding that grants cluster-admin, inspect details to decide if it really needs full privileges:
  1. If a subject should have reduced privileges, first bind it to a less‑privileged ClusterRole (example: view; adjust role/subject to your needs):
  • Example manifest to create a safer ClusterRoleBinding:
Apply it:
  1. Once you have confirmed the replacement access works, remove the unnecessary cluster-admin binding:
Repeat steps 2–4 for every ClusterRoleBinding where .roleRef.name == cluster-admin and the subject is not supposed to be fully privileged.
  1. Verification (same logic as the audit, to ensure no non‑cluster-admin binding grants cluster-admin):

Additional Reading: