On This Page

Home / Stream/ Securing/Secure your On-Prem/Hybrid Deployment

Secure Your On-Prem/Hybrid Deployment

This document outlines essential security considerations to safeguard your on-prem/hybrid Cribl deployment.

Secure Your Installation
​

Secure your Cribl Stream deployment by ensuring the following during installation.

Choose a Secure Environment
​

Protect your Cribl deployment by:

  • Isolating your deployment – deploy Cribl Stream on a dedicated network segment to minimize exposure.
  • Restricting physical access – control who can physically access the deployment hardware.

Configure a System Proxy
​

Enhance the security and reliability of your Cribl deployment by leveraging proxy servers.

  • To configure a system proxy for outbound HTTP/S traffic: Set the HTTP_PROXY and HTTPS_PROXY environment variables before starting Cribl Stream, specifying the proxy’s IP address or FQDN and optionally the port number. For details, see System Proxy Configuration.

  • To configure a SOCKS proxy for secure communication between Leader and managed Nodes: Follow the steps in Configure a SOCKS proxy. This will allow you to bypass network restrictions and ensure uninterrupted data flow.

Create a Dedicated User
​

To enhance security, avoid running Cribl Stream with root privileges. Instead, create a dedicated user account with limited permissions.

For details, see Setting Capabilities for Cribl Stream or Running Edge as an Unprivileged User.

Change Default Admin Password
​

After your initial login, immediately create a strong, unique password for the administrator account. This will help prevent unauthorized access.

Note: Worker Node passwords are managed by the Leader Node.

Locate and Access Your Cribl Secrets
​

When you install Cribl Stream, the following security files are created:

  • cribl.secret – This file stores a unique cryptographic key used for authentication, password encryption, and key encryption. It’s essential for securing your Cribl Stream deployment when authenticating with integrated services.
  • keys.json – This file contains cryptographic keys used for internal operations within Cribl Stream.

These files are stored in:

Single-instance deployment – both files are located in $CRIBL_HOME/local/cribl/auth/.

Distributed deployment – both files reside on the Leader Node, in $CRIBL_HOME/groups/<group‑name>/local/cribl/auth/.

You can use the Settings > Security > Secrets section to create and update authorization tokens, username/password combinations, and API‑key/secret‑key combinations for reuse across the application. For details, see Secrets.

Set Your Remote Git Repo to Private
​

Cribl uses Git for efficient configuration management. In Distributed deployments, a local Git repository tracks configuration changes. For added security and disaster recovery, you can also connect to a remote Git repository. Here are some key considerations.

  • Private repositories – Always ensure that your remote Git repository is private, to prevent unauthorized access to your configuration files.
  • Disaster recovery – Remote repositories provide a valuable backup for your Cribl configuration in case of system failures or data loss.

FIPS Mode (Cribl Stream only)
​

Do not start Cribl Stream without FIPS mode enabled, or else you will be unable to run it in FIPS mode later. You must enable FIPS mode as described in the FIPS Mode document, after installing but before starting Cribl Stream.

Secure the Leader Auth Token
​

Cribl Stream generates a strong, random authentication token for new installations and when transitioning from Single-instance to Distributed mode.

If you need to change the default token:

  • Create a unique, secure value.
  • Update the token in the UI or Docker Compose file.

For details, see How to Secure the Auth Token for the Leader Node.

Set up Role-Based Access Control for Members
​

Cribl offers detailed role-based access control (RBAC) to ensure appropriate permissions and security. For details on how to define and manage fine-grained access control across Cribl products and resources, see Members and Permissions.

Enhance Security with an Identity Provider (IDP)
​

We strongly recommend using an external Identity Provider (IDP) to implement single sign-on (SSO) for Cribl. This enhances your organization’s security, by centralizing user authentication and authorization.

For details, see:

Secure Your Communication
​

Secure your Cribl communication channels by using the following options.

  • SSL/TLS – Encrypt Cribl access and traffic with SSL or TLS.
  • Custom headers – Enhance security with custom HTTP headers.
  • Encryption – Create and manage your own keys to encrypt events in real time.
  • Secrets – Centrally manage secrets that your instances use to authenticate on integrated services.
  • KMS – Use internal or external key management service for advanced key management.

Choose a combination that best aligns with your organization’s security policies.

Secure Access to the Leader and Worker Nodes
​

You can secure access to the Cribl Edge API and UI by configuring Secure Sockets Layer (SSL) or Transport Layer Security (TLS). Do this on the Leader, to secure inbound communications to the Edge Nodes. You can use your own certs and private keys, or you can generate a pair with OpenSSL. For details, see Configure TLS for API and UI Access.

For TLS details, see the following:

Import an Existing Certificate and Key
​

You can secure Leader-to-Worker Node communications by using an existing TLS/SSL certificate and key, in \.pem\ format. For details, see Import Certificate and Key.

Create a Self-signed Certificate
​

You also have the option to create a self-signed certificate and key by following the steps outlined in Configure SSL.

Connect to the Leader Securely
​

Configure secure communication between your Leader and Edge Nodes using either the user interface, the instance.yml configuration file, or environment variables. For details, see Secure Leader/Worker Nodes Communications.

Secure Access to the Worker/Edge Nodes UI
​

Cribl recommends that in Enterprise Distributed deployments, you prevent direct browser access to the UI for all Worker Nodes. For details, see Secure Access to Worker Node UIs.

Configure TLS Mutual Authentication (optional)
​

Implement client certificate exchange to enhance security by allowing only authorized clients with valid certificates to connect to the Leader. Configure this feature after setting up encrypted TLS communication. For details, see Configuring TLS Mutual Authentication.

Secure Communication Between Sources and Destinations
​

To authenticate Cribl Stream with external data senders and receivers, configure certificates at the Worker Group level. For details, see Secure Cribl Stream Sources and Destinations with Certificates.

Configure Custom HTTP Headers
​

Custom HTTP headers are metadata that can be sent along with HTTP requests and responses. They provide a way to convey extra data that is not part of the standard HTTP protocol. You can customize Cribl’s security settings with custom HTTP headers. For details, see Custom HTTP Headers.

Create Encryption Keys
​

You can create and manage keys that Cribl Stream will use for real-time encryption of fields and patterns within events. For details, see:

Configure a Key Management Service (KMS)
​

Cribl offers a built-in Key Management Service (KMS) that strengthens the security of your data. With certain license tiers, you have the option to integrate an external KMS. A KMS securely manages the encryption keys used to protect sensitive information on Worker Groups and Worker Nodes within Cribl Stream.

For details, see Configure KMS.

Create Secrets
​

Use the Cribl secrets store to isolate and simplify the management of authentication tokens, usernames/passwords, and API keys.

Secure Data at Rest
​

You are solely responsible for implementing encryption for data at rest on systems hosting Cribl products. To secure data at rest, consider:

  • Filesystem-level encryption: Encrypting the entire file system where Cribl data resides.
  • Hardware-level encryption: Using self-encrypting drives (SEDs) or other hardware-based encryption mechanisms.

Secure Data in Motion
​

For an extra layer of protection, consider encrypting your data while it travels between Cribl Stream and your data Sources and Destinations. For details, see Data Encryption.

Currently, Cribl Stream supports decryption only when Splunk is the end system. For details, see Data Decryption.

For a comprehensive solution, we recommend configuring TLS. TLS encrypts the entire data stream, including all event fields, regardless of Source or Destination type. This provides a more robust security posture for your data in motion. For details, see Secure Cribl Stream Sources and Destinations with Certificates.

Disable the Exec Source
​

The Exec Source, while powerful, can pose security risks if not configured and used carefully. To mitigate these risks, you can disable the Exec source by setting the CRIBL_NOEXEC environment variable. This prevents the execution of arbitrary commands, reducing the attack surface. For details, see Disable the Exec Source.

Filter Sensitive Information in API Responses
​

Use the sensitiveFields configuration property to filter sensitive information in the responses to API requests to /inputs and /outputs endpoints. Add an array that lists the attributes you want to filter under sensitiveFields in the api section of your cribl.yml configuration file, as shown in this example:

Example sensitiveFields array in cribl.yml
api:
  host: 0.0.0.0
  port: 9000
  sensitiveFields:
    - awsApiKey
    - awsSecret
    - token
    - password
  retryCount: 120
  ...

In the responses for /inputs and /outputs endpoints, Cribl returns empty values ('') for the attributes you list in the sensitiveFields array. In this example, Cribl will return empty values for the attributes awsApiKey, awsSecret, token, and password.

Use caution: the sensitiveFields configuration property affects UI workflows and applications that rely on the responses to /inputs and /outputs endpoints. The responses will contain empty values ('') instead of plaintext values for the attributes that you list in the sensitiveFields array. When you change or update a Source or Destination, you must also re-enter the correct value for any attribute that is listed in the sensitiveFields array.

Refer to the API reference for more information about the /inputs and /outputs endpoints and the attributes that appear in their responses.