Can't patch fast enough? Zero trust as a last line of defense

The velocity at which new features are added and applications evolve directly drives up architectural complexity. This relentless pace isn't just driven by the desire for new features; it is increasingly forced by the constant discovery of new vulnerabilities. Patching a single critical dependency can trigger a cascade of required updates and unexpected architectural changes as each product and solution comes with a myriad of implementation options and various features to enable or disable. Tailoring this complexity to your specific environment makes it challenging to guarantee every component is deployed according to industry best practices. Validated patterns bridge this gap by providing ready-to-use, heavily tested deployment patterns for various use cases, mitigating the need to build complex, security-focused architectures from scratch.

The uncomfortable truth about vulnerability management

In 2025, over 40,000 new CVEs were published. That's more than 100 every single day. Today, AI-powered exploit generation is drastically accelerating the time from vulnerability disclosure to active exploitation in the wild. "Chasing the holy grail" shows how pursuing a perfect score of zero CVEs can sometimes be counterproductive if it distracts from deeper defense-in-depth strategies. A component that's "clean" at 9 AM might have a newly disclosed vulnerability by 5 PM. Even when you achieve zero known CVEs, unknown vulnerabilities always remain.

The patching math (the misconception that security is just a numbers game where fewer CVEs means less risk) simply doesn't add up for enterprise environments running hundreds of containerized workloads. Unlike traditional monolithic architectures running on a single operating system, distributed container environments introduce significantly higher architectural complexity. Countless microservices and network touchpoints offer far more configuration options where something can go wrong and inadvertently create a security gap. Trying to fix absolutely everything instantly is a Sisyphean task that conflicts with a modern, risk-based security strategy. It also ignores a fundamental truth: no matter how aggressively you try to apply updates, there will always be a lag.

So, what do you do in the gap between vulnerability disclosure and patch deployment? The answer lies in a security principle that has been around for years but is more critical today than ever: Zero-trust architecture.

What zero trust means for your Red Hat OpenShift cluster

Zero trust is not a product you install. It's an architectural philosophy that assumes a breach has already occurred, mandating that every interaction must be explicitly verified and authorized. According to NIST SP 800-207, zero trust means removing implicit trust granted to resources — assets, applications, or user accounts — based solely on their physical or network location. Authentication and authorization are discrete functions performed before any session to an enterprise resource is established.

Implementing zero trust in Kubernetes and Red Hat OpenShift requires a multi-layered approach spanning workload identity, secret management, and runtime access control. Specifically within the networking domain, one of the most critical implications of this philosophy is moving beyond the default flat network posture where every pod can communicate freely. By default, Kubernetes applies no internal network restrictions, equivalent to leaving every internal door in a building unlocked simply because the building has a front gate (such as a cluster ingress controller, API gateway, or perimeter firewall). However, relying solely on this perimeter defense is fundamentally insufficient for modern cloud-native environments.

According to the zero trust model, we assume a breach has already occurred and that bad actors are already inside your environment, whether they are external attackers who bypassed the perimeter, a compromised supply chain component, or malicious internal threats operating directly from within. By implementing Kubernetes network resource restrictions, we create a default deny network connection with explicit authentication and authorization to use the network and reach other resources attached to it (Figure 1).

From theory to practice: The layered zero trust validated pattern (ZTVP)

To translate these best practices into reality, we leverage the Layered Zero Trust Validated Pattern (ZTVP). A validated pattern embodies Infrastructure as Code (IaC) best practices and GitOps automation, drastically reducing setup time for complex OpenShift deployments engineered for security and scalability. Over the last three months, the ZTVP project has made significant strides, achieving Tested Tier accreditation.

The pattern brings together multiple components into a cohesive, GitOps-deployed zero-trust architecture:

• Zero trust workload identity manager: Provides short-lived, cryptographic identities based on the SPIFFE/SPIRE project to workloads.
• HashiCorp Vault: Stores sensitive assets and cluster secrets in a security-first manner, integrated with ZTWIM for JWT authentication.
• Red Hat build of Keycloak: Manages user authentication and federated identity.
• Red Hat Advanced Cluster Security for Kubernetes: Acts as the intelligent security brain, providing unified multi-cluster monitoring, proactive admission control, real-time behavioral anomaly detection and crucially in our example, a network policy analyzer.

Network policies: The last line of defense

While network policies are often discussed as a foundation of zero trust, they are not a principle in themselves. Instead, they are a proactive, architectural mechanism used to enforce the desired outcomes of a zero trust model. Red Hat outlines four core principles of zero trust, and well-designed network policies actively support every single one of them:

• Microsegmentation: By governing traffic at the individual pod level, network policies inherently divide the cluster into granular, security-enhanced segments.
• Least-privilege access: A default-deny posture provides that workloads are only granted the exact network permissions they absolutely need to function, and nothing more.
• Deperimeterization: Security controls are moved away from just the cluster's "front gate" and applied directly around the workloads themselves.
• Assume breach: By proactively eliminating lateral attack paths, strict ingress and egress rules are already in place to contain the blast radius the moment a compromise occurs.

Furthermore, an extremely important aspect of Kubernetes network policies is that they exist on a separate control plane from the application pods they protect. This means that even if an attacker successfully breaches a container and gains elevated privileges within that application, they cannot simply redefine or bypass the network boundaries restricting them. To enhance the overall security posture of the internal environment and truly put these principles into practice, we must define fine-grained network policies that govern both ingress and egress traffic at the pod level:

• Ingress policies: These control the incoming traffic to a pod, enforcing a rule that a service only accepts connections from explicitly authorized sources. If a neighboring pod in the cluster is compromised, a strong ingress policy prevents the attacker from accessing your sensitive workloads laterally.
• Egress policies: These control the outgoing traffic from a pod. Their goal is to strictly limit what external or internal resources a pod can reach. If a pod is compromised, egress policies neutralize an attacker's ability to exfiltrate data, perform broad network reconnaissance, or download malicious payloads from external command-and-control servers.

The default-deny foundation

While defining specific ingress and egress rules is crucial, relying on them alone leaves a dangerous gap, allowing for human error and deceptive attacks. By default, Kubernetes operates on an allow-all model, meaning any traffic not explicitly restricted is permitted. If a developer simply forgets to apply a policy, that pod is left wide open. But the risk goes beyond honest mistakes. In a supply chain attack, a developer might be unknowingly tricked into deploying a compromised third-party component, completely unaware of the hidden malicious payload or its consequences.

A default-deny policy flips this paradigm from a blocklist to an allowlist. The core tenet of zero trust mandates that every single interaction must be explicitly authorized, so it logically follows that absolutely no access can be implicit. By strictly blocking all traffic right out of the gate, a default-deny posture creates an environment where an accidental omission (or a cleverly disguised rogue container attempting to phone home) results in a safely blocked connection. It forces you to explicitly grant access by design, turning what could be a silent, catastrophic breach into a noticeable, easily fixed deployment error.

The approach starts with a simple but powerful rule: Deny all traffic by default. Every namespace receives a default-deny NetworkPolicy that blocks all ingress and egress for every pod unless an explicit allow policy exists.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-in-namespace
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

As soon as a NetworkPolicy targets a pod in a namespace, it no longer retains unrestricted access. By defining a policy that blocks access by default, it aligns with a zero trust deny by default posture.

Why this matters when you can't patch

Consider an enterprise scenario reminiscent of the infamous Log4j crisis or more recent framework shocks like the React2Shell vulnerability (CVE-2025-55182):

1. A critical remote code execution (RCE) vulnerability is abruptly disclosed in a ubiquitous library used by your application.
2. The vulnerability allows full server takeover if an attacker can simply send a specially crafted request to the affected service.
3. Because the library is deeply embedded in your dependencies, a validated patch won't be successfully tested and deployed to production for several days.

The impact on an organization with zero trust network policies is minimal:

• An attacker compromising any pod can easily reach the vulnerable service across any namespace (no lateral isolation).
  • With ZTVP network policies: The attacker cannot reach the service from another namespace (namespace isolation).
• An attacker can connect to any exposed port on the service, including critical or management ports (no port-level filtering).
  • With ZTVP network policies: The attacker cannot connect to ports that aren't explicitly allowed (port-level filtering).
• An attacker can freely make outbound connections to exfiltrate data or establish command and control (C2) channels (no egress restrictions).
  • With ZTVP network policies: The attacker cannot exfiltrate data to external endpoints (egress restrictions).

Demonstration: Eliminating the attack path

We've created a demonstration video in which we observe exactly how properly implemented network policies actively eliminate attack paths. Initially, we see an environment without a default-deny posture, where an attacker leveraging a supply chain vulnerability can easily perform extensive reconnaissance, freely probing the network for other unpatched components to exploit. Then we see that once strict network policies are applied, the story changes completely.

Even if an attacker manages to successfully breach a pod, their capacity to research the network, scan for vulnerabilities, or pivot laterally is entirely neutralized. The policies restrict them to the compromised container, effectively containing the threat and buying you the crucial time needed to implement corrective actions. While they may not be the only fail-safe in a comprehensive security strategy, establishing strict network boundaries is arguably the best starting point for building your last line of defense.

This demonstration shows how network policies restrict an attack to the compromised container, effectively containing the threat and buying you the crucial time needed to implement corrective actions.

The broader picture: Defense in depth

Network policies are just one layer of a comprehensive strategy. The Layered Zero Trust Validated Pattern combines these policies with SPIFFE/SPIRE workload identities (using zero trust workload identity manager), Vault-managed secrets, centralized authentication using an identity provider (IdP) such as our default Red Hat build of Keycloak, and Red Hat Advanced Cluster Security for Kubernetes runtime monitoring. Network policies complete the picture by ensuring that even if identity, secrets, and application security fail, the network layer provides containment.

But how do you know if your network policies are actually working, or if a compromised container is repeatedly probing your internal boundaries? What happens when a zero-day exploit triggers a denied connection?

We help answer these critical questions over the course of this blog series exploring how the Layered Zero Trust Validated Pattern implements zero-trust security practices. Here's what to expect as we continue:

• Active defense with Red Hat Advanced Cluster Security for Kubernetes: Implementing deep runtime monitoring, automated network policy scanning, and real-time alerting to act as your central security brain.
• Identity and secrets: Managing workload identities more securely with zero trust workload identity manager and Vault integration.
• Supply chain: Locking down your software supply chain from end to end by enforcing content signatures and verifying pipeline tasks to guarantee only trusted code reaches your cluster.

Ready to see it in action? You don't have to wait for the next article to get started. Check out the Layered Zero Trust Validated Pattern to explore the architecture, and try the network policies demo for yourself.

References

• NIST SP 800-207: Zero Trust Architecture
• NIST SP 800-207A: Zero Trust for Cloud-Native Applications
• CISA: Zero Trust Microsegmentation Guidance
• Layered Zero Trust Validated Pattern
• Validated Patterns
• Chasing the Holy Grail: Why Red Hat's Hummingbird Project aims for near-zero CVEs
• CVE Metrics