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-admin for 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-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.

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-i for 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-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.

References

Related rules

to-top