Part 2 of a series on implementing zero trust in Red Hat OpenShift with the layered zero trust validated pattern (ZTVP)In our previous article, we explored why network policies, specifically a default-deny posture combined with strict ingress and egress rules, are your critical last line of defense when you can’t patch fast enough or when all other security barriers fail. By locking down network communication, we effectively eliminate lateral attack paths and contain the blast radius of a compromised workload.But a true zero-trust architecture as defined by NIST SP 800-207 isn't about building stronger perimeter walls, it's about building better gates and continuously verifying what passes through them. Network policies give us the gates. But if we assume a breach has already occurred, we must acknowledge a harsh reality: Even the best static access controls aren't enough on their own. When a zero-day vulnerability strikes, you need active runtime surveillance to detect anomalous behavior inside the workload. Even with the best network policies in place, there is always the looming threat of an unannounced zero-day vulnerability.If an attacker is trapped inside a container by your network policies, what are they doing in there? To answer that, you need a central security "brain". In the Layered Zero Trust Validated Pattern (ZTVP), that brain is Red Hat Advanced Cluster Security.Red Hat Advanced Cluster Security: The brainWhile network policies dictate what should happen, Red Hat Advanced Cluster Security (ACS) monitors what is actually happening. In the context of an idealized NIST 800-207 zero-trust architecture, this continuous monitoring is what completes the critical security control loop. It continuously gathers real-time transaction and behavioral context, acting as a policy information point (PIP). This is fed back to the central intelligence engine, the policy decision point (PDP). In this way, Red Hat Advanced Cluster Security can instantly trigger automated responses at the policy enforcement point (PEP)—such as revoking access or terminating a compromised workload.Within ZTVP, we don't just deploy the default configuration of Red Hat Advanced Cluster Security. We deploy it configured with custom, tailored security policies adhering to industry best practices to enforce this dynamic zero trust model at runtime. Our custom deployment introduces four critical policies—fully defined and available in the Layered Zero Trust Validated Pattern repository—designed to work in tandem with the network layer. To provide clear visibility into these controls, they are divided into two distinct operational categories: Alerting (which verifies that our network "gates" are properly configured during deployment) and Termination (which actively neutralizes an ongoing threat at runtime).These four policies are outlined below:Category(SDLC phase)Policy NameEnforcement ActionAlerting (Deploy)Deployments should have at least one ingress Network PolicyAlerts administrators if a deployment is pushed without an ingress boundary, highlighting workloads unnecessarily exposed to internal network traffic.Alerting (Deploy)Deployments should have at least one egress Network PolicyAlerts administrators if a deployment lacks an egress boundary, identifying configurations that could allow data exfiltration or unrestricted lateral movement.Termination (Runtime)Prevent Runtime Privilege EscalationInstantly kills the pod if a container attempts to elevate privileges (for example, running sudo, su, or pkexec) or displays indicators of a container escape (such as nsenter or unshare).Termination (Runtime)Stop Suspicious ExecImmediately terminates the pod if an attacker attempts to execute reconnaissance or networking tools (such as nmap, nc, or ncat), completely cutting off their ability to map the internal environment.Trust, but verify: Monitoring network policy complianceHow exactly do you guarantee that every workload is actually protected by these gates, and that a critical network boundary hasn't been accidentally omitted or removed during a deployment update? Furthermore, if a policy is misconfigured and an attacker manages to bypass it, how do you catch them?In the ZTVP, we address this by combining our runtime enforcement with strict deployment checks. To help ensure no workload is left exposed due to a missing or accidentally removed network policy, the ZTVP includes two specific custom ACS deployment policies—enabled by default in alerting mode:Deployments must have at least one ingress network policyDeployments must have at least one egress network policyCurrently, to demonstrate this capability in a controlled manner, and to prevent alert fatigue across an entire cluster, these custom policies are enabled by default only for our ZTVP demo application. Within this scope, the policies continuously scan the environment. If a developer pushes a deployment without defining its specific network boundaries, ACS immediately flags it. This helps ensure that the foundational "gates" are always verified as present, while our runtime termination policies stand ready to catch any anomalous behavior should those gates ever be misconfigured or bypassed.However, let's be candid about the technical limitations of configuration scanning: Red Hat Advanced Cluster Security cannot directly monitor if a namespace-wide "deny by default" policy is actively enforced. Not every architectural best practice can be perfectly validated through static checks. Because of these inevitable blind spots in implementation monitoring, relying purely on alerts leaves a critical gap in our armor.Active defense: Threat elimination at runtimeBecause we know we cannot statically verify every single security control, we must assume that some misconfigurations might slip through, or that an attacker might find a novel way to exploit a workload. When an active attack is underway, alerting is simply not enough; seconds matter. This is where the ZTVP implementation of Red Hat Advanced Cluster Security transitions from a passive monitoring tool into a ruthless active defense mechanism. To bridge the gap left by static monitoring limitations, two additional custom policies were implemented and is enabled in termination mode:Suspicious Pod Behavior MonitoringDangerous Command Execution DetectionDemonstration: Real-time threat detection and pod terminationIn this short video, we put the core zero trust principle of "assume a breach"—established in our first article—to the ultimate test. We simulate a scenario where an attacker has already successfully bypassed initial boundaries and gained access to a running pod.Without ZTVP: In a standard environment without strict runtime monitoring, an attacker has unrestricted time to execute discovery commands, map the internal network, probe local files, and experiment with various exploitation options completely undetected.With ZTVP: In a ZTVP-secured cluster, the Red Hat Advanced Cluster Security runtime monitoring immediately detects an attacker's initial reconnaissance command. This action triggers an instant termination policy, dropping the terminal session and killing the rogue pod in real time to neutralize the threat before any further activity occurs..Consider a scenario where a zero-day vulnerability in a supply chain component allows an attacker to execute code inside one of your pods. Even if your network policies successfully block them from pivoting to other namespaces or exfiltrating data, they are still inside the pod, where attempts to run reconnaissance scripts, inject payloads, or execute shell commands, can take place.The moment the attacker tries to execute a dangerous command or exhibit suspicious behavior, ACS detects the anomaly. Because these policies are set to termination mode within the ZTVP, Red Hat Advanced Cluster Security doesn't just send an alert, it immediately kills the rogue pod.This is the ultimate synergy of defense in depth: Network policies block the attacker's escape routes, and active runtime monitoring eliminates the threat entirely. Even if a configuration was missed, the risk of a successful, prolonged attack drops effectively to zero.