KCSA — Common Attack Vectors

10 minute read

What Is an Attack Vector?

An attack vector is a specific method or pathway that an attacker uses to exploit a vulnerability and gain unauthorized access to a system. While the attack surface defines where attacks can occur, attack vectors describe how they are carried out.

This section covers the most common attack vectors in Kubernetes environments — the techniques that appear repeatedly in real-world incidents and on the KCSA exam.

The KCSA exam tests your ability to recognize attack vectors from scenario descriptions and map them to the correct mitigation. Focus on understanding the patterns, not memorizing exploit commands.

Container Escape Techniques

A container escape occurs when a process inside a container breaks out of its isolation and gains access to the host system. This is one of the most severe attack vectors because it bypasses the fundamental security boundary of containerization.

Privileged Containers

Running a container with privileged: true disables nearly all container isolation:

# DANGEROUS: Gives the container almost full host access
securityContext:
  privileged: true

What privileged mode grants:

  • Access to all host devices (/dev)
  • Ability to mount host filesystems
  • Access to host network interfaces
  • Capability to load kernel modules
  • Ability to modify kernel parameters

A privileged container is not a container — it is essentially a process running directly on the host with almost no restrictions.

hostPath Volume Mounts

Mounting host directories into a container can allow file access to the entire host filesystem:

# DANGEROUS: Access to the entire host filesystem
volumes:
  - name: host-root
    hostPath:
      path: /

An attacker with access to a pod mounting the host root filesystem can:

  • Read /etc/shadow to obtain password hashes
  • Write to /etc/crontab to establish persistence
  • Read kubelet credentials from /var/lib/kubelet/
  • Access other pods’ data through container runtime directories

/proc Exploitation

The /proc filesystem provides an interface to kernel internals. In a misconfigured container:

  • /proc/sysrq-trigger — Can trigger kernel actions (reboot, crash dump)
  • /proc/1/root — With hostPID: true, provides access to the host’s root filesystem through PID 1
  • /proc/kcore — Exposes physical memory contents
# DANGEROUS: Shares the host PID namespace with the container
hostPID: true

Kernel Vulnerabilities

Container isolation relies on the Linux kernel. Kernel exploits can bypass all container security:

  • Dirty COW (CVE-2016-5195) — Race condition allowing write to read-only memory mappings
  • Dirty Pipe (CVE-2022-0847) — Overwrites data in arbitrary read-only files
  • runc vulnerability (CVE-2019-5736) — Allowed container escape through the container runtime

Kernel vulnerabilities are why node OS patching is critical. Even perfect container configuration cannot protect against a kernel exploit.

Privilege Escalation Paths

Privilege escalation is the process of gaining higher permissions than originally granted. In Kubernetes, this typically follows a path from a compromised pod to cluster-admin level access.

ServiceAccount Token → RBAC → cluster-admin

This is the most common privilege escalation path:

  1. Compromise a pod — Through a vulnerable application
  2. Read the ServiceAccount token — Mounted at /var/run/secrets/kubernetes.io/serviceaccount/token
  3. Enumerate permissions — Use kubectl auth can-i --list with the token
  4. Find overpermissive roles — ServiceAccount may have wildcard permissions or ability to create RoleBindings
  5. Escalate to cluster-admin — Create a ClusterRoleBinding granting cluster-admin to the ServiceAccount
# Inside a compromised pod — reading the service account token
TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)

# Checking what the token can do
kubectl auth can-i --list --token=$TOKEN

# If the SA can create clusterrolebindings, game over:
kubectl create clusterrolebinding pwned \
  --clusterrole=cluster-admin \
  --serviceaccount=default:compromised-sa

Pod Creation → Privileged Pod → Node Access

If a ServiceAccount can create pods, an attacker can create a privileged pod:

  1. Create a pod with privileged: true and hostPID: true
  2. Mount the host filesystem via hostPath
  3. Use nsenter to enter the host namespace
  4. Gain full root access on the node

This is why the ability to create pods is considered a powerful permission — it can be escalated to full node access.

Escalation via Impersonation

Kubernetes supports user impersonation. If a ServiceAccount has impersonate permissions:

# Dangerous RBAC allowing impersonation
rules:
  - apiGroups: [""]
    resources: ["users", "groups", "serviceaccounts"]
    verbs: ["impersonate"]

An attacker can impersonate any user, including system:masters group members, effectively gaining cluster-admin access.

Lateral Movement

Lateral movement is the technique of moving from one compromised component to other components within the cluster.

Pod-to-Pod via Network

By default, Kubernetes has a flat network — every pod can reach every other pod:

  1. Compromise one pod
  2. Scan the cluster network (e.g., 10.244.0.0/16) for other pods
  3. Discover services via DNS queries (*.svc.cluster.local)
  4. Access internal services that have no authentication (e.g., databases, caches)
# Inside a compromised pod — discovering services
nslookup *.default.svc.cluster.local

# Scanning for other pods
for i in $(seq 1 254); do
  ping -c 1 -W 1 10.244.0.$i 2>/dev/null && echo "Host 10.244.0.$i is UP"
done

Pod-to-Node via Kubelet

If the kubelet API (port 10250) allows anonymous access:

  1. From a compromised pod, reach the node’s kubelet API
  2. List all pods on that node
  3. Execute commands in other pods on the same node
  4. Access pod logs and secrets

Cross-Namespace Movement

Without NetworkPolicies, pods can communicate across namespaces:

  1. Compromise a pod in namespace dev
  2. Reach services in namespace production
  3. Access databases, internal APIs, or secret-containing pods in production

This is a critical point: namespaces without NetworkPolicies provide zero network isolation.

Node-to-Node via Stolen Credentials

Once an attacker has node-level access:

  1. Read kubelet credentials from the node
  2. Access the API server with node-level permissions
  3. Use node permissions to read Secrets for pods scheduled on that node
  4. Pivot to other nodes or escalate to control plane

Credential Theft

Stealing credentials is often the first step in privilege escalation and lateral movement.

ServiceAccount Token Theft

Every pod has a ServiceAccount token mounted by default:

/var/run/secrets/kubernetes.io/serviceaccount/
├── token        # JWT token for API server authentication
├── ca.crt       # Cluster CA certificate
└── namespace    # Current namespace name

Mitigation: Use automountServiceAccountToken: false for pods that don’t need API access. Use projected service account tokens (short-lived, audience-bound).

Secrets in Environment Variables

Secrets injected as environment variables are visible in:

  • /proc/<pid>/environ for any process in the container
  • Container runtime inspection (crictl inspect)
  • Application crash dumps and logs
# Visible via /proc — prefer volume mounts instead
env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-creds
        key: password

Prefer mounting Secrets as files rather than environment variables. File-mounted Secrets are less likely to leak through logs, crash dumps, or /proc.

Kubeconfig Files

Kubeconfig files may be found on:

  • Developer workstations
  • CI/CD pipelines
  • Jump hosts / bastion servers
  • Inside containers if misconfigured

A leaked kubeconfig with cluster-admin access gives full control over the cluster.

Cloud Metadata Attack (IMDS)

This is one of the most important attack vectors for KCSA — the Instance Metadata Service (IMDS) attack.

How It Works

Cloud providers (AWS, GCP, Azure) provide a metadata endpoint at 169.254.169.254 that returns information about the running instance, including IAM credentials.

  1. Attacker compromises a pod
  2. Pod sends HTTP request to http://169.254.169.254/latest/meta-data/
  3. Metadata endpoint returns instance profile credentials
  4. Attacker uses cloud credentials to access cloud resources (S3, databases, other services)
# From inside a compromised pod on AWS
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

# This returns temporary AWS credentials:
# AccessKeyId, SecretAccessKey, Token

The cloud metadata endpoint is the number one method attackers use to escalate from a Kubernetes pod to cloud infrastructure access.

Mitigations

Cloud Provider Mitigation
AWS Use IMDSv2 (requires token), use IRSA (IAM Roles for Service Accounts)
GCP Use Workload Identity, block metadata via NetworkPolicy
Azure Use Azure AD Workload Identity, restrict IMDS access
All Apply NetworkPolicy blocking egress to 169.254.169.254 
# NetworkPolicy blocking IMDS access
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cloud-metadata
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
              - 169.254.169.254/32

Cryptojacking

Cryptojacking is deploying cryptocurrency mining software in compromised pods. It is the most common outcome of Kubernetes compromises because:

  • It directly generates revenue for attackers
  • It is easy to deploy (just run a container image)
  • It can run undetected for extended periods
  • The attacker doesn’t need to exfiltrate data

Attack Flow

  1. Gain access via exposed dashboard, service, or vulnerable app
  2. Deploy a mining container (e.g., XMRig for Monero)
  3. Configure the miner to connect to a mining pool (sometimes a private pool to evade detection)
  4. Consume as many node resources as possible

Detection

  • Unexplained CPU spikes across nodes
  • Unknown pod images or containers
  • Connections to known mining pool domains/IPs
  • Resource usage exceeding defined limits

Denial of Service (DoS) Attacks

DoS attacks aim to make Kubernetes services or the cluster itself unavailable.

Resource Exhaustion

  • Fork bombs — Processes that recursively spawn children until the node runs out of PIDs
  • Memory bombs — Allocating memory until the node OOM kills processes
  • Disk filling — Writing to emptyDir volumes until node disk is full

Pod Flooding

  • Creating large numbers of pods to exhaust scheduler or node resources
  • Deploying pods with extreme resource requests to prevent other pods from scheduling

API Server Flooding

  • Sending excessive API requests to degrade control plane performance
  • Expensive list operations on large clusters (e.g., listing all pods with no pagination)

Mitigation: Use LimitRange and ResourceQuota to cap resource usage per namespace. Set API Priority and Fairness to protect the API server.

Attack Kill Chain in Kubernetes

Understanding the full attack lifecycle helps you identify where security controls should be placed.

Stage Description Kubernetes Example
1. Initial Access Gaining a foothold in the cluster Exploiting a vulnerable web app, using stolen kubeconfig
2. Execution Running attacker code kubectl exec, deploying a malicious pod
3. Persistence Maintaining access after reboot/restart CronJob backdoor, mutating webhook
4. Privilege Escalation Gaining higher privileges SA token → RBAC escalation, privileged pod
5. Defense Evasion Hiding from detection Running in kube-system, deleting events/logs
6. Credential Access Stealing credentials Listing Secrets, reading IMDS
7. Discovery Understanding the environment Listing pods, services, namespaces, RBAC
8. Lateral Movement Moving to other pods/nodes Flat network exploitation, kubelet API
9. Collection Gathering target data Accessing databases, reading volumes
10. Exfiltration Moving data out DNS tunneling, uploading to external storage
11. Impact Achieving the attacker’s goal Cryptojacking, data destruction, ransom 
Initial Access → Execution → Persistence → Privilege Escalation
     ↓                                            ↓
Defense Evasion ← Credential Access ← Discovery ← Lateral Movement
                                                       ↓
                                    Collection → Exfiltration → Impact

Real-World Attack Scenario Walkthrough

Here is a realistic end-to-end attack scenario that combines multiple vectors:

Scenario: E-Commerce Cluster Compromise

Step 1 — Initial Access: Attacker discovers a publicly exposed web application with an SQL injection vulnerability in a pod running in the frontend namespace.

Step 2 — Execution: Attacker exploits SQL injection to gain remote code execution inside the frontend pod.

Step 3 — Credential Access: Attacker reads the ServiceAccount token at /var/run/secrets/kubernetes.io/serviceaccount/token.

Step 4 — Discovery: Using the token, attacker queries the API server:

  • Lists all namespaces
  • Lists all pods in backend namespace
  • Lists Secrets in backend namespace (SA has overly permissive RBAC)

Step 5 — Lateral Movement: No NetworkPolicies exist. Attacker’s pod directly connects to the database pod in the backend namespace on port 5432.

Step 6 — Credential Theft (Cloud): Attacker queries 169.254.169.254 from the compromised pod and obtains AWS IAM credentials with S3 access.

Step 7 — Exfiltration: Using the AWS credentials, attacker downloads customer data from S3 buckets.

Step 8 — Persistence: Attacker creates a CronJob that runs a reverse shell every hour, maintaining access even if the original pod is restarted.

What Could Have Prevented This?

Control What It Would Have Stopped
Input validation / WAF Step 1 — Initial access via SQLi
automountServiceAccountToken: false Step 3 — Token not available
Least-privilege RBAC Step 4 — Cannot list backend Secrets
Default-deny NetworkPolicy Step 5 — Cannot reach backend pods
Block IMDS + Workload Identity Step 6 — Cannot reach metadata endpoint
Pod Security Standards (Restricted) Step 8 — Cannot create privileged CronJob
Audit logging + alerting Multiple steps — Detection at each stage

Key Takeaways for the Exam

Attack Vector What to Remember
Container escape Privileged mode, hostPath, /proc, kernel exploits
Privilege escalation SA token → RBAC → cluster-admin; pod creation is a powerful permission
Lateral movement Flat network by default; namespaces ≠ network isolation
Credential theft SA tokens mounted by default; Secrets in env vars leak via /proc
Cloud metadata (IMDS) 169.254.169.254 returns cloud credentials; block with NetworkPolicy
Cryptojacking Most common outcome of k8s compromise
DoS Fork bombs, resource exhaustion; mitigate with LimitRange/ResourceQuota
Kill chain Initial access → execution → persistence → escalation → movement → exfil
  • Know the kill chain stages — exam may ask “What stage of the attack is this?”
  • Understand that defense-in-depth means placing controls at every stage
  • The cloud metadata attack is a favorite exam topic — know the IP, the risk, and the mitigations

Next: Kubernetes-Specific Threats →

Updated:

You may also enjoy