Access cloud resources

Info

ID: MS-TA9020
Tactic: Privilege Escalation, Lateral Movement
MITRE technique: T1078.004

If the Kubernetes cluster is deployed in the cloud, in some cases attackers can leverage their access to a single container to get access to other cloud resources outside the cluster. For example, AKS uses several managed identities that are attached to the nodes, for the cluster operation. Similar identities exist also in EKS and GKE (EC2 roles and IAM service accounts, respectively). By default, running pods can retrieve the identities which in some configurations have privileged permissions. Therefore, if attackers gain access to a running pod in the cluster, they can leverage the identities to access external cloud resources.

Also, AKS has an option to authenticate with Azure using a service principal. When this option is enabled, each node stores service principal credentials that are located in /etc/kubernetes/azure.json. AKS uses this service principal to create and manage Azure resources that are needed for the cluster operation. By default, the service principal has contributor permissions in the cluster’s Resource Group. Attackers who get access to this service principal file (by hostPath mount, for example) can use its credentials to access or modify the cloud resources.

Mitigations

ID	Mitigation	Description
MS-M9003	Adhere to least-privilege principle	Grant only necessary permission to the cloud identities.
MS-M9018	Restrict the access of pods to IMDS	Restrict the access of pods to IMDS to restrict pods from getting access to cloud identities.
MS-M9019	Allocate specific identities to pods	Use dedicated allocated identities to pods
MS-M9013	Restrict over permissive containers	Block mounting volumes with access to cloud credentials.