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, and gcp.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

to-top