Worker Group to Worker Group bridging is a core data movement overlay used to route data between separate Worker Groups, typically to cross security, trust, or organizational boundaries. This overlay establishes a clear, formal data-sharing interface.

Common Patterns

​

The primary use cases and examples of bridging are:

• DMZ ingest: A Worker Group in the DMZ terminates raw Sources (acts as the final Destination), applies filtering and masking, and forwards only sanitized events to an internal Core Worker Group.

• Regional to Central: Regional Worker Groups process local data and forward curated summaries or subsets into a central Core Worker Group for global analytics.

• Other boundaries: Used to separate traffic between zones, such as operations to IT or vendor to internal networks.

Benefits

​

• Enforce boundaries: Establishes clear, formal interfaces to separate traffic between zones, ensuring security and trust boundaries are strictly respected.

• Achieve independent scaling: Allows Worker Groups on each side of the bridge to scale and operate independently without directly impacting the other.

• Compression and egress size: Data ingested by one Worker Group can be compressed when sent to another Worker Group, resulting in smaller data size on the wire and reduced egress costs.

• Billing efficiency: Data ingest is only billed once, where the data first enters the Cribl deployment.

Design Notes

​

Bridging endpoints should be treated as formal internal APIs due to the security boundaries they cross.

• Protocol & hop: Uses Cribl HTTP or Cribl TCP Destination to Source pairs configured between the Worker Groups. Bridging should maintain a single logical hop across the boundary to minimize complexity. This minimizes processing latency, reduces complexity for troubleshooting, and avoids increasing the failure domain of the data path. Cribl HTTP is generally preferred for its compatibility with load balancers and better horizontal distribution across Worker Processes.

• Avoid chains: Instead of creating a complex chain (for example, Worker Group A sends to B, which sends to C), data should move directly from the Source-facing Worker Group (such as DMZ) to its immediate downstream consumer (such as Core). This prevents increased latency and points of failure.

• Schema agreements: Define a stable, versioned “interop schema” for each connection, documenting required fields and canonical formats.

• Security & PII: Apply PII masking, tokenization, or redaction in the Source-facing Worker Group so that only compliant data crosses the boundary.

• Firewall rules: Use mTLS (Mutual TLS) on Cribl HTTP/TCP when crossing trust boundaries and apply strict, least-privilege firewall rules.