No wildcard cluster-admin bindings beyond ops team
Demonstrate that cluster-admin ClusterRoleBindings do not use wildcard or overly broad subject identifiers except for explicitly authorized operations team accounts.
Description
What this control does
This control restricts the assignment of Kubernetes cluster-admin ClusterRoleBindings with wildcard subjects (e.g., system:authenticated, system:unauthenticated, or wildcard group memberships) to only designated operations teams. Cluster-admin provides unrestricted access to all Kubernetes resources across all namespaces, and wildcard bindings grant this privilege to broad, often poorly-defined user populations. By limiting these bindings to explicitly named operations personnel or tightly scoped service accounts, the control prevents privilege escalation, lateral movement, and accidental or malicious cluster-wide compromise.
Control objective
What auditing this proves
Demonstrate that cluster-admin ClusterRoleBindings do not use wildcard or overly broad subject identifiers except for explicitly authorized operations team accounts.
Associated risks
Risks this control addresses
- Unauthorized users gaining cluster-admin privileges through wildcard group memberships or default authentication bindings
- Privilege escalation by attackers who compromise any authenticated user account when system:authenticated has cluster-admin
- Accidental deletion or modification of critical cluster infrastructure by non-operations personnel with excessive privileges
- Lateral movement across all namespaces and workloads by an attacker with access to any authenticated principal
- Compliance violations due to lack of least-privilege enforcement and insufficient separation of duties
- Inability to attribute administrative actions to specific individuals when wildcard subjects obscure identity
- Compromise of service accounts in any namespace leading to full cluster control if service account groups have cluster-admin
Testing procedure
How an auditor verifies this control
- Obtain a current export of all ClusterRoleBindings in the cluster using kubectl get clusterrolebindings -o yaml or equivalent API query.
- Filter the exported ClusterRoleBindings to identify all bindings that reference the cluster-admin ClusterRole.
- Extract the subjects array from each cluster-admin ClusterRoleBinding and document the kind, name, namespace, and apiGroup for each subject.
- Identify any subjects using wildcard patterns including system:authenticated, system:unauthenticated, system:serviceaccounts, or regex/glob patterns in name fields.
- Request the current authoritative list of approved operations team members, service accounts, and groups permitted to hold cluster-admin privileges.
- Compare the wildcard or broad-scope subjects found in step four against the approved operations team roster from step five.
- Interview the Kubernetes platform team to confirm the rationale for any wildcard bindings and verify change control records for their creation or modification.
- Review Kubernetes audit logs for the past 90 days to identify any usage of cluster-admin privileges by subjects matching wildcard bindings outside the operations team.
Where this control is tested