Container and Kubernetes security testing has become a critical discipline as organizations adopt containerized workloads at scale. A misconfigured Kubernetes cluster can expose an organization's entire cloud infrastructure to lateral movement and data exfiltration — and the misconfigurations are extraordinarily common. Kubernetes ships with permissive defaults — the CNCF-commissioned 2019 Kubernetes security audit by Trail of Bits and Atredis Partners flagged confusing default settings, insecure TLS in use by default, and policies that may silently fail to apply (CNCF Kubernetes Security Audit, 2019) — so production clusters require deliberate hardening against benchmarks like the CIS Kubernetes Benchmark rather than relying on out-of-the-box configuration. This guide covers the full container security testing methodology, from Docker daemon exposure to Kubernetes RBAC exploitation and etcd security.
Docker Security: Daemon Exposure and Container Escape
Docker Daemon Exposure
The Docker daemon, if exposed on a TCP socket without TLS authentication, provides root-equivalent access to the host. The default Docker configuration listens on a Unix socket (/var/run/docker.sock) accessible only to root — but many CI/CD and container management configurations expose the TCP socket for remote management:
dockerd -H tcp://0.0.0.0:2375
An attacker with access to port 2375 can execute commands on the host by mounting the host filesystem into a privileged container:
docker -H tcp://<target>:2375 run -v /:/mnt --rm -it alpine chroot /mnt sh
This provides a root shell on the host in seconds. Even the Docker Unix socket, if accessible within a container via volume mount, provides the same capability. Never mount /var/run/docker.sock into containers unless absolutely required, and ensure TCP socket exposure uses mutual TLS authentication.
Privileged Container Escape
Containers running with the --privileged flag have full access to the host's devices and can load kernel modules, mount the host filesystem, and interact with the host network namespace. Privileged container escape is trivial:
mount /dev/sda1 /mnt && chroot /mnt bash
More subtle than full --privileged are specific dangerous capability grants. The CAP_SYS_ADMIN capability enables many host-level operations; CAP_NET_ADMIN allows modifying host network interfaces; CAP_SYS_PTRACE allows attaching to host processes. Each of these individually creates container escape paths that a skilled attacker can exploit.
hostPath Volume Exploitation
Kubernetes PodSpecs with hostPath volume mounts expose host filesystem paths within the container. A pod mounting /etc, /var/lib/kubelet, or /proc can read sensitive host configuration, extract credentials, or modify host-level files. Mounting / (the root filesystem) is equivalent to privileged container escape.
Kubernetes RBAC Misconfigurations
Kubernetes Role-Based Access Control (RBAC) is complex, and misconfiguration is the norm rather than the exception in production clusters. The most common critical RBAC findings in penetration test engagements include:
- Wildcard permissions: ClusterRoles granting
resources: ["*"]withverbs: ["*"]effectively grant cluster-admin equivalence. Disturbingly common in operator-generated RBAC manifests. - Cluster-admin RoleBindings: Binding the
cluster-adminClusterRole to service accounts used by non-administrative workloads - list/get on secrets: A role that allows listing or getting Kubernetes Secrets can read all secrets in the bound namespace, including service account tokens and application credentials
- create on pods or deployments: The ability to create pods is functionally equivalent to code execution on any node, since the pod specification controls the container image, capabilities, and volume mounts
- impersonate verb: Allowing a service account to impersonate other users or service accounts enables privilege escalation to any impersonatable identity
Service Account Token Abuse
Every Kubernetes pod is automatically mounted with a service account token unless automountServiceAccountToken: false is set. This token, readable at /var/run/secrets/kubernetes.io/serviceaccount/token, authenticates to the Kubernetes API server as the pod's service account. An attacker who achieves code execution in any container can extract this token and query the API:
TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
curl -H "Authorization: Bearer $TOKEN" https://kubernetes.default.svc/api/v1/namespaces/default/secrets
If the service account has excessive permissions — a common finding — this provides access to cluster secrets, the ability to create privileged pods, and potential cluster-admin escalation.
etcd Security
etcd is the Kubernetes backing store for all cluster state, including Secrets objects. Kubernetes Secrets are stored base64-encoded (not encrypted) in etcd by default. An attacker with direct access to etcd — either through network exposure or by compromising a control plane node — can extract all cluster secrets:
etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key get / --prefix --keys-only
Encryption at rest for etcd must be explicitly configured via the EncryptionConfiguration API resource. AES-GCM or Secretbox encryption should be enabled for all secret types. etcd should be network-accessible only from the Kubernetes API server — never directly from worker nodes or external networks.
Network Policy Bypass and Multi-Tenancy Risks
Kubernetes NetworkPolicies restrict pod-to-pod communication, but they require a network plugin (CNI) that enforces them. Clusters using the default kubenet CNI or a CNI that does not implement NetworkPolicy enforcement have no effective network segmentation between pods, regardless of what NetworkPolicy objects are defined. Always verify that the CNI enforces NetworkPolicy and that default-deny policies are in place before relying on NetworkPolicy for tenant isolation.
Security Assessment Tools
- kube-bench: Runs CIS Kubernetes Benchmark checks and reports compliance failures with remediation guidance
- Trivy: Scans container images for CVEs and Kubernetes manifests for misconfigurations
- kubesec: Scores Kubernetes resource manifests against security best practices
- kube-hunter: Active hunting for security weaknesses in Kubernetes clusters
- Falco: Runtime security monitoring for containers using eBPF-based syscall inspection
CIS Kubernetes Benchmark compliance is required for many regulatory frameworks. Running kube-bench as part of cluster provisioning and on a recurring basis identifies control failures before they are exploited. Our penetration testing engagements include Kubernetes security assessments as a standalone service or as part of broader cloud security reviews. Contact Fortress MSSP to assess your container security posture.