Kubernetes Creation or Modification of Sensitive Role

  1[metadata]
  2creation_date = "2026/02/04"
  3integration = ["kubernetes"]
  4maturity = "production"
  5updated_date = "2026/02/09"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects the creation or modification of Kubernetes Roles or ClusterRoles that grant high-risk permissions,
 11such as wildcard access or RBAC escalation verbs (e.g., bind, escalate, impersonate), which may enable
 12privilege escalation or unauthorized access within the cluster.
 13"""
 14language = "esql"
 15license = "Elastic License v2"
 16name = "Kubernetes Creation or Modification of Sensitive Role"
 17note = """ ## Triage and analysis
 18
 19> **Disclaimer**:
 20> 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.
 21
 22### Investigating Kubernetes Creation or Modification of Sensitive Role
 23
 24This rule detects allowed create, update, or patch actions on Roles and ClusterRoles that introduce high-risk RBAC permissions, including wildcard access and escalation verbs like bind, escalate, or impersonate. These changes matter because they can silently expand privileges and enable persistence or lateral movement across the cluster. Attackers commonly add a new ClusterRole with `*` verbs/resources and then use it to bind themselves or a service account to cluster-admin–equivalent access.
 25
 26### Possible investigation steps
 27
 28- Identify the responsible identity and origin by reviewing the audit event’s user/service account, userAgent, and source IPs, then confirm whether the action came from approved automation (e.g., GitOps/CI) or an interactive session.  
 29- Retrieve and diff the Role/ClusterRole manifest before vs after the change to pinpoint newly added wildcards, escalation verbs (bind/escalate/impersonate), or permissions over RBAC resources that enable privilege escalation.  
 30- Enumerate RoleBindings/ClusterRoleBindings that reference the modified role and determine which users/groups/service accounts gained effective permissions, prioritizing bindings created/changed near the same time.  
 31- Validate authorization intent by correlating the change with a change ticket/PR and the expected namespace/cluster scope, and flag any out-of-band edits (kubectl apply/edit) that bypass the normal workflow.  
 32- If suspicious, contain by reverting the role and removing or disabling newly privileged bindings/subjects, then hunt for follow-on activity from the same identity (e.g., creation of new service accounts, secrets access, or additional RBAC changes) within the incident window.
 33
 34### False positive analysis
 35
 36- Cluster administrators or platform automation legitimately create or update Roles/ClusterRoles to include wildcard verbs/resources or escalation-related verbs (bind/escalate/impersonate) during initial cluster bootstrapping, feature enablement, or maintenance, especially when enabling broad operational access for system components.  
 37- Routine RBAC refactoring such as consolidating multiple granular roles into a single reusable role, migrating permissions across namespaces, or adjusting access for incident response can temporarily add permissions over RBAC resources (roles/rolebindings/clusterroles/clusterrolebindings) and trigger the rule even when the change is approved and tracked.
 38
 39### Response and remediation
 40
 41- Immediately locate and quarantine the changed Role/ClusterRole by reverting it to the last known-good manifest (from Git/GitOps) or deleting it if unauthorized, and remove any new RoleBinding/ClusterRoleBinding subjects that reference it.  
 42- Contain the actor by disabling or rotating credentials for the responsible user/service account (and its tokens), and if the change came from a workload, isolate the namespace/workload (scale down, deny egress) until provenance is confirmed.  
 43- Eradicate persistence by searching for and removing additional RBAC changes made in the same window (new roles, bindings, service accounts) and by revoking any newly granted access to secrets or cluster-scoped resources discovered during review.  
 44- Recover by redeploying RBAC from a controlled pipeline, validating effective permissions for impacted subjects, and monitoring for re-creation of the same role name or re-binding attempts after rollback.  
 45- Escalate to platform security/incident response immediately if the role grants wildcard permissions, includes `impersonate`/`escalate`/`bind`, is cluster-scoped, or is bound to non-admin subjects or external identities without an approved change record.  
 46- Harden by enforcing RBAC guardrails (OPA Gatekeeper/Kyverno policies blocking wildcard/escalation verbs except for approved groups), restricting who can create/update RBAC objects, and requiring all RBAC changes to flow through code review and signed GitOps automation.
 47"""
 48references = [
 49    "https://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control",
 50]
 51risk_score = 47
 52rule_id = "0fb25791-d8d4-42ab-8fc7-4954642de85f"
 53severity = "medium"
 54tags = [
 55    "Data Source: Kubernetes",
 56    "Domain: Kubernetes",
 57    "Use Case: Threat Detection",
 58    "Tactic: Persistence",
 59    "Tactic: Privilege Escalation",
 60    "Resources: Investigation Guide",
 61]
 62timestamp_override = "event.ingested"
 63type = "esql"
 64query = '''
 65FROM logs-kubernetes.audit_logs-* metadata _id, _index, _version
 66| WHERE
 67  kubernetes.audit.objectRef.resource in ("roles", "clusterroles") and
 68  kubernetes.audit.verb in ("create", "update", "patch") and
 69  `kubernetes.audit.annotations.authorization_k8s_io/decision` == "allow" and
 70  kubernetes.audit.level == "RequestResponse" and kubernetes.audit.stage == "ResponseComplete" and
 71  KQL("""kubernetes.audit.requestObject.rules.verbs:("*" or "escalate" or "bind" or "impersonate") or kubernetes.audit.requestObject.rules.resources:("clusterroles" or "clusterrolebindings" or "roles" or "rolebindings")""")
 72| KEEP
 73  @timestamp,
 74  data_stream.namespace,
 75  `kubernetes.audit.annotations.authorization_k8s_io/decision`,
 76  kubernetes.audit.level,
 77  kubernetes.audit.objectRef.name,
 78  kubernetes.audit.objectRef.resource,
 79  kubernetes.audit.requestURI,
 80  kubernetes.audit.responseStatus.code,
 81  kubernetes.audit.sourceIPs,
 82  kubernetes.audit.stage,
 83  kubernetes.audit.user.groups,
 84  kubernetes.audit.user.username,
 85  kubernetes.audit.userAgent,
 86  kubernetes.audit.verb,
 87  _id,
 88  _index,
 89  _version
 90'''
 91
 92[[rule.threat]]
 93framework = "MITRE ATT&CK"
 94
 95[[rule.threat.technique]]
 96id = "T1098"
 97name = "Account Manipulation"
 98reference = "https://attack.mitre.org/techniques/T1098/"
 99
100[[rule.threat.technique.subtechnique]]
101id = "T1098.006"
102name = "Additional Container Cluster Roles"
103reference = "https://attack.mitre.org/techniques/T1098/006/"
104
105[rule.threat.tactic]
106id = "TA0003"
107name = "Persistence"
108reference = "https://attack.mitre.org/tactics/TA0003/"
109
110[[rule.threat]]
111framework = "MITRE ATT&CK"
112
113[[rule.threat.technique]]
114id = "T1098"
115name = "Account Manipulation"
116reference = "https://attack.mitre.org/techniques/T1098/"
117
118[[rule.threat.technique.subtechnique]]
119id = "T1098.006"
120name = "Additional Container Cluster Roles"
121reference = "https://attack.mitre.org/techniques/T1098/006/"
122
123[rule.threat.tactic]
124id = "TA0004"
125name = "Privilege Escalation"
126reference = "https://attack.mitre.org/tactics/TA0004/"