How to audit Kubernetes cluster admin bindings: Find every superuser path and cut it back

Who holds cluster-admin is the single most important access question in a Kubernetes cluster, and the honest answer is rarely just the ClusterRoleBindings that name it. Superuser access also comes from the system:masters group in client certificates, from cloud provider mappings such as EKS access policies and AKS local admin credentials, from RoleBindings to cluster-admin inside namespaces, and from ordinary-looking permissions such as bind, escalate and impersonate that let a subject grant itself the role. This runbook finds all of them, separates the legitimate from the accidental, and shows how to remove bindings safely with a rollback. It is for platform engineers and security teams running self-managed, EKS, AKS or GKE clusters. For how RBAC works in general, see the Kubernetes RBAC Guide; this page is the audit task.

This is an independent guide from NHI Mgmt Group, based on the Kubernetes documentation and the AWS, Microsoft and Google documentation for their managed services as of November 2026. It is not sponsored or reviewed by any of them. Confirm settings against current documentation.

Key takeaways

• Bindings are only one route. Members of system:masters bypass RBAC and any authorisation webhook, and Kubernetes states this cannot be revoked by removing RoleBindings or ClusterRoleBindings.
• Look at RoleBindings too. A RoleBinding to cluster-admin gives full control of that namespace, including the namespace object itself.
• Count the equivalents. bind, escalate, impersonate, wildcard rules, create on serviceaccounts/token and get on nodes/proxy can each reach cluster-admin.
• Check the cloud layer. EKS AmazonEKSClusterAdminPolicy, AKS local accounts and GKE IAM roles grant cluster-wide control outside the cluster's own RBAC objects.
• Never edit the default binding. The API server reconciles default system: roles and bindings at start-up; reduce access by removing other bindings and the credentials behind them.

When you need this

• Periodic access review: Kubernetes calls periodic RBAC review "vital", partly because a new account created with a deleted user's name inherits that user's bindings.
• After installing operators and tools: install scripts and vendor charts often request cluster-admin for their service account.
• Incident response: creating a binding to cluster-admin is a classic persistence step (ATT&CK T1098.006 Additional Container Cluster Roles). See the Kubernetes Cluster Compromise Playbook.
• Audit evidence: NIST SP 800-53 AC-6(5) Privileged Accounts and AC-6(7) Review of User Privileges expect a short, reviewed list of privileged subjects.

Before you start

Audit with a read-only identity that can list RBAC objects cluster-wide. Do not use a system:masters certificate for the audit itself: those requests skip authorisation and do not exercise RBAC. Export every RBAC object to version control before you change anything; that export is your rollback.

kubectl get clusterroles,clusterrolebindings -o yaml > rbac-cluster-backup.yaml
kubectl get roles,rolebindings -A -o yaml > rbac-namespaced-backup.yaml

Step-by-step

Steps 1 to 6 are read-only. Step 7 changes access and needs owner agreement. Step 8 may need certificate rotation.

1. List ClusterRoleBindings to cluster-admin and their subjects.

   kubectl get clusterrolebindings -o jsonpath='{range .items[?(@.roleRef.name=="cluster-admin")]}{.metadata.name}{"\t"}{.subjects}{"\n"}{end}'

   Expect the default cluster-admin binding to the system:masters group. Every other line is a finding to explain.
2. List RoleBindings to cluster-admin in every namespace.

   kubectl get rolebindings -A -o jsonpath='{range .items[?(@.roleRef.name=="cluster-admin")]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.subjects}{"\n"}{end}'

   Namespace owners usually need admin, which cannot write resource quotas or the namespace itself; cluster-admin in a RoleBinding can.
3. Find cluster-admin equivalents. Review every ClusterRole and Role whose rules contain * in verbs, resources or apiGroups, and every role granting the verbs in the table below. Kubernetes warns that wildcards cover future resource types as well as current ones. Then list who is bound to those roles, using the same jsonpath pattern with each role name.
4. Test effective access for each subject. For each non-default subject, confirm what it can really do:

   kubectl auth can-i '*' '*' --as=system:serviceaccount:NAMESPACE:NAME
   kubectl auth can-i --list --as=system:serviceaccount:NAMESPACE:NAME -n NAMESPACE

   For users and groups use --as=USER and --as-group=GROUP. A "yes" to '*' '*' means superuser whatever the role is called.
5. Check the cloud provider layer.
   • EKS: list access entries with aws eks list-access-entries --cluster-name CLUSTER, then for each principal run aws eks list-associated-access-policies --cluster-name CLUSTER --principal-arn ARN and flag arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy, which grants wildcards on everything, including non-resource URLs. Note accessScope.type: cluster or namespace. Review the aws-auth ConfigMap as well if the cluster still uses it; entries there are not migrated automatically. The automatic creator entry is a common forgotten admin.
   • AKS: Microsoft documents that local accounts are enabled by default and that --admin access is "non-auditable". Check disableLocalAccounts and test with az aks get-credentials --resource-group RG --name CLUSTER --admin; on a hardened cluster it fails with "Getting static credential isn't allowed because this cluster is set to disable local accounts."
   • GKE: GKE checks RBAC first and then IAM, so a principal with broad Kubernetes Engine IAM roles on the project can act in the cluster without any binding. Review project IAM alongside RBAC, and check Google Groups bound through gke-security-groups.
6. Find system:masters credentials. Inventory issued client certificates whose organisation is system:masters: kubeconfigs created at bootstrap, admin certificates generated by installers, and break-glass files. On AKS, admin credentials from --admin are such certificates. These cannot be removed with RBAC; the only revocation is to stop trusting them by rotating the cluster certificates.
7. Remove or narrow each unjustified binding. For each finding agree a replacement with the owner: admin, edit or a custom role in a RoleBinding, or a read-only ClusterRole for monitoring tools. Because roleRef is immutable, create the new binding first, verify with kubectl auth can-i, then delete the old one:

   kubectl delete clusterrolebinding BINDING_NAME

   For EKS, disassociate the policy or replace it with AmazonEKSAdminPolicy scoped to namespaces. For AKS, run az aks update --resource-group RG --name CLUSTER --disable-local-accounts after confirming Entra ID admin groups work.
8. Revoke what bindings cannot. Where system:masters certificates or AKS admin credentials were handed out, rotate the cluster certificates (Microsoft documents this as required on existing AKS clusters after disabling local accounts). Plan this as a change with its own window, since every client must fetch new credentials.

Permissions to treat as cluster-admin

Prioritise the work

Where identity fits

Most surprising cluster-admin holders are non-human: controllers, operators, CI deployers and monitoring agents whose service accounts were bound to cluster-admin to make an install work. Their tokens sit inside pods, so anyone who can exec into those pods or read their mounted token holds the same power. Pair this audit with How to Find pods that automount service account tokens and the Kubernetes Service Account Token Guide. Kubernetes also advises limiting the nodes that run powerful pods and keeping them away from untrusted workloads.

Verify it worked

• Re-run steps 1 to 4: only the default binding and documented break-glass subjects remain.
• Effective access: kubectl auth can-i '*' '*' returns "no" for every changed subject.
• Cloud layer: no unexpected principal holds AmazonEKSClusterAdminPolicy; the AKS --admin test fails.
• Workloads: no new "forbidden" errors in controller logs; see the Kubernetes RBAC Forbidden Errors Troubleshooting Guide if they appear.

Rollback and common errors

Hardening afterwards

• Admission policy: reject new ClusterRoleBindings and RoleBindings to cluster-admin outside an allow list, starting in audit mode. See the Kubernetes Admission Control Guide.
• Alert on change: in the API server audit log, alert on create, update or patch of clusterrolebindings and rolebindings whose request references cluster-admin, and on any request authenticated through system:masters. See the Kubernetes Audit Log Detection Guide.
• Low-privilege admins: Kubernetes recommends a low-privileged account with impersonation rights rather than daily cluster-admin use.
• Break-glass: keep one documented emergency path, stored offline, tested and alerted. See the Break-Glass Account Guide.

What to look for in the audit log

The API server audit log records who made each request, what object it touched and, at the Request or RequestResponse level, the object body. Make sure your audit policy logs RBAC objects at least at the Request level, otherwise you see that a binding was created but not which role it references. Useful patterns:

Requests made through nodes/proxy reach the kubelet directly, and Kubernetes notes they bypass API server audit logging, so the permission itself must be audited in step 3 rather than detected later.

Small cluster or large fleet

One cluster can be audited by hand with the commands above in under an hour. A fleet needs the same queries run from a central job against every cluster, results stored per cluster, and policy enforced through a common admission controller configuration. Fleet owners should also standardise how cloud admin access is granted (one EKS access policy pattern, local accounts disabled on every AKS cluster) so the cloud layer is checked once per pattern, not per cluster.

Metrics

Common failure patterns

• Auditing bindings and ignoring certificates: a kubeconfig with a system:masters certificate on a laptop survives every RBAC clean-up.
• Ignoring the cloud layer: EKS access policies and GKE IAM can grant full control while the cluster's RBAC looks clean.
• Only searching for the name: a custom ClusterRole with wildcards, or bind on clusterroles, is cluster-admin under another name.
• Leaving admin dashboards exposed: powerful in-cluster consoles become the shortest route to the cluster. The Tesla Kubernetes cryptojacking incident began with an administrative console reachable without a password.
• Deleting before replacing: removing a controller's binding without a scoped replacement causes an outage and the binding comes back wider.

Framework mapping

Practitioner checklist

• Back up all RBAC objects before any change.
• List ClusterRoleBindings and RoleBindings to cluster-admin.
• Find wildcard roles and the bind, escalate, impersonate and token permissions.
• Confirm effective access with kubectl auth can-i for each subject.
• Review EKS access policies, AKS local accounts and GKE IAM.
• Inventory system:masters certificates and plan rotation where needed.
• Replace, verify, then delete each unjustified binding.
• Enforce admission rules and alert on new cluster-admin bindings.

Standards and references

• Kubernetes: Using RBAC Authorization
• Kubernetes: Role Based Access Control Good Practices
• Kubernetes: User impersonation
• AWS: Review access policy permissions for Amazon EKS
• AWS CLI Reference: eks list-associated-access-policies
• Microsoft Learn: Manage local accounts with AKS-managed Microsoft Entra integration
• Google Cloud: Authorize actions in clusters using RBAC

Related NHI Mgmt Group resources: Kubernetes RBAC Guide · Kubernetes NHI Security Guide · EKS Identity Hardening Guide · Azure Kubernetes Service Security Hardening Guide