Kubernetes Service Account Token Created via TokenRequest API

Detects the creation of a Kubernetes service account token through the TokenRequest API by a non-system identity. The TokenRequest API allows users and workloads to programmatically generate short-lived tokens for any service account they have create permissions on, without accessing the filesystem or the mounted projected token. Attackers who have gained initial access to a cluster can abuse this API to mint tokens for more privileged service accounts, pivot to cloud provider resources via IRSA/workload identity, or generate long-lived tokens that persist beyond pod termination. Unlike mounted service account tokens which are detectable through file access monitoring, tokens created via the TokenRequest API leave no filesystem footprint, they are only visible in Kubernetes audit logs as a create verb on the serviceaccounts/token subresource. This rule excludes legitimate system components such as the kubelet, kube-controller-manager, and cloud provider managed identities (EKS, AKS, GKE) that routinely create tokens for pod lifecycle management.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/05/05"
  3integration = ["kubernetes"]
  4maturity = "production"
  5updated_date = "2026/10/06"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects the creation of a Kubernetes service account token through the TokenRequest API by a non-system identity. The
 11TokenRequest API allows users and workloads to programmatically generate short-lived tokens for any service account
 12they have create permissions on, without accessing the filesystem or the mounted projected token. Attackers who have
 13gained initial access to a cluster can abuse this API to mint tokens for more privileged service accounts, pivot to
 14cloud provider resources via IRSA/workload identity, or generate long-lived tokens that persist beyond pod
 15termination. Unlike mounted service account tokens which are detectable through file access monitoring, tokens created
 16via the TokenRequest API leave no filesystem footprint, they are only visible in Kubernetes audit logs as a create
 17verb on the serviceaccounts/token subresource. This rule excludes legitimate system components such as the kubelet,
 18kube-controller-manager, and cloud provider managed identities (EKS, AKS, GKE) that routinely create tokens for pod
 19lifecycle management.
 20"""
 21false_positives = [
 22    """
 23    New automation, admission webhooks, or platform agents that legitimately call the TokenRequest API under a
 24    non-standard user string may require narrow exclusions by user.name or source IP.
 25    """,
 26]
 27from = "now-6m"
 28index = ["logs-kubernetes.audit_logs-*"]
 29language = "kuery"
 30license = "Elastic License v2"
 31name = "Kubernetes Service Account Token Created via TokenRequest API"
 32note = """## Triage and analysis
 33
 34### Investigating Kubernetes Service Account Token Created via TokenRequest API
 35
 36This alert indicates a successful `create` against the `serviceaccounts/token` subresource (TokenRequest API), which
 37issues a new service account token without a filesystem read. In EKS and other managed clusters, this can be abused to
 38mint tokens for more privileged service accounts (including IRSA-linked ones) and pivot to cloud APIs.
 39
 40#### What to review first
 41
 42- Actor and origin:
 43  - `user.name` / `kubernetes.audit.user.username`
 44  - `source.ip` / `kubernetes.audit.sourceIPs`
 45  - `user_agent.original` / `kubernetes.audit.userAgent`
 46  - For cloud identity, review `kubernetes.audit.user.extra.*` (e.g., `arn`, `principalId`).
 47- Targeted service account:
 48  - `kubernetes.audit.objectRef.namespace` and `kubernetes.audit.objectRef.name`
 49  - `kubernetes.audit.requestURI` (should resemble `/api/v1/namespaces/<ns>/serviceaccounts/<sa>/token`)
 50- Token issuance hints:
 51  - `kubernetes.audit.annotations.authentication_kubernetes_io/issued-credential-id` (token JTI/issued credential id)
 52
 53#### Scoping
 54
 55- Identify which Role/ClusterRoleBindings grant the actor `create` on `serviceaccounts/token` in the affected namespace.
 56- Pivot on the same `user.name` and `source.ip` for follow-on secret reads, pod exec, RBAC changes, or cloud API calls.
 57
 58### Response and remediation
 59
 60- If unauthorized, remove/revert the RBAC permission that allows TokenRequest (`serviceaccounts/token`) and rotate the
 61  affected service account credentials where applicable.
 62- For IRSA/workload identity cases, rotate/revoke the cloud role session pathways and review cloud audit logs for API
 63  activity from the time window of the token mint.
 64"""
 65references = [
 66    "https://kubernetes.io/docs/reference/kubernetes-api/authentication-resources/token-request-v1/",
 67    "https://attack.mitre.org/techniques/T1552/007/",
 68]
 69risk_score = 47
 70rule_id = "4df91789-7859-4bc4-9c5a-6b56bfa81a8b"
 71severity = "medium"
 72tags = [
 73    "Data Source: Kubernetes",
 74    "Domain: Kubernetes",
 75    "Use Case: Threat Detection",
 76    "Tactic: Credential Access",
 77    "Resources: Investigation Guide",
 78    "Noise: Low",
 79    "Performance: Fast",
 80    "Rule Type: Custom Query (KQL)",
 81    "Platform: Kubernetes",
 82    "Domain: Containers",
 83    "Domain: Cloud",
 84]
 85timestamp_override = "event.ingested"
 86type = "query"
 87query = '''
 88data_stream.dataset:"kubernetes.audit_logs" and 
 89kubernetes.audit.verb:"create" and
 90kubernetes.audit.objectRef.resource:"serviceaccounts" and
 91kubernetes.audit.objectRef.subresource:"token" and
 92user.name:(* and not 
 93 (system\:kube-controller-manager or
 94  system\:kube-scheduler or
 95  system\:node\:* or
 96  system\:serviceaccount\:kube-system\:* or
 97  eks\:* or
 98  aksService or
 99  aks-service or
100  masterclient or
101  nodeclient or
102  system\:serviceaccount\:gke-managed-system\:* or
103  system\:serviceaccount\:gke-connect\:* or
104  system\:serviceaccount\:anthos-identity-service\:* or
105  system\:gke-controller-manager or
106  system\:serviceaccount\:tigera-operator\:* or
107  system\:serviceaccount\:calico-system\:*))
108'''
109
110[[rule.threat]]
111framework = "MITRE ATT&CK"
112
113[[rule.threat.technique]]
114id = "T1552"
115name = "Unsecured Credentials"
116reference = "https://attack.mitre.org/techniques/T1552/"
117
118[[rule.threat.technique.subtechnique]]
119id = "T1552.007"
120name = "Container API"
121reference = "https://attack.mitre.org/techniques/T1552/007/"
122
123[rule.threat.tactic]
124id = "TA0006"
125name = "Credential Access"
126reference = "https://attack.mitre.org/tactics/TA0006/"

Triage and analysis

Investigating Kubernetes 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. In EKS and other managed clusters, this can be abused to mint tokens for more privileged service accounts (including IRSA-linked ones) and pivot to cloud APIs.

What to review first

  • Actor and origin:
    • user.name / kubernetes.audit.user.username
    • source.ip / kubernetes.audit.sourceIPs
    • user_agent.original / kubernetes.audit.userAgent
    • For cloud identity, review kubernetes.audit.user.extra.* (e.g., arn, principalId).
  • Targeted service account:
    • kubernetes.audit.objectRef.namespace and kubernetes.audit.objectRef.name
    • kubernetes.audit.requestURI (should resemble /api/v1/namespaces/<ns>/serviceaccounts/<sa>/token)
  • Token issuance hints:
    • kubernetes.audit.annotations.authentication_kubernetes_io/issued-credential-id (token JTI/issued credential id)

Scoping

  • Identify which Role/ClusterRoleBindings grant the actor create on serviceaccounts/token in the affected namespace.
  • Pivot on the same user.name and source.ip for follow-on secret reads, pod exec, RBAC changes, or cloud API calls.

Response and remediation

  • If unauthorized, remove/revert the RBAC permission that allows TokenRequest (serviceaccounts/token) and rotate the affected service account credentials where applicable.
  • For IRSA/workload identity cases, rotate/revoke the cloud role session pathways and review cloud audit logs for API activity from the time window of the token mint.

References

Related rules

to-top