GKE Service Account Token Created via TokenRequest API

IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

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.

Rule type: query

Rule indices:

logs-gcp.audit-*

Severity: medium

Risk score: 47

Runs every: 5m

Searches indices from: now-6m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

Domain: Cloud
Domain: Kubernetes
Data Source: GCP
Data Source: Google Cloud Platform
Use Case: Threat Detection
Tactic: Credential Access
Resources: Investigation Guide

Version: 1

Rule authors:

Elastic

Rule license: Elastic License v2

Investigation guide

edit

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.

Setup

edit

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

Rule query

edit

data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and
event.action:"io.k8s.core.v1.serviceaccounts.token.create" and
client.user.email:(* and not (
  "system:kube-controller-manager" or
  "system:kube-scheduler" or
  "system:gke-controller-manager" or
  "system:gcp-controller-manager" or
  system\:node\:* or
  system\:serviceaccount\:kube-system\:* or
  system\:serviceaccount\:gke-managed-system\:* or
  system\:serviceaccount\:gke-connect\:* or
  system\:serviceaccount\:anthos-identity-service\:*
))

Framework: MITRE ATT&CK^TM

Tactic:
- Name: Credential Access
- ID: TA0006
- Reference URL: https://attack.mitre.org/tactics/TA0006/
Technique:
- Name: Unsecured Credentials
- ID: T1552
- Reference URL: https://attack.mitre.org/techniques/T1552/
Sub-technique:
- Name: Container API
- ID: T1552.007
- Reference URL: https://attack.mitre.org/techniques/T1552/007/

« GKE Rapid Secret GET Activity Against Multiple Objects GKE Anonymous Endpoint Permission Enumeration »