GKE RBAC Wildcard Elevation on Existing Role

IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

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.

Rule type: query

Rule indices:

logs-gcp.audit-*

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-6m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

https://kubernetes.io/docs/reference/access-authn-authz/rbac/

Tags:

Domain: Cloud
Domain: Kubernetes
Data Source: GCP
Data Source: Google Cloud Platform
Use Case: Threat Detection
Tactic: Privilege Escalation
Resources: Investigation Guide

Version: 1

Rule authors:

Elastic

Rule license: Elastic License v2

Investigation guide

edit

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).

Setup

edit

The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule.

Rule query

edit

data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and
event.action:(
  "io.k8s.authorization.rbac.v1.roles.update" or
  "io.k8s.authorization.rbac.v1.roles.patch" or
  "io.k8s.authorization.rbac.v1.clusterroles.update" or
  "io.k8s.authorization.rbac.v1.clusterroles.patch"
) and source.ip:(* and not ("127.0.0.1" or "::1")) and not (
  client.user.email:"system:addon-manager" and
  event.action:(
    "io.k8s.authorization.rbac.v1.roles.patch" or
    "io.k8s.authorization.rbac.v1.clusterroles.patch"
  )
) and
gcp.audit.response.rules.verbs:"*" and gcp.audit.response.rules.resources:"*"

Framework: MITRE ATT&CK^TM

Tactic:
- Name: Privilege Escalation
- ID: TA0004
- Reference URL: https://attack.mitre.org/tactics/TA0004/
Technique:
- Name: Account Manipulation
- ID: T1098
- Reference URL: https://attack.mitre.org/techniques/T1098/
Sub-technique:
- Name: Additional Container Cluster Roles
- ID: T1098.006
- Reference URL: https://attack.mitre.org/techniques/T1098/006/

« GKE Ephemeral Container Added to Pod GKE Service Account Modified RBAC Objects »