GKE Service Account Modified RBAC Objects

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

GKE Service Account Modified RBAC Objects

Detects write operations performed by GKE service accounts against RBAC resources (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings). Service accounts typically do not manage RBAC directly; this activity may indicate token abuse or unauthorized privilege escalation.

Rule type: query

Rule indices:

logs-gcp.audit-*

Severity: medium

Risk score: 47

Runs every: 5m

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

Maximum alerts per execution: 100

References:

Tags:

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

Version: 1

Rule authors:

Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating GKE Service Account Modified RBAC Objects

This rule detects service accounts performing allowed write actions on RBAC resources. Stolen or over-privileged service account tokens can silently alter authorization to gain or retain elevated access.

Possible investigation steps

Review client.user.email, event.action, and gcp.audit.resource_name.
Trace the acting service account to its owning workload and inspect recent image changes or exec activity.
Correlate with change tickets or GitOps commits for the same RBAC object.

False positive analysis

Platform operators and GitOps controllers running in-cluster commonly create or patch RBAC objects.

Response and remediation

Revert unauthorized RBAC changes, rotate the service account credentials, and tighten RBAC for the workload.

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
client.user.email:(system\:serviceaccount\:* and not (
  "system:serviceaccount:kube-system:clusterrole-aggregation-controller" or
  "system:serviceaccount:kube-system:generic-garbage-collector"
)) and event.action:(
  "io.k8s.authorization.rbac.v1.clusterrolebindings.create" or
  "io.k8s.authorization.rbac.v1.clusterrolebindings.delete" or
  "io.k8s.authorization.rbac.v1.clusterrolebindings.patch" or
  "io.k8s.authorization.rbac.v1.clusterrolebindings.update" or
  "io.k8s.authorization.rbac.v1.clusterroles.create" or
  "io.k8s.authorization.rbac.v1.clusterroles.delete" or
  "io.k8s.authorization.rbac.v1.clusterroles.patch" or
  "io.k8s.authorization.rbac.v1.clusterroles.update" or
  "io.k8s.authorization.rbac.v1.rolebindings.create" or
  "io.k8s.authorization.rbac.v1.rolebindings.delete" or
  "io.k8s.authorization.rbac.v1.rolebindings.patch" or
  "io.k8s.authorization.rbac.v1.rolebindings.update" or
  "io.k8s.authorization.rbac.v1.roles.create" or
  "io.k8s.authorization.rbac.v1.roles.delete" or
  "io.k8s.authorization.rbac.v1.roles.patch" or
  "io.k8s.authorization.rbac.v1.roles.update"
)

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/
Tactic:
- Name: Persistence
- ID: TA0003
- Reference URL: https://attack.mitre.org/tactics/TA0003/
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 RBAC Wildcard Elevation on Existing Role GKE Suspicious Assignment of Controller Service Account »