This is the second part of our two-blog series, where we explore various initial access vectors into Kubernetes environments, analyze the associated attack angles, and clarify the relevant risks.
Taxonomy
In the first blog, we presented the taxonomy of initial access vectors and discussed control plane access. In this part, we focus on data plane access. We will go through the possible initial access vectors originating from the applications running on the cluster, discuss concerns around container images (their origin and potential escape scenarios), and wrap up with execution-as-a-service workload types.
Applications
Kubernetes clusters are designed to run workloads. Naturally, these workloads perform certain actions by implementing business logic. Every workload can have a critical vulnerability resulting in Remote Code Execution (RCE). For the vulnerability to be exploitable, it must be exposed and reachable by an external user—either directly (e.g., RCE in a frontend pod) or indirectly (e.g., misconfiguration leading to RCE in an SQL database pod, accessed via a frontend pod). Since application security is beyond the scope of this article, we focus here on how to contain the attacker after initial access. In such a scenario, a malicious actor would find themselves in the execution context of a vulnerable pod, as illustrated in this diagram:
From this point, two main vectors are available to attackers: (1) abuse of Kubernetes RBAC privileges associated with this pod’s Service Account (SA) and/or (2) abuse of system privileges within the current container or neighbor pod containers to escape to the host and move laterally. Several security boundaries are designed to prevent these lateral movement and privilege escalation scenarios, such as Kubernetes namespaces (RBAC separation), Pod Security Standards (restriction of pod system capabilities), network policies and dedicated Kubernetes node scheduling. The success of the attacker depends on the effectiveness of these security controls. In our 2023 Kubernetes Security Report, we stressed the abundance of lateral movement opportunities once an attacker gains initial access. The array of security vulnerabilities involving Kubernetes infrastructure, found by the Wiz Vulnerability Research team, testifies to this.
We strongly recommend using a mix of security boundaries within the cluster, and in particular:
Separate front-end and externally facing pods into a distinct namespace, assigning their Service Accounts minimal privileges.
Apply appropriate Pod Security Standards (PSS) levels to your workload at the namespace level. Split namespaces if needed based on sensitivity levels.
When managing vulnerabilities in pods, prioritize those pods that are publicly exposed and those with powerful privileges.
For more restrictive hard multi-tenancy consider using separate K8s clusters. Check out PEACH cloud isolation framework for details.
NodePort Service
Kubernetes provides multiple ways to expose workloads to external users, with load balancer services and application gateways being the most popular. Another, less common, way to expose pods is via a NodePort service. When a cluster operator creates a NodePort service, Kubernetes opens a static port in the default range of 30000–32767 on the worker node.
There are several security concerns with NodePort, primarily because it 'is not typically used in production systems. As such, its presence could indicate an unintended service exposure. The same port is open on all nodes in the cluster, even if the workload is not present, unnecessarily increasing exposure. Each node proxies the port into the service, making direct access possible. Fine-grained network access controls are also more limited compared to load balancer services. Our internal analysis on a random sample of 100 Wiz tenants with Kubernetes setups shows that about 6% have NodePort services exposed externally.
Images and supply chain
Container images present a less obvious, but still risky, access vector. If an attacker controls an image and a cluster pod pulls it, the path from container execution to local node admin—and potentially to cluster admin—can be short. One of the most infamous vulnerabilities that emphasized the risks of untrusted images was Leaky Vessels, published last winter. Vulnerabilities in the runc library allowed unauthorized host-level access merely by deploying a pod with a malicious image.
To mitigate these risks:
Apply appropriate PSS levels for data plane workloads to prevent container escapes.
Use namespaces as a security boundary against lateral movement, limiting RBAC permissions to the namespace scope.
Consider using user namespaces on pods that don’t require special conditions, as per our previous research. This advanced feature renders root permissions ineffective in a host context.
It's also important to know that images are one of the few vectors that can't be mitigated by network restrictions, since pods need to download images from a container registry. Malicious images stress the importance of having high-quality software and a strong chain of custody with SBOM and signing from a trusted partner. This highlights the importance of verifying container images before use. Two strategies for image security are:
Maintaining a local (mirror) container registry with vulnerability and provenance checks.
Implementing image signature verification via the Admission Controller (AC) logic to ensure only signed, trusted images are deployed.
Wiz has recently made it extremely easy to ensure a secure software supply chain in Kubernetes clusters. The traditional approach to verifying images is by establishing image trust via digital signatures. This ensures that deployed images came from trusted sources (using the public key to verify at deploy time the signed images).
Wiz's Image Trust and Kubernetes Audit Log Collector
Secure your applications across the SDLC by deploying only trusted images and monitoring your Kubernetes control plane in near-real time to detect potential threats.
Read more
Wiz took it to the next level with Wiz Image Trust, allowing you to not only establish trust, but to also tightly tie a security policy to each deployed image, thereby ensuring that the image meets the organization security compliance: scanning for CVEs, malware and embedded secrets before the image gets pulled and at any given point in time – easily navigating back to the CI/CD scan and scan policy that is associated with the deployed image. This is done without having to deal with key management, which is one of the most challenging operational aspects typically associated with signing and verifying images.
Execution-as-a-service
An often-underestimated initial access vector is execution-as-a-service, wherein a service vendor offers execution to service users. The ability to run external AI models, for example, is equivalent to execution of arbitrary code. Since Kubernetes is such a handy technology, AI vendors increasingly utilize K8s pods and containers to run the models. As a result, vendors must rely on K8s security separation controls, which, as we have seen before, are hard to get right.
The Wiz vulnerability research team has found cross-tenant vulnerabilities in multiple AI services, such as HuggingFace Inference API, Replicate, and SAP AI Core. These research pieces illustrate the main risk associated with such service – cross-tenant access. The diagram below shows the typical flow of the compromise:
Moreover, this attack flow can be generalized to impact any execution-as-a-service infrastructure that relies on Kubernetes clusters on the backend. Vendors offering such services must enforce strict security controls around the execution environment. Below are the key measures to consider:
Namespace per execution pod (where feasible): Isolating each pod into its own namespace helps contain potential breaches and limits the attack surface.
User namespaces for execution pods: This advanced feature prevents container root privileges from translating to host-level root access, adding an extra layer of security.
Network security policies: Implementing fine-grained network policies restricts pod-to-pod communication, reducing the likelihood of lateral movement between workloads.
Node-per-tenant scheduling: Assigning individual worker nodes to different tenants ensures isolation and prevents cross-tenant threats in shared infrastructure environments.
Kernel isolation and sandboxing (e.g., Kata containers, gVisor, seccomp, AppArmor): Using additional kernel-level isolation and sandboxing technologies significantly reduces the risk of container escapes and enhances security at the system level.
Finally, depending on how effectively these controls are implemented, consider switching to separate VMs instead of relying on Kubernetes clusters to achieve even stronger isolation.
Cloud Access and CI/CD
Due to space limitations, we can’t cover the extensive topics of cloud access and CI/CD pipelines in this post, but they are critical areas in Kubernetes security. Our 2023 Kubernetes Security Report highlights that the vast majority of clusters (over 80%) are managed and run in the cloud, making them an integral part of broader cloud infrastructure. This means cluster operators must have visibility into cloud IAM (Identity and Access Management) to manage access to clusters at scale effectively.
Cloud IAM is a dynamic and complex area, with new features regularly being introduced. We anticipate that more privilege escalation vulnerabilities will arise from this space, similar to the one we detailed earlier in this series. Keeping track of these developments is essential to stay ahead of emerging risks.
CI/CD pipelines, which sit at the core of modern software development process, are another essential vector for Kubernetes security. Kubernetes integrates into CI/CD toolchains, with operators like ArgoCD and Flux automating K8s resource deployments across new and existing clusters. These tools streamline operations, but they also represent a significant security concern, as CI/CD workflows often have admin-level access to Kubernetes environments, potentially giving attackers a route to gain initial foothold in clusters.
Conclusion
This concludes our 2-blog series on Kubernetes initial access (read part one). As shown, Kubernetes is a complex, distributed system with multiple access vectors, any of which—if left unsecured - can lead to a full cluster compromise. We hope this taxonomy helps systematize and prioritize associated risks.
