Skip to content


Source Destination MITRE
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:

kubectl auth can-i get secrets


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.