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/07/10"
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]
67timestamp_override = "event.ingested"
68type = "query"
69
70query = '''
71data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and
72event.action:(
73 "io.k8s.authorization.rbac.v1.roles.update" or
74 "io.k8s.authorization.rbac.v1.roles.patch" or
75 "io.k8s.authorization.rbac.v1.clusterroles.update" or
76 "io.k8s.authorization.rbac.v1.clusterroles.patch"
77) and source.ip:(* and not ("127.0.0.1" or "::1")) and not (
78 client.user.email:"system:addon-manager" and
79 event.action:(
80 "io.k8s.authorization.rbac.v1.roles.patch" or
81 "io.k8s.authorization.rbac.v1.clusterroles.patch"
82 )
83) and
84gcp.audit.response.rules.verbs:"*" and gcp.audit.response.rules.resources:"*"
85'''
86
87[[rule.threat]]
88framework = "MITRE ATT&CK"
89
90[[rule.threat.technique]]
91id = "T1098"
92name = "Account Manipulation"
93reference = "https://attack.mitre.org/techniques/T1098/"
94
95[[rule.threat.technique.subtechnique]]
96id = "T1098.006"
97name = "Additional Container Cluster Roles"
98reference = "https://attack.mitre.org/techniques/T1098/006/"
99
100[rule.threat.tactic]
101id = "TA0004"
102name = "Privilege Escalation"
103reference = "https://attack.mitre.org/tactics/TA0004/"
104
105[rule.investigation_fields]
106field_names = [
107 "@timestamp",
108 "client.user.email",
109 "source.ip",
110 "user_agent.original",
111 "event.action",
112 "event.outcome",
113 "gcp.audit.resource_name",
114 "gcp.audit.request.kind",
115 "data_stream.namespace",
116]
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 Cluster-Admin Role Binding Created or Modified
- GKE Creation of a RoleBinding Referencing a ServiceAccount
- GKE Creation or Modification of Sensitive Role
- GKE Service Account Modified RBAC Objects
- GKE Suspicious Assignment of Controller Service Account