GKE Service Account Token Created via TokenRequest API

Detects creation of a GKE service account token through the TokenRequest API by a non-system identity. TokenRequest allows programmatic minting of short-lived tokens for any service account the caller can create tokens for, without reading a mounted projected token from disk. Attackers with initial cluster access can abuse this API to obtain tokens for more privileged service accounts, pivot via Workload Identity to GCP APIs, or retain access after pod termination. Unlike filesystem token theft, TokenRequest activity is visible only in Kubernetes audit logs as create against the serviceaccounts/token subresource.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/07/13"
  3deprecation_date = "2026/08/21"
  4deprecated_reason = "GKE Cloud Audit Logs do not export TokenRequest (serviceaccounts/token) activity."
  5integration = ["gcp"]
  6maturity = "deprecated"
  7updated_date = "2026/08/21"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12Detects creation of a GKE service account token through the TokenRequest API by a non-system identity. TokenRequest
 13allows programmatic minting of short-lived tokens for any service account the caller can create tokens for, without
 14reading a mounted projected token from disk. Attackers with initial cluster access can abuse this API to obtain tokens
 15for more privileged service accounts, pivot via Workload Identity to GCP APIs, or retain access after pod termination.
 16Unlike filesystem token theft, TokenRequest activity is visible only in Kubernetes audit logs as create against the
 17serviceaccounts/token subresource.
 18"""
 19false_positives = [
 20    """
 21    Platform agents, admission webhooks, and CI jobs may legitimately call TokenRequest under non-standard identities.
 22    Baseline approved automation by client.user.email after validation. Expected GKE and kube-system controllers are
 23    excluded; expand exclusions if additional managed components appear in telemetry.
 24    """,
 25]
 26from = "now-6m"
 27index = ["logs-gcp.audit-*"]
 28language = "kuery"
 29license = "Elastic License v2"
 30name = "GKE Service Account Token Created via TokenRequest API"
 31note = """## Triage and analysis
 32
 33### Investigating GKE Service Account Token Created via TokenRequest API
 34
 35This alert indicates a successful create against the serviceaccounts/token subresource (TokenRequest API), which issues
 36a new service account token without a filesystem read. On GKE this can be abused to mint tokens for privileged service
 37accounts — including those bound through Workload Identity — and pivot to GCP APIs.
 38
 39### Possible investigation steps
 40
 41- Review `client.user.email`, `source.ip`, and `user_agent.original`.
 42- Identify the targeted service account from `gcp.audit.resource_name` (typically
 43  `core/v1/namespaces/<ns>/serviceaccounts/<sa>/token`).
 44- Determine which Role or ClusterRoleBindings grant the actor `create` on `serviceaccounts/token`.
 45- Correlate the same actor and source with follow-on secret reads, pod exec, RBAC changes, or GCP API activity via
 46  Workload Identity.
 47
 48### False positive analysis
 49
 50- New platform automation that mints projected tokens outside the excluded controllers may match. Allowlist after
 51  confirming expected behavior.
 52
 53### Response and remediation
 54
 55- If unauthorized, remove or revert RBAC that allows TokenRequest and rotate the affected service account credentials.
 56- For Workload Identity-linked service accounts, revoke related GCP role sessions and review Cloud Audit Logs in the
 57  same window.
 58
 59"""
 60setup = """
 61The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule.
 62"""
 63references = [
 64    "https://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/token-v1/",
 65    "https://stratus-red-team.cloud/attack-techniques/kubernetes/k8s.persistence.create-token/",
 66]
 67risk_score = 47
 68rule_id = "5d505bed-6d0e-4afa-b445-64841d4b8c58"
 69severity = "medium"
 70tags = [
 71    "Domain: Cloud",
 72    "Domain: Kubernetes",
 73    "Data Source: GCP",
 74    "Data Source: Google Cloud Platform",
 75    "Use Case: Threat Detection",
 76    "Tactic: Credential Access",
 77    "Resources: Investigation Guide",
 78]
 79timestamp_override = "event.ingested"
 80type = "query"
 81
 82query = '''
 83data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and
 84event.action:"io.k8s.core.v1.serviceaccounts.token.create" and
 85client.user.email:(* and not (
 86  "system:kube-controller-manager" or
 87  "system:kube-scheduler" or
 88  "system:gke-controller-manager" or
 89  "system:gcp-controller-manager" or
 90  system\:node\:* or
 91  system\:serviceaccount\:kube-system\:* or
 92  system\:serviceaccount\:gke-managed-system\:* or
 93  system\:serviceaccount\:gke-connect\:* or
 94  system\:serviceaccount\:anthos-identity-service\:*
 95))
 96'''
 97
 98[[rule.threat]]
 99framework = "MITRE ATT&CK"
100
101[[rule.threat.technique]]
102id = "T1552"
103name = "Unsecured Credentials"
104reference = "https://attack.mitre.org/techniques/T1552/"
105
106[[rule.threat.technique.subtechnique]]
107id = "T1552.007"
108name = "Container API"
109reference = "https://attack.mitre.org/techniques/T1552/007/"
110
111[rule.threat.tactic]
112id = "TA0006"
113name = "Credential Access"
114reference = "https://attack.mitre.org/tactics/TA0006/"
115
116[rule.investigation_fields]
117field_names = [
118    "@timestamp",
119    "client.user.email",
120    "source.ip",
121    "user_agent.original",
122    "event.action",
123    "event.outcome",
124    "gcp.audit.resource_name",
125    "gcp.audit.request",
126    "data_stream.namespace",
127]

Triage and analysis

Investigating GKE Service Account Token Created via TokenRequest API

This alert indicates a successful create against the serviceaccounts/token subresource (TokenRequest API), which issues a new service account token without a filesystem read. On GKE this can be abused to mint tokens for privileged service accounts — including those bound through Workload Identity — and pivot to GCP APIs.

Possible investigation steps

  • Review client.user.email, source.ip, and user_agent.original.
  • Identify the targeted service account from gcp.audit.resource_name (typically core/v1/namespaces/<ns>/serviceaccounts/<sa>/token).
  • Determine which Role or ClusterRoleBindings grant the actor create on serviceaccounts/token.
  • Correlate the same actor and source with follow-on secret reads, pod exec, RBAC changes, or GCP API activity via Workload Identity.

False positive analysis

  • New platform automation that mints projected tokens outside the excluded controllers may match. Allowlist after confirming expected behavior.

Response and remediation

  • If unauthorized, remove or revert RBAC that allows TokenRequest and rotate the affected service account credentials.
  • For Workload Identity-linked service accounts, revoke related GCP role sessions and review Cloud Audit Logs in the same window.

References

Related rules

to-top