GKE RBAC Wildcard Elevation on Existing Role
Flags an existing GKE Role or ClusterRole being changed (patch or update) so the effective rules become cluster-admin-like: wildcard on every API resource and wildcard on every verb. That is usually a deliberate privilege expansion, not a typo. GKE audit logs with response body capture are required so the detection reads the merged role after apply; loopback source IPs are ignored.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/07/07"
3integration = ["gcp"]
4maturity = "production"
5updated_date = "2026/09/18"
6
7[rule]
8author = ["Elastic"]
9description = """
10Flags an existing GKE Role or ClusterRole being changed (patch or update) so the effective rules become
11cluster-admin-like: wildcard on every API resource and wildcard on every verb. That is usually a deliberate privilege
12expansion, not a typo. GKE audit logs with response body capture are required so the detection reads the merged role
13after apply; loopback source IPs are ignored.
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-6m"
22index = ["logs-gcp.audit-*"]
23language = "kuery"
24license = "Elastic License v2"
25name = "GKE RBAC Wildcard Elevation on Existing Role"
26note = """## Triage and analysis
27
28### Investigating GKE RBAC Wildcard Elevation on Existing Role
29
30Someone patched or updated a Role or ClusterRole so the stored rules grant star verbs and star resources—near
31cluster-admin breadth on that scope. Confirm the actor (user.email, groups), client, and non-loopback source IP;
32then see who can bind that role.
33
34### Possible investigation steps
35
36- Diff the role YAML before and after; list RoleBindings and ClusterRoleBindings that reference it and which subjects
37 gained the widened access.
38- Review `gcp.audit.resource_name`, `gcp.audit.response.rules.verbs`, and `gcp.audit.response.rules.resources`.
39- In the same window, check secret reads, exec, and further RBAC changes from the same identity.
40
41### False positive analysis
42
43- Approved GitOps or vendor upgrades sometimes widen a known ClusterRole; allowlist stable automation when documented.
44
45### Response and remediation
46
47- Revert the role, drop unexpected bindings, rotate credentials for the actor, and block future wildcard RBAC outside
48 governed pipelines (policy-as-code, PR-only RBAC).
49
50"""
51setup = "The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule."
52references = [
53 "https://kubernetes.io/docs/reference/access-authn-authz/rbac/",
54]
55risk_score = 73
56rule_id = "563a38e9-9790-4a6a-8889-24d26055b832"
57severity = "high"
58tags = [
59 "Domain: Cloud",
60 "Domain: Kubernetes",
61 "Data Source: GCP",
62 "Data Source: Google Cloud Platform",
63 "Use Case: Threat Detection",
64 "Tactic: Privilege Escalation",
65 "Resources: Investigation Guide",
66 "Noise: Medium",
67 "Performance: Normal",
68 "Rule Type: Custom Query (KQL)",
69 "Platform: GCP",
70 "Domain: Containers",
71 "Platform: Kubernetes",
72]
73timestamp_override = "event.ingested"
74type = "query"
75
76query = '''
77data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and
78event.action:(
79 "io.k8s.authorization.rbac.v1.roles.update" or
80 "io.k8s.authorization.rbac.v1.roles.patch" or
81 "io.k8s.authorization.rbac.v1.clusterroles.update" or
82 "io.k8s.authorization.rbac.v1.clusterroles.patch"
83) and source.ip:(* and not ("127.0.0.1" or "::1")) and not (
84 client.user.email:"system:addon-manager" and
85 event.action:(
86 "io.k8s.authorization.rbac.v1.roles.patch" or
87 "io.k8s.authorization.rbac.v1.clusterroles.patch"
88 )
89) and
90gcp.audit.response.rules.verbs:"*" and gcp.audit.response.rules.resources:"*"
91'''
92
93[[rule.threat]]
94framework = "MITRE ATT&CK"
95
96[[rule.threat.technique]]
97id = "T1098"
98name = "Account Manipulation"
99reference = "https://attack.mitre.org/techniques/T1098/"
100
101[[rule.threat.technique.subtechnique]]
102id = "T1098.006"
103name = "Additional Container Cluster Roles"
104reference = "https://attack.mitre.org/techniques/T1098/006/"
105
106[rule.threat.tactic]
107id = "TA0004"
108name = "Privilege Escalation"
109reference = "https://attack.mitre.org/tactics/TA0004/"
110
111[rule.investigation_fields]
112field_names = [
113 "@timestamp",
114 "client.user.email",
115 "source.ip",
116 "user_agent.original",
117 "event.action",
118 "event.outcome",
119 "gcp.audit.resource_name",
120 "gcp.audit.request.kind",
121 "data_stream.namespace",
122]
Triage and analysis
Investigating GKE 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.email, groups), 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.
- Review
gcp.audit.resource_name,gcp.audit.response.rules.verbs, andgcp.audit.response.rules.resources. - 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
- GKE API Server Proxying Request to Kubelet
- GKE Client Certificate Signing Request Created or Approved
- GKE Container Created with Excessive Linux Capabilities
- GKE Pod Exec Potential Reverse Shell
- GKE Secret Access from Node or Denied Service Account