Cluster role binding does not grant the cluster-admin role

Check ID: rbac_cluster_admin_usage
Provider: Kubernetes
Service: rbac
Severity: CRITICAL
Categories: identity-access, cluster-security
Resource type: ClusterRoleBinding

What this check verifies

RBAC ClusterRoleBindings that bind to the cluster-admin ClusterRole are identified, showing where subjects receive super-user permissions across all namespaces.

Risk

Excessive cluster-admin grants give full API control, risking:

Secret exfiltration (confidentiality)
RBAC tampering (integrity)
Destructive actions causing outages (availability)

A compromised subject can escalate, persist via new bindings, and laterally impact all namespaces.

Recommendation

Apply least privilege: replace cluster-admin with narrowly scoped Roles/ClusterRoles and bind per namespace. Reserve super-user access for break-glass, time-bound with approval and audit. Enforce separation of duties, review RBAC regularly, and monitor role/binding changes for defense in depth.

Remediation

CLI
Terraform
Dashboard steps

kubectl delete clusterrolebinding <example_resource_name>

resource "kubernetes_cluster_role_binding" "<example_resource_name>" {
  metadata { name = "<example_resource_name>" }
  role_ref {
    api_group = "rbac.authorization.k8s.io"
    kind      = "ClusterRole"
    name      = "view" # Critical: replace any "cluster-admin" binding with a limited role
  }
  subject {
    kind = "User"
    name = "<example_resource_id>"
  }
}

List ClusterRoleBindings that use cluster-admin:

kubectl get clusterrolebindings -o json | jq -r '.items[] | select(.roleRef.name=="cluster-admin") | .metadata.name'

For each name returned, delete the binding:

kubectl delete clusterrolebinding <example_resource_name>

If access is still required, recreate with least privilege (example uses view):

kubectl create clusterrolebinding <example_resource_name> --clusterrole=view --user=<example_resource_id>

References

Where this check fires

This check runs on every scheduled scan against your Kubernetes account. Findings appear at Cloud Security → Findings filterable by Check ID = rbac_cluster_admin_usage. To re-evaluate after a fix, hit Run now on the account’s schedule under Cloud Security → Schedules — the next scan re-checks this control and marks the finding fixed or keeps it persistent.

← Back to Kubernetes checks

Kubelet has TLS certificate and private key files configured No user or group can approve certificate signing requests

​What this check verifies

​Risk

​Recommendation

​Remediation

​References

​Where this check fires

What this check verifies

Risk

Recommendation

Remediation

References

Where this check fires