cloud-kuberneteslisted

# Kubernetes attacks ## When it applies A Kubernetes control-plane or node component is reachable (externally or from a pod foothold), or you landed in a container inside a cluster and want to escalate to cluster admin / other tenants. ## Why it works k8s exposes powerful HTTP APIs that are frequently unauthenticated or over-permissioned: anonymous API access, kubelet read/exec on 10250, unauth etcd (all secrets), and mounted service-account tokens with broad RBAC. One over-scoped token = cluster takeover. ## Method 1. **From outside**: `kube-hunter`; probe API server 6443 (`/api/v1` anonymous), kubelet 10250 (`/pods`, `/run` exec), etcd 2379 (keys→secrets), and exposed dashboards (8443/anonymous). 2. **From a pod**: read the mounted token `/var/run/secrets/kubernetes.io/serviceaccount/`; `kubectl auth can-i --list` to see what it grants. 3. **Escalate via RBAC**: over-permissioned SA → create/exec pods, read secrets across namespaces, or `create pods` with a hostPath/privileged spec to mount the node (→ node/cluster takeover). 4. **Container→node breakout**: privileged pod, hostPID/hostNetwork, or a hostPath mount to the host filesystem (→ `cloud-container-escape`). 5. **Loot**: `kubectl get secrets -A`, cloud IAM via node metadata (→ `cloud-imds-ssrf`). ## Gotchas - `kubectl auth can-i --list` first — it tells you exactly what the token can do; don't guess. - Anonymous API/kubelet is common in labs and misconfigured clusters — always test unauth. - On bug bo