GKE Creation of a RoleBinding Referencing a ServiceAccount


Description

Detects creation of a GKE RoleBinding or ClusterRoleBinding that grants permissions to a ServiceAccount, which may indicate privilege delegation or RBAC misconfiguration leading to elevated access.

Query · kuery

data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and
event.action:(
  "io.k8s.authorization.rbac.v1.rolebindings.create" or
  "io.k8s.authorization.rbac.v1.clusterrolebindings.create"
) and gcp.audit.request.subjects.kind:"ServiceAccount" and not client.user.email:(
  "system:apiserver" or
  "gcp:kube-bootstrap"
)

Investigation fields

Pivot points the source recommends for triage.

  • @timestamp
  • client.user.email
  • source.ip
  • user_agent.original
  • event.action
  • event.outcome
  • gcp.audit.resource_name
  • gcp.audit.request.roleRef.name
  • gcp.audit.request.roleRef.kind
  • gcp.audit.request.subjects.name
  • gcp.audit.request.subjects.namespace
  • data_stream.namespace

Implementation guide

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

Known false positives

  • GitOps, namespace onboarding, and workload deployment commonly create RoleBindings for service accounts. Default bootstrap bindings from `system:apiserver` and GKE node bootstrap from `gcp:kube-bootstrap` are excluded.

Analyst notes

Investigating GKE Creation of a RoleBinding Referencing a ServiceAccount

This rule detects creation of a RoleBinding or ClusterRoleBinding whose subject is a ServiceAccount. Attackers often bind over-privileged roles to an existing workload service account to operate with elevated rights.

Possible investigation steps

  • Review client.user.email, source.ip, gcp.audit.request.roleRef, and gcp.audit.request.subjects.
  • Determine which workloads run under the bound service account and whether the referenced role is cluster-scoped.
  • Correlate with secret access, exec, or additional RBAC changes from the same actor.

False positive analysis

  • Legitimate deployments and operators create service account bindings during routine releases.

Response and remediation

  • Remove unauthorized bindings, rotate the service account credentials, and tighten who can create RoleBindings.
Raw source GKE Creation of a RoleBinding Referencing a ServiceAccount · Elastic TOML
Esc
Published by elastic/detection-rules ↗, licensed under Elastic License 2.0 ↗. Reproduced here unmodified.
[metadata]
creation_date = "2026/07/10"
integration = ["gcp"]
maturity = "production"
updated_date = "2026/07/10"

[rule]
author = ["Elastic"]
description = """
Detects creation of a GKE RoleBinding or ClusterRoleBinding that grants permissions to a ServiceAccount, which may
indicate privilege delegation or RBAC misconfiguration leading to elevated access.
"""
false_positives = [
    """
    GitOps, namespace onboarding, and workload deployment commonly create RoleBindings for service accounts. Default
    bootstrap bindings from `system:apiserver` and GKE node bootstrap from `gcp:kube-bootstrap` are excluded.
    """,
]
from = "now-6m"
index = ["logs-gcp.audit-*"]
language = "kuery"
license = "Elastic License v2"
name = "GKE Creation of a RoleBinding Referencing a ServiceAccount"
note = """## Triage and analysis

### Investigating GKE Creation of a RoleBinding Referencing a ServiceAccount

This rule detects creation of a RoleBinding or ClusterRoleBinding whose subject is a ServiceAccount. Attackers often bind
over-privileged roles to an existing workload service account to operate with elevated rights.

### Possible investigation steps

- Review `client.user.email`, `source.ip`, `gcp.audit.request.roleRef`, and `gcp.audit.request.subjects`.
- Determine which workloads run under the bound service account and whether the referenced role is cluster-scoped.
- Correlate with secret access, exec, or additional RBAC changes from the same actor.

### False positive analysis

- Legitimate deployments and operators create service account bindings during routine releases.

### Response and remediation

- Remove unauthorized bindings, rotate the service account credentials, and tighten who can create RoleBindings.

"""
setup = "The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule."
references = [
    "https://kubernetes.io/docs/reference/access-authn-authz/rbac/",
    "https://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control",
]
risk_score = 47
rule_id = "1e58e0a0-7674-4aa9-9409-f72f100a8b5e"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Kubernetes",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Tactic: Privilege Escalation",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and
event.action:(
  "io.k8s.authorization.rbac.v1.rolebindings.create" or
  "io.k8s.authorization.rbac.v1.clusterrolebindings.create"
) and gcp.audit.request.subjects.kind:"ServiceAccount" and not client.user.email:(
  "system:apiserver" or
  "gcp:kube-bootstrap"
)
'''

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1098"
name = "Account Manipulation"
reference = "https://attack.mitre.org/techniques/T1098/"

[[rule.threat.technique.subtechnique]]
id = "T1098.006"
name = "Additional Container Cluster Roles"
reference = "https://attack.mitre.org/techniques/T1098/006/"

[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1098"
name = "Account Manipulation"
reference = "https://attack.mitre.org/techniques/T1098/"

[[rule.threat.technique.subtechnique]]
id = "T1098.006"
name = "Additional Container Cluster Roles"
reference = "https://attack.mitre.org/techniques/T1098/006/"

[rule.threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "client.user.email",
    "source.ip",
    "user_agent.original",
    "event.action",
    "event.outcome",
    "gcp.audit.resource_name",
    "gcp.audit.request.roleRef.name",
    "gcp.audit.request.roleRef.kind",
    "gcp.audit.request.subjects.name",
    "gcp.audit.request.subjects.namespace",
    "data_stream.namespace",
]

Detection rules belong to the projects that publish them and remain under their own licenses. This site indexes and links to them; it claims no rights in them.