GKE Creation of a RoleBinding Referencing a ServiceAccount
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.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/07/10"
3integration = ["gcp"]
4maturity = "production"
5updated_date = "2026/09/18"
6
7[rule]
8author = ["Elastic"]
9description = """
10Detects creation of a GKE RoleBinding or ClusterRoleBinding that grants permissions to a ServiceAccount, which may
11indicate privilege delegation or RBAC misconfiguration leading to elevated access.
12"""
13false_positives = [
14 """
15 GitOps, namespace onboarding, and workload deployment commonly create RoleBindings for service accounts. Default
16 bootstrap bindings from `system:apiserver` and GKE node bootstrap from `gcp:kube-bootstrap` are excluded.
17 """,
18]
19from = "now-6m"
20index = ["logs-gcp.audit-*"]
21language = "kuery"
22license = "Elastic License v2"
23name = "GKE Creation of a RoleBinding Referencing a ServiceAccount"
24note = """## Triage and analysis
25
26### Investigating GKE Creation of a RoleBinding Referencing a ServiceAccount
27
28This rule detects creation of a RoleBinding or ClusterRoleBinding whose subject is a ServiceAccount. Attackers often bind
29over-privileged roles to an existing workload service account to operate with elevated rights.
30
31### Possible investigation steps
32
33- Review `client.user.email`, `source.ip`, `gcp.audit.request.roleRef`, and `gcp.audit.request.subjects`.
34- Determine which workloads run under the bound service account and whether the referenced role is cluster-scoped.
35- Correlate with secret access, exec, or additional RBAC changes from the same actor.
36
37### False positive analysis
38
39- Legitimate deployments and operators create service account bindings during routine releases.
40
41### Response and remediation
42
43- Remove unauthorized bindings, rotate the service account credentials, and tighten who can create RoleBindings.
44
45"""
46setup = "The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule."
47references = [
48 "https://kubernetes.io/docs/reference/access-authn-authz/rbac/",
49 "https://heilancoos.github.io/research/2025/12/16/kubernetes.html#overly-permissive-role-based-access-control",
50]
51risk_score = 47
52rule_id = "1e58e0a0-7674-4aa9-9409-f72f100a8b5e"
53severity = "medium"
54tags = [
55 "Domain: Cloud",
56 "Domain: Kubernetes",
57 "Data Source: GCP",
58 "Data Source: Google Cloud Platform",
59 "Use Case: Threat Detection",
60 "Tactic: Persistence",
61 "Tactic: Privilege Escalation",
62 "Resources: Investigation Guide",
63 "Noise: Low",
64 "Performance: Fast",
65 "Rule Type: Custom Query (KQL)",
66 "Platform: GCP",
67 "Domain: Containers",
68 "Platform: Kubernetes",
69]
70timestamp_override = "event.ingested"
71type = "query"
72
73query = '''
74data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and
75event.action:(
76 "io.k8s.authorization.rbac.v1.rolebindings.create" or
77 "io.k8s.authorization.rbac.v1.clusterrolebindings.create"
78) and gcp.audit.request.subjects.kind:"ServiceAccount" and not client.user.email:(
79 "system:apiserver" or
80 "gcp:kube-bootstrap"
81)
82'''
83
84[[rule.threat]]
85framework = "MITRE ATT&CK"
86
87[[rule.threat.technique]]
88id = "T1098"
89name = "Account Manipulation"
90reference = "https://attack.mitre.org/techniques/T1098/"
91
92[[rule.threat.technique.subtechnique]]
93id = "T1098.006"
94name = "Additional Container Cluster Roles"
95reference = "https://attack.mitre.org/techniques/T1098/006/"
96
97[rule.threat.tactic]
98id = "TA0003"
99name = "Persistence"
100reference = "https://attack.mitre.org/tactics/TA0003/"
101
102[[rule.threat]]
103framework = "MITRE ATT&CK"
104
105[[rule.threat.technique]]
106id = "T1098"
107name = "Account Manipulation"
108reference = "https://attack.mitre.org/techniques/T1098/"
109
110[[rule.threat.technique.subtechnique]]
111id = "T1098.006"
112name = "Additional Container Cluster Roles"
113reference = "https://attack.mitre.org/techniques/T1098/006/"
114
115[rule.threat.tactic]
116id = "TA0004"
117name = "Privilege Escalation"
118reference = "https://attack.mitre.org/tactics/TA0004/"
119
120[rule.investigation_fields]
121field_names = [
122 "@timestamp",
123 "client.user.email",
124 "source.ip",
125 "user_agent.original",
126 "event.action",
127 "event.outcome",
128 "gcp.audit.resource_name",
129 "gcp.audit.request.roleRef.name",
130 "gcp.audit.request.roleRef.kind",
131 "gcp.audit.request.subjects.name",
132 "gcp.audit.request.subjects.namespace",
133 "data_stream.namespace",
134]
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, andgcp.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.
References
Related rules
- GKE Creation or Modification of Sensitive Role
- GKE Service Account Modified RBAC Objects
- GKE Certificate Signing Request API Client Signer Requested
- GKE Cluster-Admin Role Binding Created or Modified
- GKE API Request Impersonating Privileged Identity