|Container, Node||Identity||Valid Accounts, T1078|
Represents the capacity to act as an Identity via ownership of a service account token, user PKI certificate, etc.
Authentication to the K8s API is performed via passing certificates, static tokens or OIDC tokens in the API request. This edge represents the ability to assume an identity using either acquired credentials (such as a service account token) or the intrinsic identity of a resource in K8s such as executing commands from inside a pod with a bound serviceaccount.
Control of execution within a container with a bound serviceaccount or access to a node file system.
Check for a mounted service account tokens or secrets:
Check the kubelet configuration:
This should contain the paths of the kubelet user certificates that we can steal to impersonate the node user:
Check the file(s) are accessible:
Assuming a valid token is recovered from e.g a mounted service account a token is found it can be used to interact with the K8s API, to potentially access new resources:
The kubelet PKI certificates can be used to authenticate to either the kubelet or the K8s API:
- Monitor for installation and/or execution of kubectl within pods. This is anomalous activity but may be triggered by legitimate SRE or developer activities.
- Interacting directly with the K8s API via non-standard tools e.g curl could be observed via the User-Agent field in audit logs. However, this is attacker controlled so should not be relied on.
Implement security policies
Use a pod security policy or admission controller to prevent or limit the identities under which new pods can run.