This blueprint is designed for high-security environments where data must be transported across isolated network segments (such as a DMZ, PCI, or OT network) into a trusted core environment without compromising firewall integrity.

CVA Baseline Topology

​

This blueprint is built upon the Distributed (Multi-Worker Group) Topology. In this configuration, Worker Groups/Fleets are tiered to act as a secure relay, ensuring no direct connection exists between the untrusted Source and the internal Destination.

• Receiver Worker Group/Fleet (DMZ): Positioned in the untrusted zone. It terminates high-risk protocols (Syslog, HEC) and performs initial sanitization.
• Sender Worker Group (internal/core): Positioned in the trusted zone. It receives the sanitized data stream from the DMZ workers via a single, hardened port.
• The bridge: Data is moved using the Cribl HTTP protocol, which is optimized for high-performance, load-balanced communication between groups.

For details, see Cribl.Cloud/Hybrid (not Vanilla), Hybrid Feed to Cribl.Cloud, Worker Group to Worker Group, and Edge Fleets to Worker Groups.

Overlays

​

To manage the complexity of a secure enterprise bridge, this blueprint integrates three specific CVA overlays:

• Regional/Geo Split: Used when DMZ bridges are deployed globally. This ensures that a DMZ in Europe processes and masks PII locally before sending data to a global Hub in a different region, maintaining data sovereignty.
• Hub and Spoke: The DMZ Receiver group acts as a “Regional Hub” that collects data from multiple “Spokes” (Edge nodes or smaller sites). This centralizes the egress point through the firewall.
• Cribl Edge and Stream: This manages the hand-off between the collection tier (Edge Nodes or DMZ Worker Nodes) and the processing tier (Internal Cribl Stream Workers). It optimizes the stream for “Worker-to-Worker” efficiency.
• Worker Group to Worker Group Bridging: This is the functional “bridge.” It uses the Cribl HTTP Destination on the DMZ side and the Cribl HTTP Source on the Internal side. This creates the “Hop,” allowing for load-balanced, encrypted data transit between groups.

Operational Guardrails

​

To maintain a validated state, your deployment must adhere to the specific resilience and connectivity standards defined for your environment type.

• Hop Limits: Limit bridging to a single hop (Zone A Zone B). Do not daisy-chain Workers (A B C), as this introduces significant latency and complicates troubleshooting.
• Certificate Management: You must use a Trusted CA for mTLS certificates. Do not use self-signed certificates in production, as they cannot be reliably revoked or rotated during a security event.
• Firewall Discipline: The internal firewall must be configured to allow only the IP addresses of the DMZ Worker Nodes on the specific Cribl HTTP port. All other traffic should be denied by default.
• Leader Connectivity: Ensure the DMZ Leader (if self-managed) or the cloud connection is isolated from the data path. Configuration traffic and data traffic should never share the same unencrypted segment.
• Load Balancing: Use a Network Load Balancer (NLB) between the DMZ and Internal groups to ensure the bridge can scale horizontally and handle the failure of a single internal node.

For more considrerations, see Strategic Architectures (Bridging, Edge, and Hybrid Flow).