Kubernetes
8 min readMarch 20, 2026

Securing AWS EKS with Bottlerocket: A Defense Against 'BadPods'

Can a single misconfigured pod compromise your entire EKS cluster? Explore how the 'BadPods' series exposes critical vulnerabilities and why AWS Bottlerocket is the ultimate structural defense.

AJ
Ajeet Yadav
Founder, Coding Protocols
Securing AWS EKS with Bottlerocket: A Defense Against 'BadPods'

In the world of Kubernetes, security is often treated as a layer of configuration—RBAC policies, NetworkPolicies, and Admission Controllers. But what happens when those layers fail?

A recent series by CyberSec Nerds titled "BadPods" highlights a terrifying reality: on standard EKS node deployments (like Amazon Linux), a single misconfigured pod can lead to a full cluster and cloud account compromise in seconds.

Today, we’re looking at why these "BadPods" work and how switching to AWS Bottlerocket provides a structural defense that simple configuration cannot match.


The "Everything Allowed" Pod: A Perfect Storm

The "BadPods" series starts with a manifest that enables every dangerous flag available in the Kubernetes API:

yaml
1apiVersion: v1
2kind: Pod
3metadata:
4  name: everything-allowed-exec-pod
5spec:
6  hostNetwork: true
7  hostPID: true
8  hostIPC: true
9  containers:
10  - name: pentest-container
11    image: ubuntu
12    securityContext:
13      privileged: true
14    volumeMounts:
15    - mountPath: /host
16      name: noderoot
17  volumes:
18  - name: noderoot
19    hostPath:
20      path: /

On a standard Amazon Linux node, this pod is a skeleton key. Because privileged: true is set and the root filesystem is mounted at /host, an attacker can simply run:

bash
chroot /host /bin/bash

Suddenly, they aren't just in a container; they are the root user on the EC2 instance. From there, they can steal IAM credentials via the Instance Metadata Service (IMDS), access other pods' data, or even destroy the node itself.


Why Standard AMIs Are Vulnerable

General-purpose operating systems like Amazon Linux 2023 or Ubuntu are designed for flexibility. They include:

  • Package Managers (yum, apt) that attackers can use to install hacking tools.
  • Shells and Interpreters (bash, python) that make lateral movement easy.
  • Mutable Filesystems, allowing an attacker to persist their presence on the node.

In a "BadPod" scenario, the flexibility of the host OS becomes its greatest liability.


The Bottlerocket Defense: Security by Design

AWS Bottlerocket isn't a general-purpose Linux. It is a purpose-built, open-source OS designed exclusively for running containers. It mitigates the "BadPod" threat through three core architectural choices:

1. Immutable Root Filesystem

On Bottlerocket, the root filesystem is read-only. It uses dm-verity to cryptographically verify the integrity of the OS at boot. Even if an attacker escapes to the host via a hostPath mount, they cannot modify the OS, install persistent backdoors, or alter system binaries.

2. Zero-Shell Surface Area

Bottlerocket contains no package manager and no interactive shell by default. Administrative access is performed through a separate, ephemeral "admin container" or a filtered API. For an attacker who manages to chroot /host, there is no bash to run, no curl to fetch payloads, and no apt to install tools. The environment is a dead end.

3. Enforcing SELinux Policies

While standard AMIs support SELinux, Bottlerocket ships with SELinux in enforcing mode by default, with policies specifically tuned for container isolation. Even a "privileged" container is still restricted by mandatory access controls that prevent it from accessing sensitive host paths or interference with other container runtimes.


Comparison: Mitigating the Escape

FeatureAmazon Linux 2023AWS Bottlerocket
Root FilesystemMutable (Read/Write)Immutable (Read-Only)
Default ShellBash/Zsh includedNone (Excluded)
Package ManagerDNF/Yum presentNone (Excluded)
Update MechanismPackage-by-packageAtomic Image-based Updates
Attack SurfaceBroadMinimal

How to Migrate Your EKS Cluster

Switching to Bottlerocket is straightforward if you are using EKS Managed Node Groups. You simply update your Node Group configuration to use the BOTTLEROCKET_x86_64 or BOTTLEROCKET_ARM_64 AMI type.

If you're using Terraform, it looks like this:

hcl
1module "eks" {
2  source  = "terraform-aws-modules/eks/aws"
3  # ... other config ...
4
5  eks_managed_node_groups = {
6    bottlerocket_nodes = {
7      ami_type = "BOTTLEROCKET_x86_64"
8      platform = "bottlerocket"
9      
10      # Bottlerocket specific settings
11      bootstrap_extra_args = <<-EOT
12        [settings.kubernetes]
13        "max-pods" = 110
14      EOT
15    }
16  }
17}

Conclusion

The "BadPods" series is a wake-up call for Kubernetes administrators. While we should always enforce Pod Security Standards (PSS) and use tools like Kyverno or OPA, our last line of defense should be the host itself.

By moving away from general-purpose AMIs and adopting Bottlerocket, you transform your nodes from a target-rich environment into a hardened, immutable foundation that can withstand even the most privileged misconfigurations.


Want to visualize your own EKS security posture? Download Podscape to get real-time insights and security audits for your clusters.

Related Topics

AWS
EKS
Bottlerocket
Kubernetes Security
DevOps
K8s

Read Next