Kubernetes and Container Security Testing Guide

Why Kubernetes Pentest Is a Distinct Discipline

A Kubernetes cluster running production workloads is a multi-tenant operating system. The control plane (API server, scheduler, controller manager, etcd) sits at the centre and brokers all object creation. Worker nodes execute pods. Service accounts authenticate workloads. RBAC controls what each principal can do. Admission controllers enforce policy at object-creation time. Network policies control east-west traffic. None of this exists in a traditional Linux server.

Indian SaaS, fintech and enterprise customers are now running production on EKS (AWS), AKS (Azure), GKE (GCP), Rancher, OpenShift and self-managed kubeadm clusters. The attack surface is the same in shape across providers, with managed-control-plane variations. A Kubernetes pentest tests the cluster as a graph of permissions and objects, not as a list of hosts.

Methodology: External, Internal, Configuration

Our Kubernetes pentest runs three tracks. External tests the exposed surface (public API server endpoint, ingress controllers, dashboard exposure, kubelet ports). Internal tests assumed-compromise from inside a pod or a service account token. Configuration review uses cluster-admin read-only credentials with tools like kube-bench (CIS benchmark), kubeaudit, Polaris, KubeLinter, Trivy operator and Kubescape for policy compliance scoring.

We map findings to the CIS Kubernetes Benchmark for the managed-provider variant, the Microsoft AKS / AWS EKS / Google GKE provider-specific security guidance, and OWASP Kubernetes Top 10 plus NSA / CISA Kubernetes Hardening Guidance. Customers get a single report that satisfies the platform engineering team and the SOC 2 / ISO 27001 auditor.

Cluster Enumeration

From a pod-level foothold, enumeration starts with kubectl auth can-i --list which lists everything the current service account is permitted to do. Tools like kube-hunter, kubiscan, kube-bench, and rbac-tool simplify this. We extract the service account token from /var/run/secrets/kubernetes.io/serviceaccount/, identify the namespace, then enumerate Roles, RoleBindings, ClusterRoles, ClusterRoleBindings and the implicit graph of permissions.

Common discoveries: a low-privilege application pod whose service account can list secrets across the namespace (which then exposes other applications' credentials), a service account with create-pod permission (which leads directly to privileged-pod abuse for node compromise), or a service account with impersonate verbs (which lets the attacker assume any other identity in the cluster). Each is a quick path to broader compromise.

RBAC Misconfigurations and Privilege Escalation

RBAC is where most Kubernetes pentests find their highest-impact issues. The Kubernetes RBAC model is powerful and unforgiving. A single wildcard in a Role or ClusterRole effectively grants admin within the scope.

Common escalation primitives include: pods/exec on any pod (lets you exec into another workload), secrets/get or list at namespace or cluster level (exposes credentials), create on pods (lets you schedule a privileged pod and own the node), impersonate on users or service accounts (lets you assume any identity), create on rolebindings or clusterrolebindings (lets you grant yourself cluster admin), escalate verb on roles (often overlooked, allows privilege escalation through role editing).

Tools: rbac-police, kubectl-who-can, rakkess, kubectl-access-matrix, and BloodHound-equivalent visualisers like KubeHound make these paths visible. A clean enumeration in a typical Indian SaaS cluster surfaces 3 to 10 escalation paths from default service-account positions.

Pod Escape: From Container to Node

Once an attacker can create or exec into a privileged pod, escape to the underlying node follows quickly. The simplest path is a pod with the privileged: true flag, which gives the container effectively root on the host. From there, chroot into the host's root filesystem mounted at /host or accessed through /proc/1/root, and you are root on the node, with access to every other pod's secrets and runtime.

hostPath, hostPID, hostNetwork, hostIPC

A pod with hostPath: / mounts the entire host filesystem inside the container, readable and writable. A pod with hostPID joins the host's PID namespace, exposing every process on the node. hostNetwork puts the pod on the host's network stack, bypassing network policies and exposing the kubelet localhost endpoints. hostIPC shares memory with the host. Any one of these is enough to break out.

Capabilities and Seccomp

A container with CAP_SYS_ADMIN, CAP_NET_ADMIN or CAP_SYS_PTRACE can escape through kernel features (mounting filesystems, manipulating network namespaces, attaching to host processes). Containers without an explicit seccomp profile use the default which still allows many syscalls that have been used in escape research over the years.

Control Plane and etcd

On managed clusters (EKS, AKS, GKE), the control plane is hidden behind the provider's API; pentesters do not access etcd directly. On self-managed clusters (kubeadm, kops, on-prem), etcd is operated by the customer and can sometimes be exposed.

If etcd port 2379 is reachable from a worker node or from anywhere outside the control plane, and client certificate authentication is not enforced, an attacker can read every secret in the cluster and write new objects bypassing the API server (which means bypassing admission controllers, audit logging and RBAC). We test reachability and authentication; we never run destructive writes.

Image Scanning and Supply Chain

Container images are scanned for known vulnerable packages using Trivy, Grype, Snyk Container or Anchore. Layer-by-layer review surfaces shadowed older base images, embedded secrets (especially in earlier layers that are still in the image even after deletion in a later layer), and unnecessary tools that increase blast radius (curl, wget, apt, package managers in production images).

Supply chain testing covers image signing (cosign, Notary v2), software bill of materials (SBOM), and the path from developer commit to image push to admission controller. A misconfigured admission controller that does not enforce image-signature validation makes the entire signing program theatre.

Network Policies and Runtime Defence

Default Kubernetes networking allows any pod to reach any other pod. NetworkPolicy resources restrict this, but they only work if the CNI (Calico, Cilium, weave) enforces them. We test that declared NetworkPolicies are actually enforced and that the egress restrictions hold against the metadata API of the underlying cloud (a recurring pivot path).

Runtime defence (Falco, Tracee, Aqua, Sysdig) detects anomalous in-cluster activity. We coordinate with the SOC team during the engagement to validate detection coverage. Where detection is absent, that is itself a finding in the report.

Closing remediation guidance covers Pod Security Standards (PSS) replacing the deprecated Pod Security Policies, OPA Gatekeeper or Kyverno admission policies, namespace-level resource quotas and limits to bound denial-of-service blast, and rotation of service account tokens including projected service account tokens for short lifetimes.