|PermissionSet||Identity||Steal Application Access Token, T1528|
An identity with a role that allows get on secrets (vs list) can potentially view all the serviceaccount tokens in a specific namespace or in the whole cluster (with ClusterRole).
An attacker in possession of a token with permission to read a secret cannot use this permission without knowing the secret’s full name. This permission is different from the list secrets permission described in TOKEN_LIST. However it may be possible to extract secrets via bruteforce for all K8s serviceaccounts due to their predictable naming convention.
Ability to interrogate the K8s API with a role allowing get access to secrets.
See the example pod spec.
Simply ask kubectl:
Exploitation of this vulnerability can be complex and time-consuming. See the original research for a detailed description for the steps required.
- Monitor anomalous access to the secrets API including listing all secrets, unusual User-Agent headers and other outliers.
- Alert on anomalous volume of requests to the secrets API in a short time period.
Implement least privilege access
Even get on secrets is a very powerful privilege and should not be required by the majority of users. Use an automated tool such a KubeHound to search for any risky permissions and users in the cluster and look to eliminate them.