Skip to content

Kubernetes Red Teaming & Labs

Why Hands-On K8s Security Practice Matters

RBAC policy can look perfectly reasonable on paper and still grant a service account far more than it needs - you don't find that gap by reading YAML, you find it by actually asking the cluster "what can this identity do?" and following the answer. Cluster misconfigurations are largely invisible until someone actually tries to exploit them, which is why hands-on practice (in a lab, not production) is a core skill for anyone doing Kubernetes security work, not an optional extra.

Read Kubernetes Security and OWASP Kubernetes Top 10 first - testing without knowing what you're testing for just produces unstructured poking, not a defensible assessment.

A Basic Kubernetes Security Assessment Methodology

  1. Enumerate what you actually have access to. kubectl auth can-i --list tells you every action your current identity is authorized for - run it as different service accounts to find over-permissioned ones. Check for mounted service account tokens inside running pods (/var/run/secrets/kubernetes.io/serviceaccount/token) - a compromised pod inherits whatever that token can do.
  2. Check for exposed components. Is the Kubernetes Dashboard reachable without authentication? Is the kubelet API (port 10250) reachable from outside the cluster? Is etcd's client port (2379) reachable from anywhere other than control-plane nodes? See OWASP Kubernetes Top 10's K06 category for why this matters.
  3. Audit RBAC bindings for over-permissioning. Look for ClusterRoleBindings to cluster-admin that shouldn't exist, and wildcard verbs/resources ("*") on roles bound to workload service accounts.
  4. Check NetworkPolicy coverage. Are there namespaces with zero NetworkPolicies, meaning every pod can reach every other pod by default? See Kubernetes Security.
  5. Check Pod Security Admission levels per namespace, and look for individual workloads running privileged, as root, or with dangerous hostPath mounts.
  6. Check for cluster-to-cloud exposure. Does a pod's service account map to an overly broad cloud IAM role (AWS IRSA, GCP Workload Identity)? See Kubernetes Attack Techniques and OWASP Kubernetes Top 10's K08 category.

Real Tools

Tool What It Does
kube-hunter (Aqua Security) External/internal Kubernetes penetration testing scanner - finds exposed components and known misconfigurations automatically
kube-bench (Aqua Security) Checks a cluster against the CIS Kubernetes Benchmark
Peirates Kubernetes penetration testing framework - automates privilege escalation and lateral movement paths once you have initial pod access
kubescape (ARMO, CNCF incubating) Scans against NSA, MITRE ATT&CK, and CIS frameworks in one tool
kubeaudit (Shopify) Audits clusters for common security misconfigurations (missing security contexts, default service account usage, etc.)

Run kube-bench and kubescape as a baseline first - they're fast and catch the low-hanging fruit. Use kube-hunter and Peirates for a more adversarial simulation once the basics are covered.

Practice Labs

Lab Focus
Kubernetes Goat (MadhuAkula) Vulnerable-by-design Kubernetes cluster - one of the most popular hands-on K8s security labs, with documented vulnerabilities and walkthroughs
Bust-a-Kube / ControlPlane Simulator Attack/defense simulator for practicing both offensive and defensive K8s skills
KillerCoda Kubernetes playgrounds Free, browser-based K8s environments - no local setup required
CNCF Capture the Flag (KubeCon archives) Past KubeCon CTF challenges, reusable for self-study

Certification Path

Credits/References

  1. NSA/CISA Kubernetes Hardening Guidance v1.2
  2. CIS Kubernetes Benchmark
  3. kube-hunter, kube-bench, Peirates, kubescape
  4. Kubernetes Goat