This is the second part of the Container Security Red Team Notes series. In this post, we will focus on privilege escalation, lateral movement, and persistence within a Kubernetes cluster.
3. Privilege Escalation & Lateral Movement
Service Accounts
Kubernetes mounts a service account token at /var/run/secrets/kubernetes.io/serviceaccount/token. If this account has excessive permissions (like cluster-admin), it can be used to take over the cluster.
# Check permissions with kubectl (if installed)
kubectl auth can-i --list
Cloud Metadata Services
If the cluster is running on a cloud provider (AWS, Azure, GCP), the instance metadata service might be accessible from the pod.
# AWS Metadata
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
4. Persistence
Persistence can be achieved by deploying malicious pods, creating backdoored images, or modifying cluster configurations (e.g., ValidatingAdmissionWebhooks).
Malicious Admission Controllers
An attacker with sufficient privileges can deploy a MutatingAdmissionWebhook that injects a sidecar container into every new pod, allowing them to intercept traffic or execute commands.
Shadow API Server
Creating a static pod manifest on a control plane node can launch a rogue API server or a privileged pod that persists even after the original entry point is closed.
Conclusion
Container security requires a defense-in-depth approach. Securing the supply chain, hardening the runtime environment, and monitoring for anomalous behavior are key to preventing these attacks.