Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
43 changes: 42 additions & 1 deletion content/patterns/layered-zero-trust/_index.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -108,8 +108,20 @@ The pattern consists of the following key components:
* link:https://docs.redhat.com/es/documentation/red_hat_trusted_profile_analyzer/2.2[Red{nbsp}Hat Trusted Profile Analyzer (RHTPA)]
** Provides the storage and management means for _Software Bill of Materials_ (SBOMs), with cross-referencing capabilities between SBOMs and CVEs/Security Advisories.

[id="architecture-diagram"]
==== Architecture diagram

The layered zero trust architecture enforces a Zero Trust model through four decoupled layers:

* *Identity*: Keycloak manages user authentication, while SPIRE assigns short-lived, cryptographic identities to workloads for secure service-to-service recognition.
* *Secure Transport*: Sidecar proxies intercept traffic to enforce mutual TLS (mTLS), ensuring all communication is encrypted and mutually authenticated without application code changes.
* *Secrets*: Vault centrally stores sensitive data, which is securely synced into the cluster by the External Secrets Operator only when needed.
* *Compliance*: RHACM and the Compliance Operator monitor the environment to ensure consistent policy enforcement and infrastructure hardening.

image::layered-zero-trust/layered-zero-trust-architecture-diagram.png[Layered Zero Trust architecture diagram]

[id="sidecar-pattern"]
==== Sidecar pattern
=== Sidecar pattern

The sidecar pattern is a deployment model where a separate container or process, known as a sidecar, 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.
Expand All @@ -126,6 +138,35 @@ The Layered Zero Trust pattern uses the sidecar approach to offload critical sec
This centralizes policy enforcement, simplifies development, and separates security concerns.
The sidecar patterns in this approach handle tasks such as authentication and authorization, traffic encryption, rate limiting, and auditing and logging.

[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, matching the numbered markers in the schematic:

* *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="about-technology"]
== About the technology

Expand Down
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.