Mind the Gap! Bringing Together Cloud Services and Managed K8s Environments - Christophe Tafani

The talk discusses common pitfalls and traps in managed Kubernetes environments and how to bridge the gaps between what runs inside a managed Kubernetes cluster and what is deployed in other services of the cloud provider.

• Admins in AWS do not necessarily have permissions on their Kubernetes cluster
• External secrets can be brought into the cluster using different techniques
• Architecting cloud-native applications can benefit from the full power of cloud services while avoiding complete vendor lock-in
• Attackers can abuse mechanisms to pivot from exploiting a single containerized workload to compromising full cloud environments
• A tool is being released to help mitigate and handle some of the pitfalls and problems

The talk follows the journey of Kate, a cloud-native software engineer who builds a cat classifier app. She faces the challenge of not having permissions on her Kubernetes cluster despite being a full admin on AWS. This has implications for incident response and makes it hard to determine who is admining the EKS cluster. The talk also highlights the importance of protecting against attackers who can abuse mechanisms to pivot from exploiting a single containerized workload to compromising full cloud environments.

Many organizations run Kubernetes as part of managed offerings such as AWS EKS, Azure AKS or GCP GKE. But that’s only one part of the story; other pieces of infrastructure such as databases, object storage or legacy workloads generally live outside the cluster. In this context comes the need to bridge the gaps between what runs inside a managed Kubernetes cluster, and what is deployed in other services of the cloud provider. In this talk, we start by reviewing how the different cloud providers tackle authenticating and authorizing humans to the managed Kubernetes control plane, as well as individual workloads to the cloud provider API. Then, we dive into the different techniques to bring external secrets (e.g., from AWS Secrets Manager) inside the cluster. Along the way we cover how practitioners can leverage these mechanisms to architect cloud-native applications that benefit from the full power of cloud services, while avoiding complete vendor lock-in. We also describe how an attacker can abuse these mechanisms to pivot from exploiting a single containerized workload to compromising full cloud environments, and how to best protect against these attack vectors.