From ccd82397f1dc50fbd6964893b09159e1ca8a0ede Mon Sep 17 00:00:00 2001 From: Laura Bailey Date: Tue, 3 Nov 2026 23:32:50 +1000 Subject: [PATCH] MBP-1195 xpost of third and fourth ZTVP articles on rhblog --- ...-the-loop-network-policy-verification.adoc | 41 ++++++++++ ...26-10-22-ztvp-zero-trust-on-openshift.adoc | 74 +++++++++++++++++++ 2 files changed, 115 insertions(+) create mode 100644 content/blog/2026-09-10-closing-the-loop-network-policy-verification.adoc create mode 100644 content/blog/2026-10-22-ztvp-zero-trust-on-openshift.adoc diff --git a/content/blog/2026-09-10-closing-the-loop-network-policy-verification.adoc b/content/blog/2026-09-10-closing-the-loop-network-policy-verification.adoc new file mode 100644 index 000000000..78aaec9d6 --- /dev/null +++ b/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] diff --git a/content/blog/2026-10-22-ztvp-zero-trust-on-openshift.adoc b/content/blog/2026-10-22-ztvp-zero-trust-on-openshift.adoc new file mode 100644 index 000000000..535c97fe6 --- /dev/null +++ b/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]