Zscaler Cloud NSS with Cribl Stream

What the source collects

The Zscaler Cloud NSS Source in Cribl Stream receives log data over HTTP/S from Zscaler Cloud Nanolog Streaming Service (NSS), as documented in the Zscaler Cloud NSS source page. That page classifies the source as a Push source with TLS support and Event Breaker support, and it accepts gzip-compressed inbound data when the Content-Encoding: gzip connection header is set.

If the logs are coming from a Zscaler NSS Virtual Machine, the page points to a Syslog Source over TCP instead.

Events from this source carry a set of internal, or meta, fields that are not part of the event itself but that Cribl Stream Functions can use to make processing decisions. The fields for this source are __headers (added only when Advanced Settings, Capture request headers, is toggled on), __hecToken, __inputId, __ctrlFields, __srcIpPort, and __TZ. The __srcIpPort field's value contains the IP address and, optionally, the port of the Zscaler Cloud NSS sending data to this source.

When any proxies, including load balancers, lie between Zscaler Cloud NSS and the source, the last proxy adds an X-Forwarded-For header whose value is the IP/port of the original client. With multiple proxies, that header's value becomes an array, whose first item is the original client IP/port. The Advanced Settings section says to toggle Show originating IP on when clients are connecting through a proxy that supports X-Forwarded-For, so the event keeps the client's original IP address instead of the proxy's IP address. The page's __srcIpPort section states the override as: when X-Forwarded-For is present and the Show originating IP toggle is off, the header's original client IP/port overrides __srcIpPort, and when the toggle is on, the header's contents do not override the __srcIpPort value.

Setting up the source

The configuration has two sides. On the Zscaler side, when adding a Zscaler Cloud NSS feed to your Zscaler environment, the source page documents the API URL and HTTP Headers settings:

• API URL: The URL varies depending on your Cribl environment, so use the same port and HEC endpoint that you define in the Zscaler Cloud NSS Source in Cribl Stream. In Cribl.Cloud, enter the Workspace Public Ingress Address in the format https://<groupName>.<workspaceName>.<organizationId>.cribl.cloud:<port><hec-endpoint>. On-prem, enter the IP address or FQDN for your Cribl Stream instance, or the load balancer you are using with your Cribl Stream instances.
• HTTP Headers: Key 1 is Authorization, and Value 1 is the Auth Token from your Cribl Source. Key 2 is Content-Encoding, and Value 2 is gzip.

On the Cribl side, select Products and then Cribl Stream from the top bar. Under Worker Groups, select a Worker Group. The page gives two paths: via QuickConnect, navigate to Routing > QuickConnect (Stream) or Collect (Edge), select Add Source, and pick Select Existing or Add New from the source list; via Routes, select Data > Sources (Stream) or More > Sources (Edge), choose the source, then select Add Source.

Under General Settings, enter an Input ID, a unique name that identifies this source definition; if you clone the source, Cribl Stream adds -CLONE to the original Input ID, and an optional Description. The next three settings configure where the source listens for incoming HTTP(S) data: Address, the hostname or IP, such as localhost or 0.0.0.0, with IPv4 and IPv6 support; Port, the network port; and HEC endpoint, the absolute path, which defaults to /services/collector.

Under Optional Settings, Allowed Indexes lists the values allowed in the HEC event index field, allows wildcards, and skips validation when left blank. Zscaler HEC Acks controls whether the source responds with a 200 HTTP status code acknowledging receipt of the ACK request; toggled off, which is the default, the source responds with a 400 code to indicate ACK processing is disabled. Tags are optional tags for filtering and grouping sources in the Cribl Stream UI; these tags are not added to processed events, and you separate the arbitrary tag names with a tab or hard return.

Next, create an Auth Token, the token you will provide to Zscaler in an HTTP header with the key Authorization. The Auth Tokens section provides the authentication token required to access the source's data and warns that not providing a token allows unauthorized access. The authentication method is either a manually entered token or a stored Secret: with manual entry, type the token directly or Generate a new one, or use the secrets store to select a stored Token (text secret) or Create a new one. The Enable token toggle controls the token status; toggled off, the token is disabled, skipped and ignored during initialization, and any client attempting to use a disabled token is not granted access. The page notes disabling is helpful when you need to temporarily stop receiving data from a particular service or application without completely deleting the token. Per-token Allowed indexes optionally restrict which indexes are permissible for events ingested using that token, and per-token Fields add Name/Value pairs to events referencing that token, evaluated and applied before any fields in the Processing Fields section.

Optionally, enable server-side TLS (certificate selection, certificate and private key paths, passphrase, mutual authentication, and minimum and maximum TLS versions), configure the persistent queue, the Processing settings (Eval-like Fields plus a single Pre-Processing pipeline), and the Advanced settings (including CORS, IP allowlist and denylist, request and socket limits, timeouts, and per-token request metrics). Then select Save, and Commit & Deploy.

What the docs flag

• The Auth Tokens section warns that not providing a token allows unauthorized access.
• Zscaler HEC Acks is toggled off by default, so the source responds to ACK requests with a 400 code unless you toggle it on.
• With Capture request headers enabled, the source writes inbound headers to __headers, and some Destinations also read __headers for outbound behavior: HTTP Destinations such as Webhook, Loki, Microsoft Sentinel, Dynatrace HTTP, and Cortex XSIAM use it to inject dynamic request headers, and Kafka Destinations use it for message headers. The fields can interfere silently; events can leave Cribl Stream with Source, Route, and Destination metrics looking healthy while data does not arrive or is rejected downstream, with Destination logs showing no errors or TLS certificate or hostname validation failures, or authentication errors such as invalid audience. The documented remedy is an Eval Function in a Pipeline that removes __headers before the Destination, or copies it to another field name first and then removes __headers, because the Rename Function cannot operate on fields whose names begin with __.
• The CORS allowed origins and CORS allowed headers settings are needed only when you want JavaScript code running in a web browser to send events to the source.
• On Cribl-managed Cloud Workers with an Enterprise plan, the persistent queue tab exposes only the Enable persistent queue toggle; when enabled, PQ is automatically configured in Always On mode with a maximum queue size of 1 GB of disk space per PQ-enabled Source, per Worker Process, that limit is on uncompressed inbound data, and it is not configurable. All other persistent queue settings apply to on-prem and hybrid deployments only.
• In Cribl Stream 4.1 and newer, the Source persistent queue default Mode is Always On. Smart mode is deprecated for Source persistent queue on hybrid and on-prem deployments, and in January 2027, affected configurations will automatically migrate to Always On mode.
• The Buffer size limit (bytes) setting replaces the deprecated Buffer size limit (events) setting as of Cribl Stream 4.18.0, and for upgraded Worker Groups and Fleets the new byte-based limit defaults to 1MB.
• Cribl Stream emits metrics about incoming requests only when Emit per-token request metrics in Advanced Settings is enabled. The metrics are counter-type, so they are not emitted when the value is zero, and if no tokens are configured, only summary metrics are emitted.

Frequently asked questions

What does the Cribl Stream Zscaler Cloud NSS Source collect?

It receives log data over HTTP/S from Zscaler Cloud Nanolog Streaming Service (NSS). It is a Push source with TLS support and Event Breaker support, and it accepts gzip-compressed inbound data when the Content-Encoding: gzip connection header is set.

Where does the Zscaler feed configuration place the Cribl Stream auth token?

It is entered as Value 1 for the Authorization key in the feed HTTP Headers, with the Auth Token from the Cribl Source as the value. The feed carries a second header as well, Content-Encoding as Key 2 with gzip as Value 2.

How does the Cribl Stream Zscaler Cloud NSS Source respond to ACK requests by default?

The Zscaler HEC Acks setting is toggled off by default, so the Source responds to the ACK request with a 400 code to indicate ACK processing is disabled. Toggled on, it responds with a 200 HTTP status code acknowledging receipt of the ACK request.

What happens when you disable an auth token on the Zscaler Cloud NSS Source?

The token is skipped and ignored during initialization, so any client attempting to use a disabled token will not be granted access. The docs present this as a way to temporarily stop receiving data from a particular service or application without deleting the token.