How to Prevent Lateral Movement from Kubernetes to the Cloud
Summary
Wiz explains how attackers can move from compromised Kubernetes pods or nodes into cloud environments, reports exposure findings across managed clusters, and recommends controls to reduce the risk.
Key points
- Attackers may query the Instance Metadata Service from compromised pods to obtain worker-node credentials and access cloud resources; the impact depends on the permissions assigned to those identities.
- Wiz found about 40% of examined cloud environments with managed Kubernetes had at least one pod containing a cleartext, long-term cloud key in its image.
- Wiz also found about 10% of such environments had a publicly exposed pod with exploitable critical or high-severity vulnerabilities and a highly privileged cloud identity.
- Pod service-account identities, secrets containing long-term keys, and pod escapes can provide other paths to cloud credentials and privileges.
- The article says kubelets across the three major cloud providers can read cluster resources, including secrets; AKS kubelet permissions may also allow certain Kubernetes objects to be changed.
- Recommended controls include limiting metadata access, using workload identities with least privilege, enforcing pod security standards, tightening RBAC, removing long-term cloud keys, patching exposed containers, and restricting pod-to-pod traffic.
Article Details
- Defense Focus
- Prevent lateral movement from compromised Kubernetes pods or nodes into cloud identities and resources.
- Detection Methods
- Continuously scan publicly exposed container images and remediate critical vulnerabilities.
- Data Sources
- Kubernetes pods, service accounts, Secrets, and RBAC permissions
- Cloud IAM identities, roles, and permissions assigned to worker nodes and pod service accounts
- Container image scan findings
- Rule Types
- Kubernetes NetworkPolicy egress rules to block pod access to the IMDS endpoint
- Pod Security Standards admission policies, with at least the baseline policy for sensitive namespaces
- Kubernetes RBAC permissions for reading Secrets, creating workloads, and executing into pods
- Platforms
- EKS
- GKE
- AKS
- Kubernetes
- Defensive Actions
- Use IAM Roles for Service Accounts, Workload Identity, or Azure AD workload identity with only the permissions each workload needs.
- Restrict pod access to node IMDS endpoints; for EKS, the article recommends IMDSv2, a response hop limit of 1, and disabling hostNetwork where applicable.
- Apply a Kubernetes NetworkPolicy to block metadata access from relevant pods, including access to 169.254.169.254/32.
- Enforce at least the baseline Pod Security Standards policy in namespaces containing sensitive workloads.
- Use strict Kubernetes RBAC; avoid granting non-admin subjects permission to read Secrets, create workloads, or exec into pods.
- Avoid storing long-term cloud keys in Kubernetes Secrets or pods.
- Continuously scan container images and remediate critical vulnerabilities in publicly exposed containers.
- Use network policies to restrict pod-to-pod communication and limit the scope of a compromise.
MITRE ATT&CK
T1078.004 · Cloud AccountsThe article describes using retrieved or exposed cloud identity credentials to assume cloud identities and access cloud resources.T1552.005 · Cloud Instance Metadata APIThe article describes querying the cloud Instance Metadata Service from compromised pods to retrieve worker-node identity credentials.T1552.007 · Container APIThe article describes using Kubernetes API access to list Secrets and extract long-term cloud credentials or service-account tokens.T1580 · Cloud Infrastructure DiscoveryThe article describes abusing worker-node permissions to enumerate EC2 instances and retrieve associated cloud network details.T1610 · Deploy ContainerThe article describes creating a pod on a compromised AKS node and attaching an existing Kubernetes service account to it.T1611 · Escape to HostThe article describes escaping a pod to reach its underlying host and potentially access other pods on that host.T1613 · Container and Resource DiscoveryThe article describes enumerating container registries and their images using worker-node permissions.
Threat Actors
Vendors
Amazon Web ServicesAWS requires several built-in managed policies to be attached to the worker node’s role in the EKS cluster.GCPGCP automatically attaches to new worker nodes the Compute Engine default service account with the overly permissive IAM basic editor role.Microsoft Azurepod access to cloud resources; it is named IAM Roles for Service Accounts, Workload Identity, or Azure AD workload identity, in AWS, GCP, and Azure, respectively.
Products
AKSWhen an AKS cluster is deployed, a provider-managed identity that administers cluster resources like ingress load balancers and file CSI drivers is automatically attached to the cluster’s control plane.Azure AD workload identityaccess to cloud resources; it is named IAM Roles for Service Accounts, Workload Identity, or Azure AD workload identity, in AWS, GCP, and Azure, respectively.EKSAWS requires several built-in managed policies to be attached to the worker node’s role in the EKS cluster.GKEGKE kubelet RBAC permissionsIAM Roles for Service Accountsof Least Privilege as it restricts nonessential pod access to cloud resources; it is named IAM Roles for Service Accounts, Workload Identity, or Azure AD workload identity, in AWS, GCP, and Azure, respectively.KubernetesIn this second blog post, we will analyze potential attack vectors for lateral movement between the Kubernetes and cloud domains and examine how they differ between the major CSPs depending on their default clusterPod Security Admission2. Adopt the Pod Security Admission (PSA)Workload Identityrestricts nonessential pod access to cloud resources; it is named IAM Roles for Service Accounts, Workload Identity, or Azure AD workload identity, in AWS, GCP, and Azure, respectively.