Kubernetes Cluster-Admin Role Binding Created
This rule detects the creation of a RoleBinding or ClusterRoleBinding that grants the cluster-admin ClusterRole, which provides unrestricted access to all Kubernetes resources and represents a high-risk privilege escalation or misconfiguration.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/02/04"
3integration = ["kubernetes"]
4maturity = "production"
5updated_date = "2026/02/09"
6
7[rule]
8author = ["Elastic"]
9description = """
10This rule detects the creation of a RoleBinding or ClusterRoleBinding that grants the cluster-admin
11ClusterRole, which provides unrestricted access to all Kubernetes resources and represents a
12high-risk privilege escalation or misconfiguration.
13"""
14index = ["logs-kubernetes.audit_logs-*"]
15language = "kuery"
16license = "Elastic License v2"
17name = "Kubernetes Cluster-Admin Role Binding Created"
18note = """ ## Triage and analysis
19
20> **Disclaimer**:
21> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
22
23### Investigating Kubernetes Cluster-Admin Role Binding Created
24
25This rule flags when someone creates a RoleBinding or ClusterRoleBinding that assigns the cluster-admin role, which grants unrestricted control over every Kubernetes resource and enables rapid privilege escalation or persistence. Attackers often abuse a stolen namespace service account to bind it to cluster-admin, then pivot to read secrets, change security controls, or deploy a privileged DaemonSet across all nodes to maintain control.
26
27### Possible investigation steps
28
29- Identify who created the binding by reviewing the audit event user identity, groups, source IP, and user agent, and confirm whether it matches an approved admin workflow or automation.
30- Inspect the created RoleBinding or ClusterRoleBinding to determine which subject received cluster-admin, whether it targets a service account or external identity, and whether the subject is expected to have cluster-wide privileges.
31- Correlate the creator and bound subject with recent authentication events and credential changes to spot compromised accounts, unusual access locations, or use of long-lived tokens.
32- Review subsequent Kubernetes audit activity from the same actor or newly privileged subject for rapid follow-on actions such as listing secrets, creating privileged pods/daemonsets, modifying RBAC, or disabling admission controls.
33- Validate the change against change management records and repository-based RBAC manifests, and if unauthorized, assess scope by enumerating other recent privileged RBAC grants created around the same time.
34
35### False positive analysis
36
37- A cluster bootstrap, upgrade, or recovery workflow legitimately creates or re-creates a ClusterRoleBinding/RoleBinding to `cluster-admin` for a break-glass admin user or core control-plane service account as part of restoring expected RBAC state.
38- An approved operational change temporarily grants `cluster-admin` to a namespace service account or automation identity to perform broad maintenance tasks (e.g., installing cluster-scoped resources), and the binding creation is captured during the allowed change window.
39
40### Response and remediation
41
42- Immediately identify and delete or edit the newly created RoleBinding/ClusterRoleBinding granting `cluster-admin`, then revoke the bound subject’s access by rotating the affected service account token or disabling the implicated user/identity provider account.
43- Quarantine likely-abused workloads by scaling down or deleting pods/deployments created by the newly privileged subject and blocking its network access with namespace isolation policies while you preserve relevant audit logs and YAML manifests.
44- Enumerate and undo follow-on changes made after the binding creation, including additional RBAC grants, new cluster-scoped resources (CRDs, webhooks), privileged DaemonSets, secret reads, or changes to admission controllers, and rotate any exposed credentials found in Secrets.
45- Recover by restoring RBAC and critical cluster resources from GitOps or known-good backups, then re-apply least-privilege roles and validate access with `kubectl auth can-i` for impacted identities and namespaces.
46- Escalate to incident response leadership immediately if the binding targets a service account, an external identity not in the admin group, or if there is evidence of secret access, privileged workload creation, or persistence mechanisms (e.g., new webhooks or DaemonSets).
47- Harden by enforcing RBAC via GitOps-only change control, restricting `cluster-admin` binding creation with admission policy (ValidatingAdmissionPolicy/Kyverno/OPA Gatekeeper), requiring MFA and short-lived tokens for admins, and alerting on any creation or modification of cluster-wide RBAC bindings.
48"""
49references = [
50 "https://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control",
51]
52risk_score = 47
53rule_id = "a2951930-dd35-438c-b10e-1bbdc5881cb4"
54severity = "medium"
55tags = [
56 "Data Source: Kubernetes",
57 "Domain: Kubernetes",
58 "Use Case: Threat Detection",
59 "Tactic: Persistence",
60 "Tactic: Privilege Escalation",
61 "Resources: Investigation Guide",
62]
63timestamp_override = "event.ingested"
64type = "query"
65query = '''
66event.dataset: "kubernetes.audit_logs" and kubernetes.audit.objectRef.resource:("clusterrolebindings" or "rolebindings") and
67kubernetes.audit.verb:"create" and kubernetes.audit.requestObject.roleRef.name:"cluster-admin" and
68kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and
69kubernetes.audit.level:"RequestResponse" and kubernetes.audit.stage:"ResponseComplete"
70'''
71
72[[rule.threat]]
73framework = "MITRE ATT&CK"
74
75[[rule.threat.technique]]
76id = "T1098"
77name = "Account Manipulation"
78reference = "https://attack.mitre.org/techniques/T1098/"
79
80[[rule.threat.technique.subtechnique]]
81id = "T1098.006"
82name = "Additional Container Cluster Roles"
83reference = "https://attack.mitre.org/techniques/T1098/006/"
84
85[rule.threat.tactic]
86id = "TA0003"
87name = "Persistence"
88reference = "https://attack.mitre.org/tactics/TA0003/"
89
90[[rule.threat]]
91framework = "MITRE ATT&CK"
92
93[[rule.threat.technique]]
94id = "T1098"
95name = "Account Manipulation"
96reference = "https://attack.mitre.org/techniques/T1098/"
97
98[[rule.threat.technique.subtechnique]]
99id = "T1098.006"
100name = "Additional Container Cluster Roles"
101reference = "https://attack.mitre.org/techniques/T1098/006/"
102
103[rule.threat.tactic]
104id = "TA0004"
105name = "Privilege Escalation"
106reference = "https://attack.mitre.org/tactics/TA0004/"
Triage and analysis
Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
Investigating Kubernetes Cluster-Admin Role Binding Created
This rule flags when someone creates a RoleBinding or ClusterRoleBinding that assigns the cluster-admin role, which grants unrestricted control over every Kubernetes resource and enables rapid privilege escalation or persistence. Attackers often abuse a stolen namespace service account to bind it to cluster-admin, then pivot to read secrets, change security controls, or deploy a privileged DaemonSet across all nodes to maintain control.
Possible investigation steps
- Identify who created the binding by reviewing the audit event user identity, groups, source IP, and user agent, and confirm whether it matches an approved admin workflow or automation.
- Inspect the created RoleBinding or ClusterRoleBinding to determine which subject received cluster-admin, whether it targets a service account or external identity, and whether the subject is expected to have cluster-wide privileges.
- Correlate the creator and bound subject with recent authentication events and credential changes to spot compromised accounts, unusual access locations, or use of long-lived tokens.
- Review subsequent Kubernetes audit activity from the same actor or newly privileged subject for rapid follow-on actions such as listing secrets, creating privileged pods/daemonsets, modifying RBAC, or disabling admission controls.
- Validate the change against change management records and repository-based RBAC manifests, and if unauthorized, assess scope by enumerating other recent privileged RBAC grants created around the same time.
False positive analysis
- A cluster bootstrap, upgrade, or recovery workflow legitimately creates or re-creates a ClusterRoleBinding/RoleBinding to
cluster-adminfor a break-glass admin user or core control-plane service account as part of restoring expected RBAC state. - An approved operational change temporarily grants
cluster-adminto a namespace service account or automation identity to perform broad maintenance tasks (e.g., installing cluster-scoped resources), and the binding creation is captured during the allowed change window.
Response and remediation
- Immediately identify and delete or edit the newly created RoleBinding/ClusterRoleBinding granting
cluster-admin, then revoke the bound subject’s access by rotating the affected service account token or disabling the implicated user/identity provider account. - Quarantine likely-abused workloads by scaling down or deleting pods/deployments created by the newly privileged subject and blocking its network access with namespace isolation policies while you preserve relevant audit logs and YAML manifests.
- Enumerate and undo follow-on changes made after the binding creation, including additional RBAC grants, new cluster-scoped resources (CRDs, webhooks), privileged DaemonSets, secret reads, or changes to admission controllers, and rotate any exposed credentials found in Secrets.
- Recover by restoring RBAC and critical cluster resources from GitOps or known-good backups, then re-apply least-privilege roles and validate access with
kubectl auth can-ifor impacted identities and namespaces. - Escalate to incident response leadership immediately if the binding targets a service account, an external identity not in the admin group, or if there is evidence of secret access, privileged workload creation, or persistence mechanisms (e.g., new webhooks or DaemonSets).
- Harden by enforcing RBAC via GitOps-only change control, restricting
cluster-adminbinding creation with admission policy (ValidatingAdmissionPolicy/Kyverno/OPA Gatekeeper), requiring MFA and short-lived tokens for admins, and alerting on any creation or modification of cluster-wide RBAC bindings.
References
Related rules
- Kubernetes Creation of a RoleBinding Referencing a ServiceAccount
- Kubernetes Creation or Modification of Sensitive Role
- Kubernetes Sensitive RBAC Change Followed by Workload Modification
- Kubernetes Service Account Modified RBAC Objects
- Kubernetes Container Created with Excessive Linux Capabilities