GKE API Request Impersonating Privileged Identity

Detects GKE API requests where a caller is impersonating a privileged cluster identity such as system:kube-controller-manager, system:admin, system:anonymous, or a kube-system service account. These identities have broad cluster-wide permissions including unrestricted access to secrets, the ability to create tokens for any service account, schedule pods on any node, and modify RBAC. Impersonating system:kube-controller-manager grants access to secrets across namespaces and service account token minting for lateral movement.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/07/13"
  3integration = ["gcp"]
  4maturity = "production"
  5updated_date = "2026/07/13"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects GKE API requests where a caller is impersonating a privileged cluster identity such as
 11system:kube-controller-manager, system:admin, system:anonymous, or a kube-system service account. These identities have
 12broad cluster-wide permissions including unrestricted access to secrets, the ability to create tokens for any service
 13account, schedule pods on any node, and modify RBAC. Impersonating system:kube-controller-manager grants access to
 14secrets across namespaces and service account token minting for lateral movement.
 15"""
 16false_positives = [
 17    """
 18    Break-glass admin tooling, security scanners, or approved controllers that legitimately use impersonation against
 19    privileged targets may match. Map expected callers and expand client.user.email exclusions as needed.
 20    """,
 21]
 22from = "now-6m"
 23index = ["logs-gcp.audit-*"]
 24language = "kuery"
 25license = "Elastic License v2"
 26name = "GKE API Request Impersonating Privileged Identity"
 27note = """## Triage and analysis
 28
 29### Investigating GKE API Request Impersonating Privileged Identity
 30
 31Compare the real actor (`client.user.email`, `source.ip`, `user_agent.original`) with the impersonated identity in
 32`gcp.audit.authentication_info.authority_selector` (Cloud Audit `authenticationInfo.authoritySelector`). Confirm
 33whether impersonation is authorized for that principal and target identity.
 34
 35### Possible investigation steps
 36
 37- Review `event.action` and `gcp.audit.resource_name` for the scope of the operation performed while impersonating.
 38- Determine whether the real user or service account should have `impersonate` rights against the target user or group;
 39  inspect RBAC bindings and any recent changes.
 40- Correlate with adjacent audit activity (secrets, TokenRequest, RBAC writes, CSR approval) from the same source
 41  identity.
 42- Hunt for repeated impersonation across namespaces or rapid pivoting after the event.
 43
 44### False positive analysis
 45
 46- Approved admin or scanner workflows that intentionally use `kubectl --as` against privileged targets may match.
 47  Allowlist those identities after review.
 48
 49### Response and remediation
 50
 51- Revoke or tighten `impersonate` permissions for unexpected identities; rotate credentials for any account that may
 52  have abused impersonation.
 53- If unauthorized, treat as cluster-wide credential risk: review secrets exposure, issued tokens, and RBAC drift.
 54
 55"""
 56setup = """
 57The GCP Fleet integration with GKE audit logs enabled is required. Kubernetes impersonation (`kubectl --as`) maps to
 58`gcp.audit.authentication_info.authority_selector` in Fleet.
 59"""
 60references = [
 61    "https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation",
 62    "https://kubernetes.io/docs/reference/access-authn-authz/user-impersonation/",
 63]
 64risk_score = 73
 65rule_id = "00c2a946-bbe8-4345-941d-9ea13da91600"
 66severity = "high"
 67tags = [
 68    "Domain: Cloud",
 69    "Domain: Kubernetes",
 70    "Data Source: GCP",
 71    "Data Source: Google Cloud Platform",
 72    "Use Case: Threat Detection",
 73    "Tactic: Privilege Escalation",
 74    "Tactic: Defense Evasion",
 75    "Resources: Investigation Guide",
 76]
 77timestamp_override = "event.ingested"
 78type = "query"
 79
 80query = '''
 81data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and
 82gcp.audit.authentication_info.authority_selector:(
 83  "admin" or "cluster-admin" or "kubernetes-admin" or "system:admin" or "system:anonymous" or
 84  "system:apiserver" or "system:kube-controller-manager" or "system:kube-proxy" or
 85  "system:kube-scheduler" or "system:volume-scheduler" or
 86  system\:node\:* or system\:serviceaccount\:kube-system\:*
 87) and
 88not client.user.email:(
 89  "system:kube-controller-manager" or
 90  "system:kube-scheduler" or
 91  system\:node\:* or
 92  system\:serviceaccount\:kube-system\:*
 93)
 94'''
 95
 96[[rule.threat]]
 97framework = "MITRE ATT&CK"
 98
 99[[rule.threat.technique]]
100id = "T1134"
101name = "Access Token Manipulation"
102reference = "https://attack.mitre.org/techniques/T1134/"
103
104[rule.threat.tactic]
105id = "TA0004"
106name = "Privilege Escalation"
107reference = "https://attack.mitre.org/tactics/TA0004/"
108
109[[rule.threat]]
110framework = "MITRE ATT&CK"
111
112[[rule.threat.technique]]
113id = "T1134"
114name = "Access Token Manipulation"
115reference = "https://attack.mitre.org/techniques/T1134/"
116
117[rule.threat.tactic]
118id = "TA0005"
119name = "Defense Evasion"
120reference = "https://attack.mitre.org/tactics/TA0005/"
121
122[rule.investigation_fields]
123field_names = [
124    "@timestamp",
125    "client.user.email",
126    "source.ip",
127    "user_agent.original",
128    "event.action",
129    "event.outcome",
130    "gcp.audit.authentication_info.authority_selector",
131    "gcp.audit.resource_name",
132    "data_stream.namespace",
133]

Triage and analysis

Investigating GKE API Request Impersonating Privileged Identity

Compare the real actor (client.user.email, source.ip, user_agent.original) with the impersonated identity in gcp.audit.authentication_info.authority_selector (Cloud Audit authenticationInfo.authoritySelector). Confirm whether impersonation is authorized for that principal and target identity.

Possible investigation steps

  • Review event.action and gcp.audit.resource_name for the scope of the operation performed while impersonating.
  • Determine whether the real user or service account should have impersonate rights against the target user or group; inspect RBAC bindings and any recent changes.
  • Correlate with adjacent audit activity (secrets, TokenRequest, RBAC writes, CSR approval) from the same source identity.
  • Hunt for repeated impersonation across namespaces or rapid pivoting after the event.

False positive analysis

  • Approved admin or scanner workflows that intentionally use kubectl --as against privileged targets may match. Allowlist those identities after review.

Response and remediation

  • Revoke or tighten impersonate permissions for unexpected identities; rotate credentials for any account that may have abused impersonation.
  • If unauthorized, treat as cluster-wide credential risk: review secrets exposure, issued tokens, and RBAC drift.

References

Related rules

to-top