KCSA — Kubernetes Attack Surface

7 minute read

What Is an Attack Surface?

An attack surface is the sum of all points where an attacker can try to enter or extract data from a system. In Kubernetes, the attack surface is large because the platform consists of many interconnected components communicating over the network.

Understanding the attack surface is essential for the KCSA exam. You need to know which components are exposed, what they expose, and how attackers target them.

The larger the attack surface, the more opportunities an attacker has. Reducing the attack surface is a core security principle.

Control Plane Attack Surface

The control plane is the brain of Kubernetes. Compromising any control plane component can lead to full cluster takeover.

API Server (kube-apiserver)

The API server is the most critical component — it is the frontend for all Kubernetes operations.

Attack vectors:

  • Publicly exposed API server — If the API server is reachable from the internet without proper authentication, attackers can enumerate and manipulate cluster resources
  • Anonymous authentication enabled — Allows unauthenticated requests, potentially exposing cluster information
  • Weak or missing RBAC — Overly permissive roles allow unauthorized operations
  • Token theft — Stolen ServiceAccount tokens grant API access
  • API server DoS — Flooding the API server with requests can degrade cluster operations

Default ports:

Port Protocol Purpose
6443 HTTPS Secure API endpoint (default)
8080 HTTP Insecure API endpoint (deprecated, should be disabled)

Never expose the API server’s insecure port (8080). It bypasses all authentication and authorization. Modern Kubernetes versions disable it by default, but legacy clusters may still have it enabled.

etcd

etcd stores the entire cluster state — including Secrets, RBAC policies, pod specifications, and ConfigMaps.

Attack vectors:

  • Direct etcd access — If an attacker can reach etcd directly, they can read/modify everything in the cluster
  • No TLS — Communication between API server and etcd without encryption allows traffic interception
  • No client certificate authentication — Allows unauthorized clients to connect
  • Backup theft — etcd backups contain all cluster data including Secrets

Direct access to etcd is equivalent to full cluster compromise. There is no authorization layer in etcd — if you can connect, you can read and write everything.

Default ports:

Port Purpose
2379 Client communication
2380 Peer communication (etcd cluster)

Scheduler (kube-scheduler)

Attack vectors:

  • Scheduler API exposed — Port 10259 (secure) or 10251 (insecure, deprecated)
  • Scheduling policy manipulation — An attacker who can modify scheduling policy can force workloads onto specific nodes
  • Resource starvation — Preventing legitimate pods from being scheduled

Controller Manager (kube-controller-manager)

Attack vectors:

  • Controller Manager API exposed — Port 10257 (secure) or 10252 (insecure, deprecated)
  • Service account token generation — The controller manager creates SA tokens; compromising it means forging tokens
  • Cloud provider credentials — Controller manager often has cloud provider credentials for dynamic provisioning

Data Plane (Worker Node) Attack Surface

Worker nodes run your actual workloads. They present a significant attack surface because they are closer to application code and data.

Kubelet

The kubelet runs on every worker node and manages pod lifecycle.

Attack vectors:

  • Kubelet API (port 10250) — If anonymous authentication is enabled, anyone who can reach port 10250 can list pods, execute commands inside containers, and read logs
  • Read-only kubelet API (port 10255) — Exposes pod information without authentication (deprecated but may still be open)
  • Host filesystem access — Kubelet has access to the node filesystem
# Dangerous: kubelet with anonymous auth enabled
# /var/lib/kubelet/config.yaml
authentication:
  anonymous:
    enabled: true  # NEVER enable this in production

Port 10250 with anonymous auth enabled is one of the most common Kubernetes misconfigurations found in the wild. Always verify this is disabled.

Container Runtime

The container runtime (containerd, CRI-O) executes containers on the node.

Attack vectors:

  • Docker socket mounting — Mounting /var/run/docker.sock into a container gives that container full control over the Docker daemon, effectively giving it root on the host
  • Container escape — Exploiting runtime vulnerabilities to break out of the container isolation
  • Privileged containers — Containers running with privileged: true have almost no isolation from the host
# DANGEROUS: Mounting Docker socket
volumes:
  - name: docker-sock
    hostPath:
      path: /var/run/docker.sock

Pod-to-Pod Network

  • No default network isolation — By default, all pods can communicate with all other pods across all namespaces
  • Service discovery enumeration — Attackers can discover services via DNS (<service>.<namespace>.svc.cluster.local)
  • Traffic sniffing — Without encryption (mTLS), pod-to-pod traffic can be intercepted on the overlay network

Supply Chain Attack Surface

The software supply chain introduces threats before workloads even run in the cluster.

Container Images

  • Malicious base images — Using unverified base images from public registries
  • Outdated images — Images with known CVEs that have not been patched
  • Image tampering — Images modified between build and deployment (no signature verification)
  • Typosquatting — Pulling ngimx instead of nginx from a public registry

Container Registries

  • Unauthenticated registries — Allowing anonymous pull/push operations
  • Registry compromise — An attacker who compromises the registry can replace images
  • No content trust — Pulling images without verifying their signatures

CI/CD Pipeline

  • Pipeline compromise — Injecting malicious steps into build pipelines
  • Secret leakage — Build pipelines often have access to cluster credentials
  • Dependency confusion — Pulling internal packages from public repositories

External-Facing Attack Surface

Services exposed to external traffic are the most obvious attack surface.

Ingress Controllers

  • Process all incoming HTTP/HTTPS traffic
  • Vulnerable to application-layer attacks (SQL injection, XSS) targeting backend services
  • Misconfigured TLS termination can expose traffic in plain text

LoadBalancer Services

  • Directly expose services on cloud provider load balancers
  • Each LoadBalancer service gets a public IP
  • Overly broad exposure widens the attack surface

NodePort Services

  • Open a port on every node in the cluster (range 30000–32767)
  • Any service reachable on node IPs + NodePort
  • Bypasses Ingress rules and network policies at the Ingress level

Avoid using NodePort in production. Prefer Ingress controllers or LoadBalancer services with proper security controls. NodePort exposes ports on ALL nodes, not just the ones running the target pods.

Attack Surface Summary Table

Component Attack Surface Severity Key Mitigation
API Server Public exposure, weak auth, anonymous access Critical Private endpoint, OIDC auth, RBAC, audit logging
etcd Direct access, no TLS, backup theft Critical Restrict network access, enable TLS, encrypt at rest
Kubelet Port 10250 anonymous auth, read-only port High Disable anonymous auth, close port 10255
Container Runtime Docker socket mount, privileged containers High Block socket mounts, deny privileged via PSS
Pod Network Flat network, no encryption High Default-deny NetworkPolicy, service mesh mTLS
Scheduler Exposed API, policy manipulation Medium Bind to localhost, secure port only
Controller Manager Exposed API, cloud credentials Medium Bind to localhost, rotate credentials
Container Images Malicious images, outdated CVEs High Image scanning, signing, admission control
Ingress Application-layer attacks Medium WAF, rate limiting, TLS
NodePort Port exposure on all nodes Medium Avoid NodePort, use Ingress instead

Real-World Breach Examples

Tesla Cryptojacking (2018)

  • Attackers found an unauthenticated Kubernetes Dashboard exposed to the internet
  • Through the dashboard, they deployed cryptocurrency mining pods
  • The mining pods were configured to use a non-standard mining pool to avoid detection
  • Lesson: Never expose the Kubernetes Dashboard without authentication; use network policies to restrict access

Shopify Bug Bounty (2020)

  • A security researcher discovered they could escape their Google Cloud Kubernetes pod
  • The escape allowed access to the cloud metadata service (169.254.169.254)
  • From the metadata, they obtained cloud credentials with broad permissions
  • Lesson: Block IMDS access from pods, use Workload Identity, apply network policies

Capital One Breach (2019)

  • While not purely a Kubernetes issue, it highlighted cloud metadata exploitation
  • A compromised web application firewall (WAF) allowed access to the EC2 metadata endpoint
  • The IMDS endpoint returned IAM credentials that granted access to S3 data
  • Lesson: Use IMDSv2 (requires token), limit pod access to cloud metadata

Reducing the Attack Surface — Checklist

Use this checklist to systematically reduce your Kubernetes attack surface:

Control Plane

  • API server is not publicly accessible (private endpoint or VPN)
  • Anonymous authentication is disabled on the API server
  • Insecure port (8080) is disabled
  • etcd is not directly accessible from worker nodes or external networks
  • etcd uses TLS for all communication
  • etcd data is encrypted at rest
  • Scheduler and Controller Manager bind to localhost only

Worker Nodes

  • Kubelet anonymous authentication is disabled
  • Kubelet read-only port (10255) is closed
  • Docker socket is not mounted into any container
  • No containers run in privileged mode without explicit justification
  • Node OS is hardened and minimal (e.g., Bottlerocket, Talos)

Network

  • Default-deny NetworkPolicy is applied to all namespaces
  • Pod-to-pod traffic uses mTLS (via service mesh) where required
  • NodePort services are minimized or eliminated
  • Ingress controllers have rate limiting and WAF enabled

Supply Chain

  • Images are pulled from trusted, private registries only
  • All images are scanned for CVEs before deployment
  • Image signatures are verified via admission controllers
  • CI/CD pipelines use short-lived, scoped credentials

Key Takeaways for the Exam

Concept What to Remember
API Server Most critical component; secure with auth, RBAC, audit, private endpoint
etcd Direct access = full cluster compromise; must use TLS and restrict access
Kubelet Port 10250 with anonymous auth is a top misconfiguration
Docker socket Mounting it into a container = root on the host
Flat network Default k8s has no network isolation; use NetworkPolicy
Supply chain Malicious images, typosquatting, registry compromise are real threats
NodePort Exposes ports on ALL nodes — prefer Ingress
  • Know which ports map to which components (6443, 2379/2380, 10250, 10255)
  • Understand that different components have different severity levels when compromised
  • Real-world examples often appear in KCSA scenario questions — know the patterns, not the details

Next: Common Attack Vectors →

Updated:

You may also enjoy