docs: restructure Layered Zero Trust documentation

content/patterns/layered-zero-trust/lzt-architecture.adoc

@@ -0,0 +1,180 @@
+---
+title: Architecture
+weight: 5
+aliases: /layered-zero-trust/lzt-architecture/
+---
+
+:toc:
+:imagesdir: /images
+:_mod-docs-content-type: ASSEMBLY
+include::modules/comm-attributes.adoc[]
+
+[id="lzt-architecture"]
+= Architecture
+
+The Layered Zero Trust pattern implements a layered zero trust architecture that provides workload identity management, secure communication, secret management, runtime security monitoring, and compliance scanning on {rh-ocp}.
+
+[id="layered-architecture-overview"]
+== Layered architecture overview
+
+The ZTVP is structured in three decoupled layers, each building on the one below:
+
+* *Layer 0 — Foundation*: The always-deployed security baseline. These components are installed automatically with every ZTVP deployment and provide the core Zero Trust capabilities.
+* *Layer 1 — Feature Sets*: Optional capabilities that can be enabled per use case. These extend the foundation with additional security services like supply chain signing, private registries, and network observability.
+* *Layer 2 — Use Cases*: Real applications that demonstrate Zero Trust principles in practice. They consume the services provided by Layers 0 and 1.
+
+image::layered-zero-trust/layered-zero-trust-architecture-diagram.png[Layered Zero Trust architecture diagram]
+
+[id="layer-0-foundation"]
+=== Layer 0 — Foundation
+
+[cols="2,3,2",options="header"]
+|===
+| Component | What it does | Zero Trust contribution
+
+| HashiCorp Vault
+| Centralized secret storage and management with JWT-based authentication
+| Dynamic secrets, just-in-time credential injection
+
+| Zero Trust Workload Identity Manager (SPIRE/SPIFFE)
+| Assigns short-lived cryptographic identities to workloads
+| No shared secrets, mutual authentication
+
+| Red{nbsp}Hat build of Keycloak
+| User authentication and SSO via OIDC
+| Centralized identity, per-application access control
+
+| External Secrets Operator
+| Synchronizes secrets from Vault into {ocp}
+| Automated secret lifecycle management
+
+| Red{nbsp}Hat Cert Manager
+| Automated TLS certificate lifecycle
+| Encrypted communications, daily CA rotation
+
+| Compliance Operator
+| CIS benchmark scanning and automated remediation
+| Continuous compliance monitoring
+
+| {rh-rhacm}
+| Multi-cluster management control plane
+| Centralized policy enforcement
+
+| Red{nbsp}Hat Advanced Cluster Security
+| Runtime security monitoring, threat detection and response
+| Continuous monitoring, automated threat termination
+|===
+
+[id="layer-1-feature-sets"]
+=== Layer 1 — Feature Sets
+
+[cols="2,3,2",options="header"]
+|===
+| Component | What it does | Required for
+
+| Red{nbsp}Hat Quay
+| Private OCI image registry
+| Supply chain security use cases
+
+| Multicloud Object Gateway (NooBaa)
+| Object storage service for {ocp}
+| Quay storage backend, Network Observability
+
+| Red{nbsp}Hat Trusted Artifact Signer (RHTAS)
+| Keyless signing and verification of container images and artifacts
+| Secure supply chain
+
+| Red{nbsp}Hat Trusted Profile Analyzer (RHTPA)
+| SBOM storage, analysis, and CVE cross-referencing
+| Supply chain vulnerability analysis
+
+| Red{nbsp}Hat OpenShift Pipelines
+| Cloud-native CI/CD on {ocp}
+| Automated supply chain workflows
+
+| Network Observability (Loki + FlowCollector)
+| Network flow monitoring and visualization
+| Network traffic analysis
+|===
+
+[id="layer-2-use-cases"]
+=== Layer 2 — Use Cases
+
+[cols="2,3",options="header"]
+|===
+| Use case | Description
+
+| xref:/patterns/layered-zero-trust/lzt-data-protection.adoc[Zero Trust Data Protection]
+| The `qtodo` demo application shows how workload identity, dynamic secrets, user authentication, and network segmentation protect a real application — with zero code changes.
+
+| xref:/patterns/layered-zero-trust/lzt-secure-supply-chain.adoc[Secure Supply Chain]
+| Manual walkthrough of container image signing, SBOM generation, and artifact verification using RHTAS and RHTPA.
+
+| xref:/patterns/layered-zero-trust/lzt-automated-secure-supply-chain.adoc[Automated Supply Chain]
+| Tekton pipeline automating the build, sign, verify, and deploy workflow end-to-end.
+|===
+
+[id="sidecar-pattern"]
+== Sidecar pattern
+
+The sidecar pattern is a deployment model where a separate container runs alongside the main application to handle auxiliary tasks. In an {ocp} environment, pods simplify this by ensuring the sidecar and main application share the same lifecycle. This approach benefits Zero Trust architectures by enabling centralized enforcement of security policies such as authentication, authorization, traffic encryption (mTLS), rate limiting, auditing, and logging — without requiring developers to add this logic to every microservice.
+
+The Layered Zero Trust pattern uses the sidecar approach to offload critical security functions from the main application. This centralizes policy enforcement, simplifies development, and separates security concerns.
+
+[id="applied-sidecar-pattern-data-protection"]
+=== Applied sidecar pattern: Data protection
+
+The following diagrams illustrate how the sidecar pattern is applied in practice to solve the Data Protection use case. They demonstrate how an application (`qtodo`) retrieves database credentials dynamically without hard-coding secrets.
+
+==== Logical structure
+
+The logical structure diagram shows the composition of the application pod and its relationship to the infrastructure.
+
+* *Decoupled components*: The `qtodo` application logic is separated from security functions. The application container runs alongside helper sidecars (spiffe-vault-client, spiffe-helper) and init containers.
+* *Infrastructure layers*: The sidecars bridge the gap between the application and the platform services:
+
+** *Workload identity*: The sidecars interface with SPIRE to prove the pod's identity.
+** *Secret management*: They connect to HashiCorp Vault to fetch secrets.
+** *Trust anchors*: Keycloak and Cert Manager provide the root trust for the ecosystem.
+
+image::layered-zero-trust/layered-zero-trust-data-protection-logical.png[Logical structure of the sidecar pattern for data protection]
+
+==== Schematic workflow
+
+The schematic diagram details the step-by-step execution flow:
+
+* *Identity minting* (Steps 3-6): Upon startup, the SPIRE Agent validates the pod (via node attestors and kubelet) and mints a cryptographic identity (SPIFFE ID).
+* *Secret retrieval* (Step 7): The spiffe-vault-client sidecar uses this verified identity to authenticate with HashiCorp Vault and request the specific credentials needed for the database.
+* *Secure access* (Steps 8-9): The credentials are passed to the application, allowing it to authenticate and establish a connection to the PostgreSQL database securely.
+
+image::layered-zero-trust/layered-zero-trust-data-protection-schematic.png[Schematic workflow of the sidecar pattern for data protection]
+
+[id="deployment-variants"]
+== Deployment variants
+
+The pattern supports multiple deployment configurations:
+
+[cols="2,3",options="header"]
+|===
+| Configuration file | Description
+
+| `values-hub.yaml`
+| Default hub cluster deployment with the full Layer 0 foundation
+
+| `values-coco-dev.yaml`
+| Development variant for Confidential Containers integration
+|===
+
+[id="feature-variant-system"]
+== Feature variant system
+
+Layer 1 features can be enabled or disabled independently using the feature variant system. Feature definitions are stored in `scripts/features/` and can be composed into deployment configurations using the `gen-feature-variants.py` script.
+
+For example, to generate a `values-hub.yaml` with Network Observability enabled:
+
+[source,terminal]
+----
+$ python3 scripts/gen-feature-variants.py --features netobserv
+----
+
+See the link:https://github.com/validatedpatterns/layered-zero-trust/tree/main/scripts/features[feature definitions] in the repository for available options.

content/patterns/layered-zero-trust/lzt-automated-secure-supply-chain.adoc

@@ -1,6 +1,7 @@
 ---
 title: Secure supply chain - Automated approach
 weight: 40
+
 aliases: /layered-zero-trust/lzt-automated-secure-supply-chain/
 ---
 

content/patterns/layered-zero-trust/lzt-data-protection.adoc

@@ -0,0 +1,97 @@
+---
+title: Data protection
+weight: 20
+aliases: /layered-zero-trust/lzt-data-protection/
+---
+
+:toc:
+:imagesdir: /images
+:_mod-docs-content-type: ASSEMBLY
+include::modules/comm-attributes.adoc[]
+
+[id="lzt-demo-application"]
+= Data protection
+
+This use case demonstrates Zero Trust data protection using the `qtodo` demo application — a simple to-do list app built with Quarkus and PostgreSQL that is included in the default Layered Zero Trust pattern installation described in the xref:/patterns/layered-zero-trust/lzt-getting-started.adoc[Getting Started] guide. No additional setup is required to explore this use case.
+
+[id="what-this-demonstrates"]
+== What this demonstrates
+
+On its own, the `qtodo` application is unremarkable. What makes it special is _how_ it runs inside the ZTVP — every interaction is authenticated, every credential is dynamic, and every network connection is explicitly authorized. No application code was changed to achieve this.
+
+[id="security-features-in-action"]
+== Security features in action
+
+When a user accesses the `qtodo` application, the following security features activate:
+
+[id="user-authentication"]
+=== 1. User authentication
+
+The user is redirected to Red{nbsp}Hat build of Keycloak for login. Only users with the correct role in the `ztvp` realm can access the application. No credentials are stored in the application code.
+
+[id="workload-identity"]
+=== 2. Workload identity
+
+The `qtodo` pod proves its identity using a cryptographic SPIFFE certificate (SVID). This identity is issued by SPIRE and rotates automatically every hour. No static service account tokens are used.
+
+[id="dynamic-secrets"]
+=== 3. Dynamic secrets
+
+The `spiffe-vault-client` sidecar uses the pod's SPIFFE identity to authenticate with HashiCorp Vault and retrieve the PostgreSQL password. The password is never stored as a Kubernetes Secret — it's fetched just-in-time and exists only in memory.
+
+[id="network-isolation"]
+=== 4. Network isolation
+
+Default-deny NetworkPolicies block all traffic. Explicit allow rules permit only the connections that the application requires: browser to `qtodo` (port 8443), `qtodo` to PostgreSQL (port 5432), `qtodo` to Vault (port 8200), and `qtodo` to DNS (port 5353). Nothing else is permitted.
+
+[id="before-vs-after"]
+== Before vs. after
+
+[cols="2,2,3",options="header"]
+|===
+| Aspect | Traditional deployment | With ZTVP
+
+| Database credentials
+| Static Kubernetes Secret in etcd
+| Dynamic, fetched from Vault via SPIFFE
+
+| User authentication
+| Application-managed or none
+| Centralized Keycloak SSO
+
+| Network access
+| Allow-all (Kubernetes default)
+| Default-deny with per-pod allow rules
+
+| Workload identity
+| Shared service account
+| Cryptographic SPIFFE SVID (1-hour TTL)
+
+| Code changes required
+| N/A
+| None — security injected via sidecars
+|===
+
+[id="try-it-yourself"]
+== Try it yourself
+
+After deploying the ZTVP, you can access the `qtodo` application and observe the Zero Trust security features in action:
+
+. Navigate to the `qtodo` route in the {ocp} Console (*Networking > Routes* in the `qtodo` namespace).
+. You will be redirected to the Keycloak login page. Log in with the credentials stored in HashiCorp Vault.
++
+To retrieve the Keycloak user credentials:
++
+.. Open the Vault UI (available via the `vault` route in the `vault` namespace).
+.. Log in to Vault using the root token (available in the `vaultkeys` secret in the `imperative` namespace).
+.. Navigate to *Secrets > hub > keycloak-users* to find the demo user credentials.
++
+[NOTE]
+====
+The `keycloak-users` Secret was removed from Kubernetes in favor of storing all credentials exclusively in Vault. This is an intentional security improvement — credentials are managed in a single, auditable location.
+====
+
+. Observe the OIDC redirect flow — the browser is redirected to Keycloak, authenticated, and then returned to the application.
+. Add and remove to-do items to verify the application works end-to-end.
+
+For a detailed technical walkthrough of the sidecar architecture and data protection workflow, see xref:/patterns/layered-zero-trust/lzt-secure-multitier.adoc[Secure Multitiered Applications].