Ensure The Cluster-Admin Role Is Only Used Where Required

More Info:

The cluster-admin ClusterRole grants unrestricted access to the entire cluster. It should only be bound to principals that strictly require full administrative control.

Risk Level

Critical

Address

Security

Compliance Standards

CIS AKS

Triage and Remediation

Remediation

Remediation

Manual Steps

List all cluster-admin bindings and their subjects
- Run on: any machine with kubectl access
- Command:
```
kubectl get clusterrolebindings -o wide | grep 'cluster-admin'
kubectl get clusterrolebindings -o yaml | grep -A10 -B2 'name: cluster-admin'
```
- Purpose: identify every ClusterRoleBinding that grants cluster-admin and who/what it is bound to (users, groups, service accounts).
For each binding, understand what is using it and why
- For each binding name found (e.g. cluster-admin, aks-cluster-admin-binding, etc.), inspect details:
```
kubectl get clusterrolebinding <binding-name> -o yaml
```
- Map each subject to:
  - Human user / group (e.g. corporate IdP group)
  - Service account (note its namespace and owning deployment/workload)
  - System or add-on component (e.g. CNI, Ingress, monitoring)
- Check your internal documentation, IaC (Helm, Terraform, etc.), or platform docs to see why this binding was created.
Decide if full cluster-admin is strictly necessary for each subject
For each subject in each binding, ask:
- Does it require cluster-wide, unrestricted access (e.g. break-glass admin, platform SRE)?
- Is its actual function limited (e.g. namespaced app, read-only monitor, single-namespace operator)?
- Is there a documented support / vendor requirement for cluster-admin, or can it be scoped down (namespace-scoped or specific API groups/resources/verbs)?
- If multiple subjects are in one binding, evaluate each individually; you may need to split them into separate bindings with different roles.

Design and apply least-privilege alternatives where possible

If cluster-admin is not strictly required, create or reuse a less-privileged ClusterRole/Role that matches the real needs. Examples (adapt to your case):

# Example: read-only cluster-wide role
kubectl apply -f - <<'EOF'
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: readonly-cluster
rules:
  - apiGroups: [""]
    resources: ["pods","services","configmaps","namespaces"]
    verbs: ["get","list","watch"]
EOF

Bind that role to the subject instead of cluster-admin (adjust kind, name, namespace as identified in step 2):

kubectl apply -f - <<'EOF'
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: readonly-cluster-binding
subjects:
  - kind: User
    name: <user-identifier>
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: readonly-cluster
EOF

For service accounts that only need namespace access, prefer Role + RoleBinding in that namespace.

Remove or narrow the cluster-admin bindings
- After confirming the replacement access works (functional tests, user confirmation, or workload logs), remove or adjust the cluster-admin binding:
  - To completely remove a no-longer-needed binding:
    kubectl delete clusterrolebinding <binding-name>
  - To keep the binding but drop unnecessary subjects, edit it interactively:
    kubectl edit clusterrolebinding <binding-name>
    Remove only the subjects that no longer require cluster-admin, then save.
- For bindings managed by GitOps/IaC, make the equivalent changes in the source manifests instead of editing live objects directly, then apply/sync.
Verify remaining usage of cluster-admin is minimal and intentional
- Run on: any machine with kubectl access
- Command:
```
kubectl get clusterrolebindings --no-headers | grep 'cluster-admin' || echo "No cluster-admin bindings found"
```
- For any remaining bindings, ensure you have documented justification (who, why, and approval) and that they are periodically re-reviewed.

Using kubectl

Run these commands from any machine with kubectl access.

List all ClusterRoleBindings that grant cluster-admin:

kubectl get clusterrolebindings -o wide | grep 'cluster-admin'

If you get no output, there are no current bindings to cluster-admin (no problem for this check).
Any lines returned indicate a binding that must be reviewed.

View full details of each binding found:

# Example: replace <binding-name> with each name from step 1
kubectl get clusterrolebinding <binding-name> -o yaml

Focus on:

.roleRef.name – must be cluster-admin for this control.
.subjects – which User, Group, or ServiceAccount is getting cluster-admin.

Problem indicators:

Bindings to broad identities such as:
- system:authenticated, system:unauthenticated, or other large groups
- Wildcard-like groups used by your IdP (e.g., “AllEmployees”)
ServiceAccounts in application namespaces (e.g., default, dev-*, prod-*) that do not clearly require full cluster control.
External users or groups where a more specific, least-privilege ClusterRole could be used instead.

(Optional) Quickly list just the subjects of all cluster-admin bindings:

kubectl get clusterrolebindings -o json \
  | jq -r '.items[]
    | select(.roleRef.kind=="ClusterRole" and .roleRef.name=="cluster-admin")
    | .metadata.name as $b
    | .subjects[]? 
    | [$b, .kind, .name, (.namespace // "-")] 
    | @tsv'

Output columns:

ClusterRoleBinding name
Subject kind (User, Group, ServiceAccount)
Subject name
Namespace (- for non-namespaced subjects)

Problem indicators here:

Many different subjects listed, especially generic groups.
Any entry where you cannot clearly justify why that subject needs unrestricted cluster-wide admin access.

Automation

#!/usr/bin/env bash
# Report all uses of the cluster-admin ClusterRole and highlight likely risks.
# Run on: any machine with kubectl access and current-context set to target cluster.

set -euo pipefail

echo "== ClusterRoleBindings that grant cluster-admin =="
kubectl get clusterrolebindings -o json \
  | jq -r '
    .items[]
    | select(.roleRef.kind == "ClusterRole" and .roleRef.name == "cluster-admin")
    | [
        .metadata.name,
        .subjects // [] | map(.kind + "/" + .name + (if .namespace then " (ns:" + .namespace + ")" else "" end)) | join(", ")
      ]
    | @tsv
  ' \
  | awk 'BEGIN { printf "%-40s %-60s\n", "CLUSTERROLEBINDING", "SUBJECTS"; print gensub(/./,"-","g",sprintf("%-40s %-60s"," "," ")); } { printf "%-40s %-60s\n", $1, substr($0, index($0,$2)) }'

echo
echo "== ClusterRoleBindings with cluster-admin bound to ServiceAccounts (detail) =="
kubectl get clusterrolebindings -o json \
  | jq -r '
    .items[]
    | select(.roleRef.kind == "ClusterRole" and .roleRef.name == "cluster-admin")
    | {
        name: .metadata.name,
        subjects: (.subjects // [])
      }
    | . as $b
    | $b.subjects[]
    | select(.kind == "ServiceAccount")
    | [
        $b.name,
        .name,
        (.namespace // "<none>")
      ]
    | @tsv
  ' \
  | awk 'BEGIN { printf "%-40s %-40s %-20s\n", "CLUSTERROLEBINDING", "SERVICEACCOUNT", "NAMESPACE"; print gensub(/./,"-","g",sprintf("%-40s %-40s %-20s"," "," "," ")); } { printf "%-40s %-40s %-20s\n", $1, $2, $3 }'

echo
echo "== ClusterRoleBindings with cluster-admin bound to Users/Groups (detail) =="
kubectl get clusterrolebindings -o json \
  | jq -r '
    .items[]
    | select(.roleRef.kind == "ClusterRole" and .roleRef.name == "cluster-admin")
    | {
        name: .metadata.name,
        subjects: (.subjects // [])
      }
    | . as $b
    | $b.subjects[]
    | select(.kind == "User" or .kind == "Group")
    | [
        $b.name,
        .kind,
        .name
      ]
    | @tsv
  ' \
  | awk 'BEGIN { printf "%-40s %-10s %-60s\n", "CLUSTERROLEBINDING", "KIND", "IDENTITY"; print gensub(/./,"-","g",sprintf("%-40s %-10s %-60s"," "," "," ")); } { printf "%-40s %-10s %-60s\n", $1, $2, $3 }'

echo
echo "== Summary counts =="
kubectl get clusterrolebindings -o json \
  | jq '
    .items
    | map(select(.roleRef.kind=="ClusterRole" and .roleRef.name=="cluster-admin")) as $b
    | {
        total_clusterrolebindings_using_cluster_admin: ($b | length),
        total_subjects: ($b | map(.subjects // []) | add | length),
        by_kind: ($b | map(.subjects // []) | add | group_by(.kind) | map({kind: .[0].kind, count: length}))
      }
  '

How to interpret the output (what indicates a problem):

Any entry in “ClusterRoleBindings that grant cluster-admin” is potentially risky and must be reviewed.
Especially suspicious:
- Bindings where SUBJECTS includes generic or shared identities such as:
  - Group/system:authenticated, Group/system:serviceaccounts, Group/system:masters (or similar broad groups).
  - User or group names that look like teams (devs, qa, ops, developers, etc.) instead of specific admin identities.
- ServiceAccounts in application namespaces (e.g., default, prod, staging, app-*) rather than a dedicated admin namespace.
The JSON “Summary counts” at the end:
- A total_clusterrolebindings_using_cluster_admin greater than a very small number (commonly >1–3) warrants closer review.
- A large total_subjects or by_kind entries with many User/Group subjects indicate overuse of cluster-admin.

Use this report to decide, per binding, whether the subject truly needs full cluster-admin. If not, remove that ClusterRoleBinding and replace it with a narrower ClusterRole/RoleBinding as appropriate.

More Info:​

Risk Level​

Address​

Compliance Standards​

Triage and Remediation​

Remediation​

Using kubectl​