|Unsecured Credentials, T1552
This attack represents the ability to steal a K8s API token from an accessible volume.
An attacker with access to a pod with an automounted serviceaccount token (the default behaviour) can steal the serviceaccount access token to perform actions in the K8s API. More significantly if an attacker is able to access all or part of the K8s node filesystem e.g via a
hostPath mount, an attacker could retrieve the service account tokens for ALL pods running on the node. This attack is possible from access to a container or node and each case is discussed separately throughout.
- A service account token mounted into the container via a projected volume (default behaviour).
- Access to a K8s node filesystem (
/var/lib/kubelet/podsor any parent directory)
Check whether a serviceaccount token is automounted:
Check whether a host volume mount provides access to other pods' tokens:
KDigger can also help with this.
Confirm access to the location of pod tokens:
See IDENTITY_ASSUME for how to use a captured token.
From within a container read the service account token mounted in the default location:
Steal access tokens for ALL pods running on the node:
find /var/lib/kubelet/pods/ -name token -type l 2>/dev/null
- Monitor for access to well-known K8s secrets paths from unusual processes.
Prevent service account token automounting
When a pod is being created, it automatically mounts a service account (the default is default service account in the same namespace). Not every pod needs the ability to access the API from within itself.
From version 1.6+ it is possible to prevent automounting of serviceaccount tokens on pods using: