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/07/10"
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]
64timestamp_override = "event.ingested"
65type = "query"
66
67query = '''
68data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and
69event.action:(
70 "io.k8s.authorization.rbac.v1.rolebindings.create" or
71 "io.k8s.authorization.rbac.v1.clusterrolebindings.create"
72) and gcp.audit.request.subjects.kind:"ServiceAccount" and not client.user.email:(
73 "system:apiserver" or
74 "gcp:kube-bootstrap"
75)
76'''
77
78[[rule.threat]]
79framework = "MITRE ATT&CK"
80
81[[rule.threat.technique]]
82id = "T1098"
83name = "Account Manipulation"
84reference = "https://attack.mitre.org/techniques/T1098/"
85
86[[rule.threat.technique.subtechnique]]
87id = "T1098.006"
88name = "Additional Container Cluster Roles"
89reference = "https://attack.mitre.org/techniques/T1098/006/"
90
91[rule.threat.tactic]
92id = "TA0003"
93name = "Persistence"
94reference = "https://attack.mitre.org/tactics/TA0003/"
95
96[[rule.threat]]
97framework = "MITRE ATT&CK"
98
99[[rule.threat.technique]]
100id = "T1098"
101name = "Account Manipulation"
102reference = "https://attack.mitre.org/techniques/T1098/"
103
104[[rule.threat.technique.subtechnique]]
105id = "T1098.006"
106name = "Additional Container Cluster Roles"
107reference = "https://attack.mitre.org/techniques/T1098/006/"
108
109[rule.threat.tactic]
110id = "TA0004"
111name = "Privilege Escalation"
112reference = "https://attack.mitre.org/tactics/TA0004/"
113
114[rule.investigation_fields]
115field_names = [
116 "@timestamp",
117 "client.user.email",
118 "source.ip",
119 "user_agent.original",
120 "event.action",
121 "event.outcome",
122 "gcp.audit.resource_name",
123 "gcp.audit.request.roleRef.name",
124 "gcp.audit.request.roleRef.kind",
125 "gcp.audit.request.subjects.name",
126 "gcp.audit.request.subjects.namespace",
127 "data_stream.namespace",
128]
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 Cluster-Admin Role Binding Created or Modified
- GKE Creation or Modification of Sensitive Role
- GKE Service Account Modified RBAC Objects
- GKE Unusual Sensitive Workload Modification
- GKE RBAC Wildcard Elevation on Existing Role