Egress design dictates how Cribl components communicate with external Destinations (such as SIEMs, observability platforms, object stores) and how hybrid components bridge corporate firewall boundaries. This section outlines IP behavior, Fully Qualified Domain Name (FQDN) usage, and firewall patterns for on-prem, Cribl.Cloud, and hybrid deployments.

On-Prem Egress Patterns

​

In typical on-prem setups, Worker and Edge Nodes are usually situated behind a firewall or a Network Address Translation (NAT) gateway. A NAT gateway masks internal private IP addresses with a single public IP for outgoing traffic.

Since these egress IPs remain constant over time, implementing IP-based access control lists (ACLs) is highly effective and easy to maintain. However, even with this stability, you should still enforce a “least privilege” model, opening only essential ports, to ensure the network remains secure yet adaptable to future infrastructure shifts.

Firewall Policy Guidelines

​

The following firewall policy guidelines outline the preferred methods for managing traffic between Cribl components and external Destinations. These policies are designed to minimize administrative overhead while adhering to a “Zero Trust” security posture.

Adopt an FQDN-First Strategy

​

Wherever supported by the network infrastructure, implement FQDN allow-lists for outbound traffic originating from Worker and Edge Nodes. Cloud-native Destinations (such as Splunk Cloud or AWS S3) often use dynamic IP addressing, FQDN-based filtering ensures that connectivity remains uninterrupted even when upstream service IPs change.

Formalize Static IP Fallback

​

In scenarios where legacy network hardware does not support FQDN filtering, the use of static or slowly-rotating IP address allow-lists is an acceptable alternative. However, these exceptions must be explicitly documented in the network inventory and undergo periodic reviews to ensure the IPs remain valid and necessary.

Enforce Strict Traffic Scoping

​

To reduce the attack surface, outbound traffic must be strictly scoped to the minimum required access levels. This includes:

• Destination restriction: Limiting access specifically to the FQDNs or CIDR ranges of the configured Destinations.
• Port-Level security: Restricting communication to required service ports only, typically TCP/443 for HTTPS-based ingest or specific Kafka broker ports, rather than allowing broad outbound access.

Secure Internal (On-Prem) Destinations

​

For traffic directed toward internal resources, such as on-prem Kafka clusters or Splunk Indexers, apply least-privilege rules at the internal firewall or Virtual Routing and Forwarding (VRF) layers. Harden configurations to ensure that only authorized source subnets can communicate with specific Destination Virtual IPs (VIPs).

For details, see On-Prem Architecture Planning.

Cribl.Cloud Egress Patterns

​

In a Cribl.Cloud environment, you must account for a fundamental shift in how network identity is handled compared to traditional on-premis setups. While your Worker Groups provide stable Ingress FQDNs for receiving data, you should understand that egress IP addresses are dynamic by design. These IPs change as the platform scales to meet your data demands or rebalances for peak performance. You should never architect your security or routing policies under the assumption that egress IPs will remain static.

For a port-by-port view of Cribl.Cloud connectivity and hybrid communication patterns, see Required Ports in Cribl.Cloud.

Operational Requirements for Cribl.Cloud Egress

​

To ensure consistent data flow and secure connectivity, use these guidelines to manage communication between Cribl.Cloud and your various internal and external Destinations.

Manage Egress IPs as Dynamic Metadata

​

You must treat egress IPs as volatile metadata rather than fixed infrastructure. Cribl provides the current set of egress IPs for each specific Worker Group directly within the Cribl.Cloud UI. Ensure your operations team monitors these values, as they represent the “source of truth” for any firewall or access control list (ACL) updates.

Adopt an FQDN-First Strategy

​

Whenever possible, you should permit outbound access using FQDNs rather than IP addresses. This strategy is critical when your Destinations are SaaS platforms (such as AWS S3, Snowflake, or Azure) where the Destination IPs are also dynamic. Using FQDNs removes the “double-ended” risk of both the Source and Destination IPs changing simultaneously.

Formalize IP Allow-Listing Procedures

​

If your Destination, such as a legacy SIEM or a restricted third-party API, strictly requires IP-based allow-listing, you should implement the following safeguards:

• Automated retrieval: Use the Cribl API or UI to programmatically fetch the latest egress IP sets. This reduces human error and ensures your firewall or proxy rules remain synchronized with the cloud environment.
• Change management: Coordinate these IP refreshes within established change windows to prevent unexpected “silent drops” or data gaps during platform scaling events.

Secure Cribl.Cloud to On-Prem Connectivity

​

When you route data from Cribl.Cloud back to internal services via a VPN or AWS PrivateLink, you must manage these flows with heightened scrutiny:

• Inbound permissions: Configure your internal security perimeter to allow inbound traffic specifically from the current Cribl.Cloud egress IP set.
• Semi-trusted zones: Treat these incoming data flows as “semi-trusted.” Even though the data originates from your Cribl instance, you should apply Intrusion Detection/Prevention Systems (IDS/IPS) inspection and ensure your security logging clearly distinguishes this cloud-originated traffic from purely internal network lateral movement.

For details, see Cribl.Cloud Architecture Planning and Manage Cribl.Cloud Worker Groups.

Hybrid Egress Patterns

​

When you move into a hybrid architecture, you’re essentially bridging your private infrastructure with Cribl.Cloud. This requires a more nuanced approach than a standard on-prem setup because your traffic now flows across different trust zones.

Connecting Your Local Nodes to Cribl.Cloud

​

For your hybrid environment to function, your internal Worker/Edge Nodes must be able to communicate with Cribl.Cloud. You need to ensure your Worker and Edge Nodes can reach the Cribl.Cloud Leader (for management) and the Worker Group ingress address (for data).

• Firewall requirements: You must explicitly allow outbound traffic on TCP/TLS 4200 and HTTPS 443.
• Performance optimization: Ensure these connections pass through your approved egress paths, such as proxies or inspection zones, without adding significant latency. High latency here can directly degrade your streaming performance and data throughput.

Routing Cribl.Cloud Data to External Destinations

​

When data flows out of Cribl.Cloud toward a third-party SaaS or back to your private services, the traffic is governed by a dynamic egress IP set.

• FQDN preference: Always prefer FQDN-based allow-lists for your SaaS Destinations. This is the most practical and resilient method.
• Mandatory IP rules: If your on-prem firewalls or specific SaaS tenants require IP-based rules, you must maintain a documented procedure to update these entries whenever the Cribl.Cloud egress IP set changes.

Routing Rules for Sensitive and Regulated Data

​

To stay compliant with regulations like GDPR or HIPAA, you should categorize and document your egress based on the sensitivity of the data being moved:

• Security telemetry: You may need to “region-pin” this data to specific Destinations to meet residency requirements. This often requires strict IP or FQDN controls to prevent data from leaving a specific geographic boundary.
• Observability data: For general metrics and application logs, you can often use broader FQDN rules or multi-region Destinations. This provides more flexibility and is typically more cost-effective for long-term archiving.

For details, see Hybrid Deployment Architecture Planning.