Lights on! Real-time threat response with Red Hat Advanced Cluster Security

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 brain

While 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:

Trust, but verify: Monitoring network policy compliance

How 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 policy
• Deployments must have at least one egress network policy

Currently, 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 runtime

Because 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 Monitoring
• Dangerous Command Execution Detection

Demonstration: Real-time threat detection and pod termination

In 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.

Real-time threat response with Red Hat Advanced Cluster Security by assuming a breach and neutralizing threats.

Closing the loop: Real-time admin visibility

Killing a compromised pod neutralizes the immediate threat, but the environment maintainers team and also security team still need to know that an attack was attempted. Today, all of these high-fidelity alerts, detailing the suspicious behavior, the specific commands attempted, and the enforcement action taken, are immediately logged and visible directly within the Red Hat Advanced Cluster Security console. This allows teams to investigate the root cause, such as identifying a vulnerable supply chain component, without the pressure of an active, escalating breach. However, to close the loop, we are actively working to expand this capability. The ZTVP roadmap includes planned integrations with external tracking and alerting systems, like Atlassian Jira. Soon, cluster administrators and security teams will be able to receive these critical real-time notifications directly in their preferred operational channels, providing even greater visibility and a faster incident response workflow.

The zero trust reality

Highlighting this runtime defense brings us back to the core of the zero trust model. No system is impenetrable. Our previous article established that chasing the "holy grail" of zero known CVEs is a losing battle when you cannot patch fast enough. The ultimate realization of the zero trust model is that vulnerabilities (both known CVEs and as-yet-undiscovered zero-days) are inevitable.

While strict network policies are foundational to establish "gates", and advanced controls like content signatures and pipeline verification are crucial to secure the supply chain, they are not comprehensive. The ability to monitor workloads in real-time, detect anomalous behavior, and automatically terminate threats at runtime is what separates a brittle system from a truly resilient one against the unknown.

You don't have to wait for the next installment to implement a resilient defense.

• Implement active monitoring: Deploy the custom Red Hat Advanced Cluster Security policies outlined in this article (by following the policies chart in the Validated Pattern repository) to start transforming silent network blocks into high-fidelity security intelligence.
• Explore the architecture: Review the full architecture of the Layered Zero Trust Validated Pattern to understand how this runtime surveillance fits into the broader picture.

In the next installment of this series, we explore how ZTVP secures workload identities using SPIFFE/SPIRE with zero trust workload identity manager, ensuring that even when a workload behaves perfectly, it still has to cryptographically prove exactly who it is.