Kubernetes Security Architecture and Attack Surface

Before you tune RBAC rules or Pod Security labels, it helps to see where Kubernetes can actually be attacked. Security here is layered: a weakness in your build pipeline, an exposed kubelet port, or a privileged Pod can bypass controls you trusted at the API boundary. This guide maps those layers for CKS study — trust boundaries first, realistic attack paths second, and where preventive, detective, and response controls belong without turning the page into a configuration checklist.

Why Kubernetes security is layered

Kubernetes security is not a single switch. It spans everything that can change what runs in the cluster or what a workload can reach:

• Source repositories and build systems
• Container registries and image promotion
• The Kubernetes API and admission chain
• Control-plane components and etcd
• Worker nodes, kubelet, and the container runtime
• Pod specifications and running workloads
• Cluster networking, Services, and Ingress
• Secrets, ConfigMaps, and persistent storage
• Runtime activity on nodes and inside containers
• Operational detection and incident response

The flow below shows how those areas connect in a typical delivery path. A gap at any stage can undermine controls elsewhere — signed images do not help if a CI identity can push to production, and strict RBAC does not stop a privileged Pod from reading the host filesystem.

Source Code
    ↓
Build
    ↓
Registry
    ↓
Admission
    ↓
Scheduler
    ↓
Node
    ↓
Runtime
    ↓
Workload
    ↓
Network & Data

When you prioritize hardening, ask which box in that chain an attacker would target first for your environment.

Define the main trust boundaries

Trust boundaries are the gates where identity, policy, or isolation should change. In Kubernetes they stack from the outside in:

Each horizontal band is a place to ask who is allowed to cross and with what proof:

The API server sits in the center of administration, but it is not the only path to privileged effect. These examples cross different boundaries:

• SSH access on a worker node
• A Pod with hostPath to /var/run
• A CI job that can edit Deployments in kube-system

Map controls to the boundary they actually guard.

For how authenticated requests reach persistence, see authentication, authorization, and admission control in the related guide above. For certificate trust inside the control plane, see Kubernetes PKI and certificates.

Control-plane attack surface

The control plane holds cluster desired state. Attackers who influence it can change what runs everywhere.

Common exposure points include:

• A publicly reachable or broadly routed API endpoint
• Weak or leaked client certificates, tokens, or kubeconfig files
• Excessive RBAC — cluster-admin bindings, wildcard rules, or Secrets read for every namespace
• Unsafe authorization modes or misconfigured webhook authorization
• Admission bypass, disabled plugins, or policies that never enforce on the namespaces that matter
• Compromised or overprivileged operators, controllers, and admission webhooks with broad RBAC or access to sensitive resources
• Exposed etcd without TLS or with weak peer and client authentication
• Editable static Pod manifests on control-plane nodes
• Overly long-lived, reused, or broadly trusted PKI material, and bootstrap tokens left active
• Unprotected audit logs or configuration files on disk that reveal credentials

Hardening work belongs in focused guides:

• Restrict who can reach the API
• Enforce least-privilege RBAC
• Rotate and scope certificates
• Protect etcd backups
• Ensure admission runs on every write path you care about

Audit policy and API-server flags are part of the CKS Monitoring, Logging and Runtime Security domain — this page only names the surface so you know what to look for during a review.

Worker-node attack surface

Worker nodes execute workloads and often hold the secrets of everything scheduled there. Node compromise is a common pivot because one host can expose many Pods.

Remote ssh command access, serial consoles, and broad shell logins are common entry points before an attacker reaches the kubelet or runtime socket.

Watch for:

• SSH, serial console, or broad administrative access to nodes
• Kubelet HTTPS endpoints with anonymous auth or weak webhook authorization
• Container runtime sockets accessible to unauthorized users or mounted into Pods (containerd, Docker, or CRI-O)
• CNI and CSI node plugins running with excessive host privileges
• hostPath, hostPID, hostNetwork, and mount propagation into the host filesystem
• Cloud instance metadata services reachable from Pods (169.254.169.254 and equivalents)
• Unpatched kernel, container runtime, or Kubernetes node packages
• Node bootstrap credentials, service account token files, and long-lived certificates on disk

A single compromised node may leak every Secret volume, projected token, and registry credential used by Pods on that host. That is why node hardening, kubelet configuration, and workload isolation are separate exam domains — fixing RBAC alone does not remove the blast radius of root on a worker.

Workload attack surface

Workloads are the objects attackers most often reach first — through a vulnerable app, a leaked Service, or a supply-chain image. Risk concentrates in the Pod spec and the identity attached to it. Privileged container settings are a common escalation path; see privileged Pod examples for how those fields map to host access.

• Privileged containers and allowPrivilegeEscalation: true
• Shared host namespaces — PID, network, or IPC
• Added Linux capabilities beyond what the app needs
• Writable root filesystems when read-only would suffice
• Processes running as root inside the container
• Unsafe volume mounts exposing /, /var/run, or cloud credential paths
• Overprivileged ServiceAccounts with automounted tokens
• Missing NetworkPolicy — default allow-all east-west traffic
• Unconfined seccomp or missing AppArmor profiles
• Vulnerable application dependencies and outdated base images

Implementation detail lives in SecurityContext examples (linked above), Linux capabilities, Pod Security Standards (CKS domain material), and image hygiene guides. Here the takeaway is simpler: the Pod spec is a privilege grant on real kernel resources — treat every field as part of the threat model.

Supply-chain attack surface

Most clusters trust whatever image reference a manifest names. Supply-chain attacks target that trust before the Pod ever schedules.

The arrows mark custody changes — each hop is a chance to substitute code or metadata:

Threat patterns to track:

• Compromised source or CI identity
• Malicious dependencies
• Unverified release binaries
• Vulnerable base images
• Mutable tags
• Missing SBOM inventory
• Unsigned artifacts
• Unauthorized promotion between staging and production

Release verification for binaries, images, and SBOMs is covered in verify Kubernetes release artifacts.

The CKS Supply Chain Security section connects scanning, signing, and admission without repeating those tool walkthroughs here.

For image mechanics outside security, see Kubernetes container images.

Network and data attack surface

Networking and data stores extend the attack surface beyond the API. Even well-authenticated administrators can leave workloads exposed to each other or to the Internet.

Areas to review:

• Unrestricted Pod-to-Pod traffic inside the cluster
• Plaintext application protocols on Services or Ingress
• LoadBalancer or NodePort Services exposed without need
• Exposed kubelet, etcd, or cloud metadata endpoints reachable from Pods
• Secrets readable through RBAC, mounted env vars, or etcd backups
• Unencrypted PersistentVolumes or snapshots copied to less trusted environments
• Shared volumes between trust levels — staging data on production nodes
• DNS manipulation or permissive egress to arbitrary domains
• Service mesh or CNI misconfiguration that disables encryption or policy

Encryption in transit, Ingress TLS, and NetworkPolicy implementation stay in networking and hardening articles. From an architecture view, treat network and data as boundaries equal to the API: an app exploit that never calls kubectl can still exfiltrate a database if policy allows it.

Common Kubernetes attack paths

Attack paths chain weaknesses across boundaries. The diagram below shows four patterns that appear often in reviews and incident summaries — not exhaustive, but useful for tabletop exercises.

Compromised application Pod

• An RCE in the application gives an attacker code execution inside the container
• The compromised process reads the mounted ServiceAccount token
• It calls the API with permissions granted to that identity, lists Secrets, and moves laterally to other namespaces

ServiceAccount credentials are mounted into Pods by default unless automounting is disabled.

The break often starts at the workload boundary but succeeds because RBAC granted list secrets or create pods too broadly.

Privileged workload escape

• An identity that can create Pods, or a weak admission configuration, may create a Pod that mounts the host container-runtime socket through hostPath
• Access to that socket can launch new containers or interact with existing containers on the node
• That exposes other workloads and node data without a separate API compromise

Compromised CI pipeline

• Stolen pipeline credentials push a malicious image to a registry the cluster already trusts
• The attacker reuses a familiar tag
• A later rollout or image pull can run the malicious digest
• No API vulnerability is required — the cluster faithfully runs what CI authorized

Kubelet exposure

• Direct access to a poorly protected kubelet HTTPS endpoint, or API credentials with nodes/proxy permission, can expose sensitive kubelet APIs
• Those APIs include logs and command execution in running containers
• The kubelet also provides the streaming path used for port forwarding

This is why node metadata and kubelet security sits in the CKS Cluster Setup domain alongside authentication, authorization, and metadata protection.

Detection for these paths combines audit logs, runtime rules, and image integrity checks — preventive RBAC alone will not catch a CI substitution in time without detective controls.

Shared responsibility model

Kubernetes security is shared by several parties. Blurred ownership is itself a risk — teams assume someone else patched the node or pinned the image.

On managed Kubernetes, the provider operates the control plane, but you still own:

• Tenant RBAC
• Workload manifests
• Network policy
• Secrets handling
• Node access for worker pools you manage

Managed control plane does not mean managed application security.

Map controls to security outcomes

Controls fit into phases. Preventive measures reduce likelihood; detective measures reduce dwell time; response and recovery limit impact.

Preventive controls are necessary but not sufficient:

• A blocked kubectl path does not stop a CI push
• A perfect NetworkPolicy does not fix a stolen kubeconfig

Pair each boundary in the trust diagram with at least one detective signal and a response action your team has practiced.

Build a CKS learning map

The CKS tutorial organizes hands-on lessons by exam domain. Use the attack surfaces above as a reading order — match each domain to the part of the cluster you are hardening. Baseline node and control-plane checks start with the CIS benchmark and kube-bench walkthrough in Cluster Setup.

Start with this orientation, then open the domain that matches the boundary you are reviewing. Shared articles such as RBAC and Secrets (linked above) serve CKA and CKAD too — on the CKS path, read them with least-privilege and exposure in mind.

What's Next

• Kubernetes NetworkPolicy with Examples
• Audit Kubernetes Against the CIS Benchmark with kube-bench
• Kubernetes Ingress Rules with Host, Path and TLS Examples

References

• Kubernetes security overview — upstream security documentation
• Kubernetes API server bypass risks — runtime socket and nodes/proxy risks
• Kubelet authentication and authorization — kubelet endpoint access controls
• Verify signed Kubernetes artifacts — binary, image, and SBOM verification
• Pod Security Standards — built-in workload policy levels
• RBAC good practices — authorization design guidance
• Secrets good practices — Secret handling recommendations
• CNCF Certified Kubernetes Security Specialist curriculum — official CKS competency outline

Summary

Kubernetes security architecture is a stack of trust boundaries, not a single hardening guide. Source, build, registry, admission, the API server, nodes, runtimes, workloads, networks, and data each introduce paths an attacker can chain. The API server is central to administration, but node access, privileged Pods, CI identities, and plaintext Services can bypass API-focused controls if you treat them as afterthoughts.

The attack paths that show up most often in practice — stolen ServiceAccount tokens with excessive RBAC, privileged escapes to the runtime socket, malicious images promoted through CI, and exposed kubelet interfaces — all cross more than one layer. That is why the CKS exam spreads weight across setup, hardening, system confinement, microservice risk, supply chain, and runtime detection instead of collapsing everything into one checklist.

Map each boundary to preventive, detective, and response controls your team actually operates. Use the CKS tutorial domains as the hands-on map from this orientation to implementation — Cluster Setup and Hardening for access, System Hardening and workload articles for isolation, Supply Chain Security for image trust, and Monitoring for audit and incident response. When you review a cluster, walk the trust diagram top to bottom and ask what would fail first in your environment, then open the matching lesson rather than tuning random YAML.