Kubernetes Attack Vectors
Last reviewed: — verified against Kubernetes 1.36.
Kubernetes security threats arise from misconfigurations, weak access controls, and unprotected workloads. Attackers exploit these vulnerabilities to escalate privileges, move laterally, and compromise clusters. This page is the head reference for the major attack vector categories on this site, organized by the resource that is targeted and the privilege required to exploit it.
Why Attack Vectors Matter
Threat-led security work begins with understanding how clusters are actually compromised in the wild. The catalogue below maps to real techniques observed in MITRE ATT&CK for Containers and to public incidents involving exposed Kubernetes APIs, leaked service account tokens, and supply-chain compromise. Without this perspective, defensive work tends to optimise for compliance over actual exploitability.
Each linked article walks through the technique step by step, the attacker's preconditions, and the mitigation. Use the categories as a checklist when threat-modelling a new cluster or workload.
Mapping Attack Vectors to MITRE ATT&CK Tactics
The categories on this page align with MITRE ATT&CK for Containers. The table below shows where each category fits and the typical entry point an attacker exploits.
| Category | Primary ATT&CK Tactic | Typical Entry Point | Privilege Gained |
|---|---|---|---|
| API and Control Plane | Initial Access, Discovery | Exposed API server, kubelet, or dashboard | Cluster admin via the API |
| Container and Runtime | Privilege Escalation, Lateral Movement | Privileged or hostPath workloads | Node root from a pod |
| Identity and Access | Privilege Escalation, Credential Access | Overprivileged ServiceAccount tokens | Cluster-scoped permissions |
| Network | Lateral Movement, Collection | Lack of NetworkPolicy or exposed service | Pod-to-pod or pod-to-cloud reach |
| Secrets and Data | Credential Access, Collection | Plain-text Secrets, mounted volumes | Application credentials, IAM keys |
| Supply Chain | Initial Access, Persistence | Tampered image, malicious chart | Code execution at deploy time |
| Cloud Infrastructure | Credential Access, Discovery | Pod access to instance metadata | Cloud IAM credentials |
| Policy and Configuration | Defense Evasion, Impact | Disabled or bypassed admission control | Policy bypass, resource exhaustion |
Use this table to focus mitigation effort on the tactics that are most relevant for your threat model.
Attack Vector Categories
API and Control Plane Attacks
- Compromised API Server — Exploiting exposed API endpoints.
- Exposed Dashboard — Unauthorized access to Kubernetes dashboards.
- Unrestricted etcd Access — Accessing etcd storage to retrieve secrets and cluster configurations.
- Kubelet Anonymous Authentication Abuse — Exploiting unauthenticated kubelet API access to execute commands and steal credentials.
Container and Runtime Attacks
- Privileged Container Escape — Breaking out of containers to gain host access.
- Unrestricted HostPath Mounts — Mounting host filesystem for full node compromise.
- Compromised Sidecars — Injecting or abusing sidecars to intercept data.
- Ephemeral Debug Container Abuse — Exploiting
kubectl debugto inject containers and access process namespaces. - Container Image Supplemental Group Injection — Injecting unauthorized group IDs via
/etc/groupin container images to bypass policy controls.
Identity and Access Attacks
- Insecure RBAC Permissions — Exploiting misconfigured Role-Based Access Control.
- Privileged Service Accounts — Overprivileged service accounts enabling escalation.
- Service Account Token Abuse — Exploiting service account tokens for privilege escalation.
- Exec/Attach Credential Theft — Using
kubectl execto extract credentials.
Network Attacks
- Lack of Network Policies — Lateral movement within the cluster.
- Ingress/Egress Traffic Hijacking — Manipulating network traffic flow.
- Exposed Kubelet API — Unauthorized access to kubelet APIs.
Secrets and Data Attacks
- Insecure Secrets Management — Leaking secrets due to weak storage.
- ImagePullSecrets Theft — Extracting container registry credentials.
- Persistent Volume Data Exposure — Accessing sensitive data from orphaned or shared PersistentVolumes.
Supply Chain Attacks
- Supply Chain Attacks — Injecting malicious code into images or CI/CD pipelines.
- Exploiting Insecure CSI Drivers — Abusing storage drivers to access volumes.
Cloud Infrastructure Attacks
- Cloud Metadata Service Abuse — Stealing cloud IAM credentials via IMDS from pods.
Policy and Configuration Attacks
- Misconfigured Admission Controllers — Bypassing security policies via webhook exploitation.
- Denial of Service (DoS) Attacks — Exhausting cluster resources.
Each article provides step-by-step exploitation techniques, real-world risks, and a link to the corresponding mitigation guide to help you harden your Kubernetes environments.
Risk Profile by Category
Different attack categories vary in attacker preconditions, blast radius, and detectability. Use this table to prioritise hardening effort.
| Category | Attacker Precondition | Blast Radius | Detection Difficulty | Primary Mitigation |
|---|---|---|---|---|
| Privileged Container Escape | Pod create with privileged: true or hostPath | Node root, then any pod on the node | Hard without runtime tooling | Pod Security Admission (restricted) + seccomp |
| Service Account Token Abuse | Pod compromise + reachable API server | Whatever the SA can do — often cluster-wide | Audit logs only | Disable automountServiceAccountToken, scope RBAC |
| Lack of Network Policies | Pod compromise in the same cluster | Every pod the policy would have blocked | Easy with NetworkPolicy logging or eBPF | Default-deny NetworkPolicy per namespace |
| Compromised API Server | Network reach + missing TLS/authn | Cluster admin | Easy with audit logs | Restrict --anonymous-auth=false, mTLS, OIDC |
| Supply Chain Attacks | Tampered image or chart accepted by registry | Cluster admin at first deploy | Hard — looks like normal traffic | Image signing (Cosign), admission verification |
| Cloud Metadata Service Abuse | Pod egress to 169.254.169.254 | Cloud account scoped to that IAM role | Hard at the cluster layer; visible at the cloud layer | Block IMDS via NetworkPolicy or IRSA / Workload Identity |
| Insecure Secrets Management | Pod compromise or etcd read | All Secrets accessible to that scope | Hard — Secrets reads are not audited by default | KMS v2 encryption at rest, external secret stores |
Try It: Live YAML Security Analyzer
Many of the attacks above start with a workload that should never have been admitted in the first place. Paste a Kubernetes manifest below to see whether it ships any of the high-risk patterns this section catalogues — privileged containers, host mounts, missing NetworkPolicy targeting, automounted SA tokens.
Version-Specific Notes (Kubernetes 1.36)
Several controls relevant to attack-vector mitigation have stabilised in recent Kubernetes versions:
- Pod Security Admission — GA since 1.25. The
restrictedprofile blocks the workload patterns behind privileged-escape, hostPath, and supplemental-group-injection vectors. - Anonymous authentication restriction — Beta in 1.31, GA in 1.33. The
--anonymous-auth-configflag lets the API server accept anonymous requests only on specific endpoints (such as/healthz), eliminating the historic "anonymous can hit any path" exposure. - Bound ServiceAccount tokens — Default behaviour. Tokens are projected with audience and expiration, so the long-lived tokens that powered classic SA-token-abuse paths are no longer the default.
- User namespaces (
hostUsers: false) — GA in 1.33. Reduces the impact of container-escape vectors by mapping in-pod root to an unprivileged UID on the host.
Removed APIs that previously enabled common attacks:
- PodSecurityPolicy — Removed in 1.25. Clusters that still rely on PSP are unprotected; migrate to PSA or a policy engine (Kyverno, Gatekeeper).
extensions/v1beta1Ingress — Removed in 1.22. Usenetworking.k8s.io/v1, which supports modern path-type semantics and TLS configuration.
Always check the Kubernetes deprecation guide before upgrading; security-relevant fields move through alpha/beta gates that are tied to feature-gate flags on the API server.
Defensive Principles for Threat Modelling
These principles apply when reasoning about every category above.
Assume Breach
Design controls so that a single compromised pod cannot reach cluster admin. NetworkPolicy, RBAC scoping, and automountServiceAccountToken: false are the three controls that most often interrupt the escalation chain.
Map Privilege to Blast Radius
Before granting a permission, ask "what does compromise of this identity allow?". A ClusterRole with secrets/get cluster-wide is a single SSRF away from leaking every Secret in the cluster.
Detect at Runtime
Static admission catches known-bad manifests; runtime detection catches the unknown. Pair Pod Security Admission with Falco or Tetragon for behaviours that bypass policy.
Verify Provenance
Treat every image and chart as untrusted until proven otherwise. Image signing (Cosign, Notation) plus admission-time verification is the only durable answer to supply-chain attacks.
Security Warning
The information and scripts in this section are intended for educational and security research purposes only. They demonstrate how attackers exploit misconfigurations and vulnerabilities in Kubernetes clusters.
Do not run these techniques on production systems or unauthorized environments.
Use this content only in controlled, isolated testing environments where you have explicit permission. Misuse may violate company policies or legal regulations.
You are responsible for how you use this information.
Conclusion
The categories on this page cover the techniques that compromise real Kubernetes clusters. Pair each linked article with its corresponding best practice to close the gap between threat and mitigation, and use the YAML analyzer above to validate manifests before they reach production.