Presentation Material
Abstract
Many organisations that have adopted a cloud-native stack are under the misinterpretation that the security of Kubernetes (K8s) clusters fall within the remit of cloud service providers. This misconception leads them to believe that either cluster offensive security is not required, or is considered a low priority exercise. As a result, organisations are not fully aware of the business value-add and significance associated with engaging in offensive security testing for K8s cluster.
In my investigations across multiple organisations, it was observed that there is an underestimation regarding the potential risks associated with misconfigurations in K8s clusters and integrated components within the cloud-native stack.
In this talk, I will share why organisations need to conduct offensive security assessments on K8s clusters, along with attack chains reflecting real world techniques on infiltrating and exploitation of a K8s cluster. The audience will acquire knowledge on how to attack a K8s cluster and learn about key controls that enhance the security posture of K8s cluster using defense in depth methodology.
AI Generated Summary
The talk addresses widespread misconceptions that Kubernetes clusters are “secure by design” or solely the cloud provider’s responsibility, emphasizing the critical need for user-side security configurations. It presents real-world offensive security engagement findings, demonstrating that misconfigurations frequently lead to severe compromises.
Key attack chains illustrate how attackers pivot from seemingly low-privilege entry points to full cluster compromise. One chain exploited a CI/CD runner with excessive get secrets permissions, allowing token theft from a production pod running with cluster-admin rights. Another involved a non-production pod with storage-admin rights that inappropriately accessed production cloud storage buckets. A third demonstrated container escape via a privileged pod, enabling host filesystem access and subsequent deployment of a malicious pod for node shell access.
Practical takeaways stress a defense-in-depth strategy across the Kubernetes lifecycle. Core controls include enforcing least-privilege IAM roles (distinguishing get vs. list secrets), implementing strict network policies to isolate environments and restrict metadata API access, and running containers as non-root with read-only filesystems. Security must be integrated at build time (image scanning, signing, trusted registries), deployment (robust secrets management, Pod Security Policies in enforce mode), and runtime (workload segregation, continuous monitoring). The overarching lesson is that default Kubernetes configurations are insufficient; proactive, layered security based on threat modeling is essential to protect cloud-native environments.