On a cloud provider the cluster boundary is not the security boundary. Every pod on a node can inherit a broad node role unless something stops it, so one compromised container can become a breach of the whole cloud account.
- Give each workload its own cloud identity bound to its service account (EKS Pod Identity or IRSA, Workload Identity Federation for GKE, Microsoft Entra Workload ID on AKS) and keep node roles minimal.
- Block pods from the instance metadata service with network policy, and require IMDSv2 on AWS hosts.
- Never store static, long-lived cloud credentials in Secrets, ConfigMaps or images.
- Detect unexpected tools, shells and metadata connections inside containers with runtime monitoring.
Guides on this site
Harden managed Kubernetes on EKS, AKS and GKE
Know what your provider secures and what you still own, then lock down API access, cloud identity, nodes, pod privileges and admission with settings that are generally available in Kubernetes 1.37, checked against the CIS and NSA/CISA baselines.
Apply a security baseline across AWS, Azure and Google Cloud
Give workloads platform identities instead of keys, guard the instance metadata endpoint, block public storage, keep audit logs past the default retention, close inbound admin ports and use the native secret store, with tested Terraform for AWS, Azure and Google Cloud.
Detect container and host threats at runtime with eBPF sensors and cloud services
Watch process, file and network activity inside containers with an eBPF sensor or a managed cloud agent, write and test rules for the attacks you expect, tune them with narrow exceptions and contain a compromised pod without destroying evidence.
References
List data from the publisher. A guide is listed as the main subject when the weakness or risk is what the guide is about, and as covering it when a dedicated section or worked example addresses it.