What is Kubernetes architecture?
Kubernetes architecture is the set of components and communication patterns that orchestrate containerized workloads across a cluster. It splits responsibility between a control plane, which decides what runs and where, and a data plane, where pods execute. Understanding this split matters because each layer has its own attack surface, and a misconfiguration in one can cascade into a full cluster compromise.
Kubernetes Security Best Practices Cheat Sheet
Whether you manage your own nodes or rely on KaaS, securing your Kubernetes environment requires a solid baseline.
Why does security matter in Kubernetes architecture?
Designed to solve real-world container orchestration problems, Kubernetes is an opinionated system optimized more for developer experience and convenience than security. A default Kubernetes cluster prioritizes operability over isolation: Pods can communicate freely without explicit NetworkPolicy rules, Kubernetes stores secrets as unencrypted Base64-encoded values and automatically mounted service account tokens that can grant unintended API access.
These default settings can have consequences: In 2023, nearly 90% of organizations reported at least one Kubernetes security incident. Still, it’s possible to find a balance between ease of use and security. The first step to protecting your clusters? Understanding how the components communicate with each other and where there might be security gaps.
Components of the control plane and their security implications
Kubernetes architecture components break down into two distinct layers: the control plane and the data plane. The control plane manages cluster state by determining which pods run and how traffic flows. The Kubernetes data plane (which we’ll discuss in the next section) is where actual workloads execute. It’s crucial to understand this division because each layer has its own attack surface, and a breach in one can cascade into the other.
Keep in mind that when you run managed Kubernetes (EKS, GKE, AKS), shared responsibility applies. The cloud provider will manage your control plane since they own physical security, the hypervisor, and the platform services. Because you own network policies, pod configurations, RBAC, workload security, and secrets management, securing them falls on you.
Next, let’s look at core components of the control plane in more detail.
The API server
The Kubernetes API server is the central control point. Every kubectl command routes through it. Every deployment, every pod creation, and every configuration change touches it. On top of that, it's the only component that can write to etcd.
At its core, the Kubernetes cluster architecture operates on a hub-and-spoke communication model. The control plane is the hub, issuing commands to worker nodes (the spokes) via API calls. The kubelet on each worker node periodically checks back with the API server to confirm its state and retrieve new workload assignments. This makes the API server a critical chokepoint. Compromise it, and you control everything. Expose it, and attackers probe clusters within minutes.
Many organizations have a vulnerable API server because…
The default
--anonymous-auth=truemaps to thesystem:anonymoususer which can create an escalation risk if RBAC policies are misconfigured.While Kubernetes removed it in v1.20, legacy self-managed clusters remain at high risk from an exposed insecure port (
localhost:8080) that bypasses authentication entirely.An engineer who accidentally exposes the API server to the internet gives attackers unfiltered access to your cluster state.
Protecting your API server
Weak API access is the entry vector for most real breaches. The API server doesn't even question the request (i.e., if credentials validate and RBAC permits it, the action succeeds).
In 2025, Cisco's analysis of VoidLink malware showed how purpose-built threats can detect a Kubernetes cluster environment and pivot toward the control plane. It's a pattern that reinforces why API server hardening can't wait.
ShadowRay 2.0 exploited unpatched Ray clusters to gain code execution on GPU nodes, then pivoted into the surrounding Kubernetes environment. Once inside, attackers repurposed the compute for cryptomining and further propagation. Both examples show why locking down the API server is a prerequisite, not an afterthought.
To protect your API server, implement these foundational measures: Make sure your API server only listens on private IPs, uses strong TLS certs, and requires valid authentication tokens. Also, enable audit logging to catch suspicious activity like rapid role creation or mass secret reads.
etcd
etcd is the primary datastore for all cluster configuration and state data, including pod definitions, service configurations, RBAC rules, and (most importantly) secrets. While read access lets attackers extract configuration details, credentials, and sensitive data about your applications, write access to etcd is equivalent to root access to the entire cluster because, unless encryption at rest is explicitly configured, secrets in etcd are merely Base64-encoded strings.
Protecting etcd
First, enable encryption at rest using a key management system (KMS). This configuration enables the API server to encrypt secrets on write and decrypt them on read.
Also consider:
Restricting network access so only the API server can reach etcd
Using TLS with mutual authentication (client certificates), so both components verify each other's identity
Protecting etcd backups with the same rigor you'd use for production databases
Controllers and scheduler
While controllers and the scheduler aren’t internet-facing, they are essential components for cluster security. The kube-controller-manager runs multiple controllers that watch cluster state and drive it toward your desired state, and the kube-scheduler assigns pods to nodes. Both are responsible for modifying the cluster state continuously. As a result, their permissions must be tightly scoped.
The Pod Security Admission controller is responsible for blocking risky pod configs like privileged containers or pods running as root. You can also pair this controller with policy-as-code tools to enforce your own rules. For example, you can block images from untrusted registries or prevent hostPath mounts to sensitive directories.
Watch 12-min demo
See how Wiz gives you unified visibility across Kubernetes clusters regardless of your KaaS provider.
Kubernetes data plane and networking security
The data plane is where your applications run. It's also where most lateral movement happens after an initial compromise.
The flat network problem with pod-to-pod traffic
Kubernetes defaults to allowing all east–west traffic, so any pod can talk to any other pod on any port. This simplifies development but requires additional controls in production environments. When default settings are in place, an attacker who compromises one pod gains an initial foothold inside your network.
Network policies are your primary defense. Creating a default-deny isolation policy where you drop everything unless it’s explicitly allowed is a good starting point. Combine this with namespace isolation, where you put different applications or teams in different namespaces and apply network policies to ensure each namespace only reaches its intended peers.
Effective namespace isolation requires CNI plugins like Calico, Cilium, and Amazon VPC CNI, which help enforce these policies at the network level. Cilium goes further than the rest, using eBPF to provide deep visibility into protocols like HTTP and gRPC, enabling you to define precise network policies based on how your services actually communicate.
But when your requirements expand beyond simple blocking to include complex traffic routing and observability, you’ll need a service mesh like Istio or Linkerd. Service meshes automatically encrypt all pod-to-pod traffic with mutual TLS, provide application-layer authorization policies, and give you rich observability.
Control plane to worker node traffic
The API server and kubelets communicate over HTTPS with mutual authentication. In modern Kubernetes clusters, kubelets typically obtain client certificates through bootstrap tokens and then rotate those certificates automatically, which reduces long-lived credential risk and helps prevent man-in-the-middle attacks. But even if your transit is encrypted, the underlying container runtime can be a "leaky vessel."
The container runtime remains a critical attack surface. Vulnerabilities such as CVE-2024-21626, which Wiz documented as part of the 'Leaky Vessels' research, and later runc breakout flaws have shown that container escape to the host filesystem is a practical risk when attackers already have code execution inside a workload.
Protecting your environment requires you to place both worker and control plane nodes on private networks. If your cluster is on the cloud, replace public access with firewall rules, VPNs, or private endpoints.
Container image supply chain security
Unlike simple binaries, container images often contain entire operating system userlands and third-party libraries. The downside? A single neglected vulnerability in a base layer can be inherited by your entire fleet, and traditional perimeter defenses will never catch the issue.
To protect your container images, embed security measures like image scanning in your CI/CD pipeline. Image scanning detects CVEs, malware, and embedded secrets before they ever reach production. It also comes in handy when you want to limit your cluster to private image registries and enforce admission policies that explicitly reject any image that hasn't been both scanned and signed.
Common networking mistakes
Exposed API endpoints: Leaving the control plane API open to the entire internet invites credential stuffing and zero-day exploits.
Unrestricted lateral movement: Since Kubernetes networks are flat by default, a compromised frontend web server can be used to probe, scan, and attack sensitive backend databases or internal services in other namespaces.
NodePort exposure: Opening high-range ports (30000–32767) on every node frequently bypasses standard Ingress controllers and cloud load balancers, which can expose internal administrative interfaces or debug tools directly to the public internet.
Clear-text internal traffic: Relying on the perimeter for security often leads to unencrypted HTTP pod-to-pod communication.
Exposing sensitive ports: Leaving critical ports (for example, 10250 for kubelet, 2379 for etcd) reachable from untrusted networks reduces time-to-exploit much more than simply using default port numbers.
Instance metadata exposure: Attackers use server-side request forgery (SSRF) to query the metadata service (e.g., AWS IMDSv1) and steal the node's IAM role credentials. From there, they pivot from a container breach to a full cloud account compromise.
Kubernetes DevSecOps
In this blog post, we’ll discuss the need for DevSecOps in Kubernetes environments. We'll walk through the reasons behind this approach, the unique challenges of orchestrated platforms, and the Kubernetes security layers that matter most.
Leggi di piùWiz's unified approach to securing Kubernetes architecture
Risks ranging from vulnerable API servers to overprivileged RBAC and flat networking become far more dangerous when analyzed in a vacuum. Wiz unifies these signals by mapping every identity, network route, and cluster resource into the Security Graph. By correlating container CVEs with Kubernetes permissions and cloud-layer exposure, the platform identifies the exact toxic combinations that define breach paths. This ensures a critical vulnerability on an internet-facing pod with administrative access is prioritized immediately, while the same flaw in a locked-down, isolated environment is deprioritized to reduce noise.
That context shapes security across the entire development lifecycle. Pre-deployment, Wiz Code scans IaC manifests, Helm charts, and container images to block privileged containers and embedded secrets before they reach the cluster. When those risks surface in production, the graph traces them back to the source commit so developers can remediate at the root via a pull request.
Once workloads are live, agentless KSPM validates control plane hardening: etcd encryption, API server authentication, and worker node configuration drift. At the identity layer, Wiz correlates Kubernetes RBAC with cloud IAM to expose overprivileged service accounts that could pivot from a compromised pod to cloud resources like S3 buckets. Because both layers feed into the Security Graph, the full lateral movement chain is visible in one view.
For real-time protection, Wiz Defend layers a lightweight, eBPF-powered Runtime Sensor on top of the agentless foundation. It detects container escapes, lateral movement, and credential theft as they happen. Vulnerability Runtime Validation (VIR) identifies which vulnerable packages are actively loaded in memory, not just installed, cutting vulnerability backlog by up to 90%.
As AI workloads increasingly run on Kubernetes, Wiz extends the same approach to AI security. Agentless scanning identifies AI frameworks in your clusters, while the Runtime Sensor detects rogue agent behavior like unauthorized credential harvesting. The Security Graph correlates risks across all four layers of an AI application: infrastructure, models, data and access, and code.
See how the Security Graph maps your Kubernetes attack surface from code to runtime. Get a demo.
See Wiz in Action
Protect your containers from build to runtime with complete Kubernetes and cloud visibility.
