AWS EKS RBAC Wildcard Elevation on Existing Role
Flags an existing Role or ClusterRole being changed (patch or update) to a wildcard on every API resource and verb. This may be indicative of a deliberate privilege expansion but may also be a nefarious attempt at privilege escalation.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/08/03"
3integration = ["aws"]
4maturity = "production"
5min_stack_comments = "The AWS integration adds the aws.eks_audit data stream in package 8.9.0, which requires Kibana 9.6.0 or later."
6min_stack_version = "9.6.0"
7updated_date = "2026/10/20"
8
9[rule]
10author = ["Elastic"]
11description = """
12Flags an existing Role or ClusterRole being changed (patch or update) to a wildcard on every API resource and verb. This
13may be indicative of a deliberate privilege expansion but may also be a nefarious attempt at privilege escalation.
14"""
15false_positives = [
16 """
17 Platform installers, GitOps controllers, and emergency break-glass roles sometimes ship or widen wildcard
18 ClusterRoles; correlate with change records and narrow by user or service account when baselined.
19 """,
20]
21from = "now-9m"
22language = "esql"
23license = "Elastic License v2"
24name = "AWS EKS RBAC Wildcard Elevation on Existing Role"
25note = """## Triage and analysis
26
27### Investigating AWS EKS RBAC Wildcard Elevation on Existing Role
28Someone patched or updated a Role or ClusterRole so the stored rules grant star verbs and star resources—near
29cluster-admin breadth on that scope. Confirm the actor (user, group, impersonation), client, and non-loopback source
30IP; then see who can bind that role.
31
32### Possible investigation steps
33
34- Diff the role YAML before and after; list RoleBindings and ClusterRoleBindings that reference it and which subjects
35 gained the widened access.
36- In the same window, check secret reads, exec, and further RBAC changes from the same identity.
37
38### False positive analysis
39
40- Approved GitOps or vendor upgrades sometimes widen a known ClusterRole; allowlist stable automation when documented.
41
42### Response and remediation
43
44- Revert the role, drop unexpected bindings, rotate credentials for the actor, and block future wildcard RBAC outside
45 governed pipelines (policy-as-code, PR-only RBAC)."""
46references = ["https://kubernetes.io/docs/reference/access-authn-authz/rbac/"]
47risk_score = 73
48rule_id = "af625960-3595-5008-ad7b-7ed2a11becda"
49setup = """This rule reads EKS control-plane audit logs collected by the AWS integration
50into `logs-aws.eks_audit-*`, where the AWS EKS audit ingest
51pipelines normalize each audit record under `aws.eks.audit.*`.
52
53Enable the `audit` control-plane log type on the EKS cluster, send its
54CloudWatch log group through the AWS integration, and confirm events carry
55`data_stream.dataset: aws.eks_audit` and
56`cloud.provider: aws` before enabling this rule.
57"""
58severity = "high"
59tags = [
60 "Domain: Cloud",
61 "Domain: Containers",
62 "Platform: AWS",
63 "Platform: Kubernetes",
64 "Data Source: AWS",
65 "Data Source: Amazon Web Services",
66 "Data Source: Kubernetes API Server Audit Logs",
67 "Service: AWS EKS",
68 "Use Case: Threat Detection",
69 "Tactic: Privilege Escalation",
70 "Rule Type: ES|QL",
71 "Resources: Investigation Guide",
72 "Profile: Beta",
73]
74timestamp_override = "event.ingested"
75type = "esql"
76
77query = '''
78from logs-aws.eks_audit-* metadata _id, _index, _version
79| where
80 aws.eks.audit.objectRef.resource in ("roles", "clusterroles") and
81 aws.eks.audit.verb in ("update", "patch") and
82 `aws.eks.audit.annotations.authorization_k8s_io/decision` == "allow" and
83 aws.eks.audit.level == "RequestResponse" and
84 aws.eks.audit.stage == "ResponseComplete" and
85 aws.eks.audit.sourceIPs is not null and
86 not aws.eks.audit.sourceIPs in ("::1", "127.0.0.1") and
87 KQL(""" aws.eks.audit.responseObject.rules.verbs:"*" and aws.eks.audit.responseObject.rules.resources:"*" """)
88| keep user.name, user_agent.original, event.action, source.ip, aws.eks.audit.verb, aws.eks.audit.objectRef.resource, aws.eks.audit.objectRef.name, aws.eks.audit.requestURI, aws.eks.audit.user.username, aws.eks.audit.user.groups, `aws.eks.audit.annotations.authorization_k8s_io/decision`, event.original, _id, _version, _index, data_stream.namespace
89'''
90
91
92[[rule.threat]]
93framework = "MITRE ATT&CK"
94[[rule.threat.technique]]
95id = "T1098"
96name = "Account Manipulation"
97reference = "https://attack.mitre.org/techniques/T1098/"
98[[rule.threat.technique.subtechnique]]
99id = "T1098.006"
100name = "Additional Container Cluster Roles"
101reference = "https://attack.mitre.org/techniques/T1098/006/"
102
103
104
105[rule.threat.tactic]
106id = "TA0004"
107name = "Privilege Escalation"
108reference = "https://attack.mitre.org/tactics/TA0004/"
Triage and analysis
Investigating AWS EKS RBAC Wildcard Elevation on Existing Role
Someone patched or updated a Role or ClusterRole so the stored rules grant star verbs and star resources—near cluster-admin breadth on that scope. Confirm the actor (user, group, impersonation), client, and non-loopback source IP; then see who can bind that role.
Possible investigation steps
- Diff the role YAML before and after; list RoleBindings and ClusterRoleBindings that reference it and which subjects gained the widened access.
- In the same window, check secret reads, exec, and further RBAC changes from the same identity.
False positive analysis
- Approved GitOps or vendor upgrades sometimes widen a known ClusterRole; allowlist stable automation when documented.
Response and remediation
- Revert the role, drop unexpected bindings, rotate credentials for the actor, and block future wildcard RBAC outside governed pipelines (policy-as-code, PR-only RBAC).
References
Related rules
- AWS EKS Creation or Modification of Sensitive Role
- AWS EKS API Request Impersonating Privileged Identity
- AWS EKS API Server Proxying Request to Kubelet
- AWS EKS Container Created with Excessive Linux Capabilities
- AWS EKS Ephemeral Container Added to Pod