Cribl Validated Architectures (CVA) operate on the principle of least-privilege access. These guardrails ensure that firewalls, security appliances, and Network Access Control Lists (ACLs) strictly regulate traffic around Leaders, Worker/Edge Nodes, Sources, and Destinations across both customer-managed and Cribl.Cloud deployments.

On-Prem Security Controls

​

In customer-managed environments, network segmentation is critical for protecting the control plane and data Pipeline.

Least-Privilege Connectivity

​

To maintain a secure posture, firewall rules should be scoped to the specific roles of each Node, ensuring that only validated traffic traverses the cluster.

• Sources to Worker Nodes: Restrict inbound traffic to Worker Group Virtual IPs (VIP) or Nodes to specific data ports based on your active Sources.
• Worker Nodes to Leader: Allow outbound communication from Workers to the Leader Node to facilitate management and configuration.
• Worker/Edge Nodes to Destinations: Allow outbound traffic from Workers only to documented Destination ports.

For details, see Ports.

TLS and mTLS Requirements

​

Enforce TLS 1.2+ for any traffic traversing DMZs, partner networks, or untrusted segments.

• Control plane: Use TLS for the Leader UI/API (9000/443) and Worker-to-Leader communication (4200/TCP) where networks are segmented.
• Data plane: Secure any Source or Destination that crosses DMZs or untrusted network segments.
• Mutual TLS (mTLS): Implement mTLS for sensitive data flows (such as security telemetry from high-risk zones), or where corporate policy mandates strong client authentication.

For details, see Securing On-Prem and Hybrid Deployments.

Traffic Optimization and Inspection

​

Configure your network infrastructure according to these traffic optimization and inspection standards to prevent connection bottlenecks and resource exhaustion.

• Idle timeouts: Set your proxies and load balancers with sensible timeouts specifically for long-lived TCP flows. You should aim for a balance; avoid aggressive timeouts that cause disruptive connection resets, but ensure you don’t allow infinite timeouts, which can lead to a buildup of “zombie” connections that waste system memory.
• Capacity planning: Size your connection-tracking (conntrack) tables and file descriptor limits to handle more than just your average daily traffic. Your configuration should account for peak loads and the sudden bursts of data that occur during failover events to ensure the system doesn’t drop packets when you need it most.
• Implement DPI and IPS exclusions: To maintain system stability, exclude Cribl data and control-plane streams from Deep Packet Inspection (DPI) and Intrusion Prevention Systems (IPS). Because these streams are often high-volume, intrusive security signatures can lead to performance instability and excessive CPU consumption on your security appliances.
• Comprehensive performance monitoring: Beyond basic uptime, you should actively monitor for specific resource constraints. Track indicators like conntrack exhaustion, “Too many open files” errors, and backpressure signals from both Sources and Destinations to identify and resolve flow issues before they impact your data integrity.

Cribl.Cloud Security Controls

​

In Cribl.Cloud architectures, Cribl manages the Leader and Cloud Worker Groups within isolated Virtual Private Clouds (VPCs). While Cribl secures the cloud-side infrastructure, you maintain control over the network policy at your enterprise boundary.

Managed Connectivity and Traffic Flow

​

All communication between customer networks and Cribl.Cloud is TLS-encrypted by default, using certificates from trusted public CAs. For heightened security, you can implement optional mTLS where supported. For details, see Securing Cribl.Cloud with TLS and Mutual TLS.

Treat the Cribl.Cloud UI as the source of truth for ingress addresses and egress characteristics. Mirror these values directly into your enterprise firewalls to prevent configuration drift.

Outbound Configuration (Hybrid/Cribl Edge)

​

Ensure on-prem Worker/Edge Nodes can reach Cribl.Cloud endpoints via Fully Qualified Domain Name (FQDN) rather than static IPs, as Cribl.Cloud endpoints are dynamic. This includes access to:

• Cribl.Cloud Leader: For UI, API, bootstrapping, and control-plane heartbeats.
• Cribl CDN/S3: For retrieving configuration bundles and updates.
• AI Services: For integrated Copilot features.

For details, see Required Ports in Cribl.Cloud.

Inbound Posture

​

To minimize the attack surface, inbound access is strictly controlled and follows a “deny-by-default” posture for both local and cloud-managed infrastructure.

• On-Prem: Do not allow arbitrary inbound Internet traffic to on-prem components.
• Cloud-Managed: Public ingress to Cribl-managed Worker Groups is restricted to a specific port range (20000-20010). Use the published ingest FQDNs found in your Workspace as the authoritative source for firewall rules.
• Private connectivity: When Cribl.Cloud must communicate with on-prem or private endpoints, prioritize the use of VPN, PrivateLink, or secure gateways. Restrict inbound firewall rules to the specific egress IPs or gateway endpoints provided by Cribl.Cloud to prevent configuration drift.

For details, see Secure Your Cribl.Cloud Deployment.

Hybrid Security Posture

​

In a hybrid deployment, treat your on-prem environment, customer-managed cloud, and the Cribl.Cloud infrastructure as distinct security zones, each separated by explicit trust boundaries. Managing these boundaries ensures that data flows remain secure even as they cross between managed and unmanaged networks.

Security Zones and Traffic Definition

​

To maintain a hardened environment, define the specific characteristics of every communication path within the Pipeline.

• Zone segmentation: On-prem infrastructure should be strategically isolated within internal zones or DMZs. Cribl-managed Worker Groups must be treated as a dedicated, vendor-managed cloud zone, accessible only through strictly defined ports and protocols.
• Per-Path definition: For every data path (such as traffic moving from a Cribl Edge node to an on-prem Cribl Stream instance, or from Cribl Stream to Cribl Lake), you must explicitly document the authentication method, the minimum encryption standard (TLS 1.2+), and the corresponding firewall or Network Security Group (NSG) rules.
• Control plane reliability: Maintaining a persistent connection on port 4200/TCP is vital for cluster health. If your network architecture requires a proxy for this traffic, use a SOCKS (Layer 4) proxy. Standard HTTP proxies are incompatible with the raw TCP streams required for Cribl cluster communication. For details, see Configure SOCKS Proxy.

Operational Lifecycle and Health Monitoring

​

A secure posture requires ongoing maintenance and validation. Incorporate the following checks into your operational runbooks to prevent service degradation or security gaps.

• Certificate management: Implement proactive monitoring for the expiration of both server and client-side certificates to avoid sudden ingestion or management outages.
• Network diagnostics: Regularly audit long-lived data flows for signs of instability, specifically watching for high rates of connection resets or TCP retransmits which can indicate firewall or transmission issues.
• Appliance validation: Periodically confirm that DPI or IPS (such as Palo Alto or Fortinet devices) are not inadvertently intercepting, decrypting, or downgrading TLS traffic on critical management ports like 4200.