How Compromised Cloud Resources Can Lead to Kubernetes Cluster Takeover
Summary
Wiz describes how stolen cloud keys, exposed kubeconfig files, and compromised container registries can enable cloud-to-Kubernetes lateral movement, and recommends credential, access-control, and registry protections.
Key points
- Wiz reports that about 15% of cloud environments using managed Kubernetes have a workload containing a cleartext long-term cloud key tied to an identity with highly privileged Kubernetes permissions.
- Compromised cloud credentials may enable cluster access through generated kubeconfig files; the potential impact depends on provider configuration and identity permissions.
- Wiz says about 87% of cloud environments using AKS clusters rely on local accounts with Kubernetes RBAC, which the article describes as the least secure authentication and authorization method.
- AKS kubeconfig files may contain plaintext certificates or, with AAD authentication, access and refresh tokens; the refresh token is valid by default for 90 days.
- An attacker able to overwrite container registry images could add a backdoor that executes when a Kubernetes pod pulls the modified image.
- Recommended safeguards include avoiding long-term workload keys, removing kubeconfig files from exposed workloads, restricting API-server access, and tightening registry policies and network access.
Article Details
- Defense Focus
- Reduce cloud-to-Kubernetes lateral movement and cluster takeover risks involving compromised cloud credentials, exposed kubeconfig files, and compromised container registries.
- Platforms
- EKS
- GKE
- AKS
- ECR
- GCR
- GAR
- ACR
- Defensive Actions
- Avoid storing long-term cloud keys in workloads; attach IAM roles, service accounts, or managed identities with minimum required permissions and use automatically rotated temporary credentials.
- Remove kubeconfig files from publicly exposed workloads, and tightly restrict access to workloads that must retain kubeconfig files and cloud keys.
- Use a private Kubernetes API server endpoint where feasible and restrict access to the authenticating workload with security-group rules limited to specific IP addresses.
- Restrict container-registry access to trusted principals and prevent public or unauthenticated access.
- For ECR repositories, use strict resource-based policies without wildcards in the Principal field and enable tag immutability.
- For ACR, restrict network access with firewall rules or a private endpoint.
- For GCR storage buckets, prevent public access and consider applying the storage.publicAccessPrevention organization policy.
- For GAR repositories, apply strict repository-specific IAM policies and restrict access for allUsers and allAuthenticatedUsers.
MITRE ATT&CK
T1525 · Implant Internal ImageThe article describes compromising a container registry and overwriting a legitimate image with a backdoored image that executes when pulled by a new pod.T1528 · Steal Application Access TokenThe article describes abusing OAuth access and refresh tokens, including refresh tokens found in an AAD-authenticated AKS kubeconfig, to authenticate to clusters.T1552.001 · Credentials In FilesThe article describes adversaries obtaining cleartext long-term cloud keys stored in cloud workloads.T1552.004 · Private KeysThe article describes attackers using discovered kubeconfig files, which may contain plaintext certificates, keys, or tokens, to authenticate to Kubernetes clusters.
Vendors
Products
ACRMany containers running in managed Kubernetes clusters use images pulled from a cloud container registry service such as ECR, GCR/GAR (the successor of GCR) and ACR. AKSfile or long-term service principal credentials and abuse their permissions to authenticate to an AKS cluster in the tenant. The impact of such compromise, however, depends on whether a local account or AADECRMany containers running in managed Kubernetes clusters use images pulled from a cloud container registry service such as ECR, GCR/GAR (the successor of GCR) and ACR. EKSAn attacker that has compromised AWS cloud keys (e.g. user access keys) might be able to generate a kubeconfig file and authenticate to an EKS cluster, depending on the identity with which the keys are associated: GARMany containers running in managed Kubernetes clusters use images pulled from a cloud container registry service such as ECR, GCR/GAR (the successor of GCR) and ACR. GCRMany containers running in managed Kubernetes clusters use images pulled from a cloud container registry service such as ECR, GCR/GAR (the successor of GCR) and ACR. GKEduring the initial authentication) might be able to generate a kubeconfig file and authenticate to a GKE cluster in the tenant, depending on the user’s permissions. Kubernetesthis series covering lateral movement in the cloud, we introduced lateral movement techniques from the Kubernetes to the cloud domain and examined how they differ between the major CSPs depending on their default