MBP-1195 xpost of third and fourth ZTVP articles on rhblog

content/blog/2026-09-10-closing-the-loop-network-policy-verification.adoc

@@ -0,0 +1,41 @@
+---
+title: "Closing the loop: From network policy intent to verified reality"
+date: 2026-09-10
+summary: Declaring network policy is only half the battle. This post covers common mistakes that undermine network policy intent, the importance of verifying real behavior at runtime, and the design-test-deploy-observe loop that underpins the Zero Trust Validated Pattern.
+author: Przemyslaw Roguski
+blog_tags:
+- patterns
+- zero-trust
+- security
+- network-policies
+- openshift
+---
+:toc:
+:imagesdir: /images
+
+== Intent is not verification
+
+A Kubernetes NetworkPolicy declares intent: _this pod should only accept connections from the ingress namespace through port 8443._ But you know the line about good intentions, right? Writing a policy and applying it to a cluster is only half the job. You also need to verify that what you intended is what happens in reality.
+
+The https://validatedpatterns.io/blog/2026-06-29-zero-trust-network-policies/[first article] in the Layered Zero Trust Validated Pattern series showed how this pattern combines default-deny policies with per-pod allow rules to limit the damage potential of a compromised workload in accordance with https://csrc.nist.gov/pubs/sp/800/207/final[NIST SP 800-207].
+
+The https://validatedpatterns.io/blog/2026-07-29-zero-trust-runtime-threat-response/[second article] showed how Red Hat Advanced Cluster Security enforces those boundaries at runtime.
+
+The third article in the series pulls network policy intent into the real world.
+
+* Learn from seven common mistakes that undermine network policies.
+* Understand the limitations of the policy analysis tooling landscape.
+* See how the Layered Zero Trust Validated Pattern uses a design-test-deploy-observe loop to close the gap between policy intent and real-world impact.
+
+== Read the full article
+
+For the complete breakdown of mistakes that catch out even experienced architects, the gap between generated and dry-run policy verification, and how the Layered Zero Trust Validated Pattern addresses these problems, read the full article on the Red Hat blog:
+
+**https://www.redhat.com/en/blog/closing-loop-network-policy-intent-verified-reality[Closing the loop: From network policy intent to verified reality]**
+
+== Get started
+
+The Layered Zero Trust Validated Pattern is open source:
+
+* https://validatedpatterns.io/patterns/layered-zero-trust/[Pattern documentation]
+* https://github.com/validatedpatterns/layered-zero-trust[Source repository]

content/blog/2026-10-22-ztvp-zero-trust-on-openshift.adoc

@@ -0,0 +1,74 @@
+---
+title: "From buzzword to blueprint: Implementing zero trust on Red Hat OpenShift with the Layered Zero Trust Validated Pattern"
+date: 2026-10-22
+summary: Zero trust is quick to describe and hard to make repeatable. This post explains how the decoupled layers of security in the Zero Trust Validated Pattern create a deployable blueprint that can not only act as protection, but also as evidence of compliance.
+author: Przemyslaw Roguski, Michael Epley, Andrew Block
+blog_tags:
+- zero-trust
+- security
+- openshift
+- patterns
+- compliance
+---
+:toc:
+:imagesdir: /images
+
+== From principle to practice
+
+Never trust, always verify. It's a memorable adage, but it doesn't tell a team what to deploy or how to connect Kubernetes controls, and it doesn't prove to a compliance officer that your protections work in practice.
+
+The https://validatedpatterns.io/patterns/layered-zero-trust/[Layered Zero Trust Validated Pattern] (ZTVP) closes that implementation gap with an open, GitOps-managed implementation of coordinated zero trust capabilities for Red Hat OpenShift that teams can adapt to their own applications.
+
+Earlier articles in this series covered individual controls: network policies as a https://validatedpatterns.io/blog/2026-06-29-zero-trust-network-policies/[last line of defense], Red Hat Advanced Cluster Security as a https://validatedpatterns.io/blog/2026-07-29-zero-trust-runtime-threat-response/[runtime enforcement engine], and the gap between https://www.redhat.com/en/blog/closing-loop-network-policy-intent-verified-reality[policy intent and verified reality].
+
+This fourth article shows how the https://validatedpatterns.io/patterns/layered-zero-trust/[Layered Zero Trust Validated Pattern] (ZTVP) pulls these pieces together in an open-source, GitOps-managed zero trust implementation that you can adapt for your own applications.
+
+== Decoupled, layered protection
+
+Under https://csrc.nist.gov/pubs/sp/800/207/final[NIST SP 800-207], there is no such thing as an implicitly trusted network, asset, or account. Authentication and authorization occur before access, and access is continuously evaluated in-context to ensure only approved transactions take place. Each type of transaction necessitates a decision, an enforcement point, and an unambiguous identity that can be used to track evidence of decisions and enforcement that occur.
+
+ZTVP orders the components that handle these required operations into decoupled layers:
+
+* *Layer 0: Foundation* — Establishes a baseline security control loop that every deployment can use. It includes:
+** Red Hat build of Keycloak for user authentication (by default)
+** Zero Trust Workload Identity Manager (SPIFFE and SPIRE) for short-lived workload identities
+** HashiCorp Vault and the External Secrets Operator for just-in-time secrets
+** Cert-Manager Operator for certificate lifecycle management
+** Red Hat Advanced Cluster Security for runtime detection
+** Red Hat Advanced Cluster Management for multi-cluster policy
+** Compliance Operator for continuous scanning and remediation
+
+* *Layer 1: Feature sets* — Extend the baseline to meet specific operational needs, such as secure supply-chain or network flow observability, as your workload develops.
+
+Additionally, Red Hat OpenShift GitOps ensures that your environment exists as code that teams can change, review, and restore through version control.
+
+
+== Supporting your zero-trust journey
+
+In practice, these decoupled layers let ZTVP support three critical user journeys:
+
+. *Protect application data without putting security logic in the application.* Sidecars give the qtodo demo application a SPIFFE identity, exchange it for a Vault credential, and reach PostgreSQL through explicit network policy. No long-lived password sits in the image.
+. *Establish trust from source to running workload.* Red Hat OpenShift Pipelines builds the artifact, Trusted Artifact Signer signs it through a keyless workflow, and Trusted Profile Analyzer analyzes the SBOM before deployment.
+. *Turn security configuration into evidence.* GitOps history, compliance operator scans, and Red Hat Advanced Cluster Security findings are repeatable indicators that support a control narrative when combined with your governance processes.
+
+Finally, although ZTVP is not certification, the article explains how ZTVP supports alignment with the following deployment frameworks:
+
+* https://csrc.nist.gov/pubs/sp/800/207/final[NIST SP 800-207]
+* https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final[NIST SP 800-53 Rev 5]
+* https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model[CISA ZTMM v2.0]
+* EO 14028
+* OMB M-22-09
+* DoD Zero Trust Reference Architecture
+
+== Read the full article
+
+For the complete architecture breakdown, the framework coverage table, and guidance on incremental adoption, read the full article on the Red Hat Blog:
+
+**https://www.redhat.com/en/blog/buzzword-blueprint-implementing-zero-trust-red-hat-openshift-layered-zero-trust-validated-pattern[From buzzword to blueprint: Implementing zero trust on Red Hat OpenShift with the Layered Zero Trust Validated Pattern]**
+
+== Get started
+
+The Layered Zero Trust Validated Pattern is open source:
+
+* https://validatedpatterns.io/patterns/layered-zero-trust/[Pattern documentation]
+* https://github.com/validatedpatterns/layered-zero-trust[Source repository]