Use global secrets to define credentials once and reuse them across Cribl Stream and Edge by referencing them in Source, Destination, and Collector configurations. Teams that span products can use the same credentials instead of maintaining duplicate credentials that can drift out of sync. When you rotate credentials, you can update the values for global secrets in one place.

Global secrets are supported only in Cribl.Cloud.

Cribl organizes global secrets in secret folders that are backed by secret stores. Access to global secrets is controlled by sharing with Worker Groups and Edge Fleets at the folder level. Manage secret stores, secret folders, and global secrets in the UI under Global Settings > Security > Secrets or with the Cribl API.

Any legacy secrets that you use in existing resource configurations will continue to work as you migrate to global secrets.

A typical workflow for global secrets is:

1. Connect to an external provider to add a secret store (such as HashiCorp Vault) or use the built-in cribl secret store.
2. Add a secret folder and share it with Worker Groups or Edge Fleets.
3. Add global secrets to the secret folder.
4. Reference global secrets in Cribl resources that support them.
5. Commit and deploy your configuration.
6. Rotate credentials as needed in the built-in cribl secret store or an externally backed secret store.

Deployment Scope ​

In Cribl.Cloud, global secrets are scoped to a single Workspace. Workspaces in the same Organization cannot access each other’s global secrets.

The Leader persists global secrets configuration and resolves secret values. In Cribl.Cloud, this means the Leader for the Workspace. Cribl adds global secrets to deployment bundles for Worker Groups and Edge Fleets through the bundle push path. Cribl adds a global secret when its secret folder is shared with the Group or Fleet, even if no resource configuration in the Group or Fleet references the secret.

Global secrets are available only in Distributed deployments. If you run Cribl Stream in single-instance mode, use legacy secrets instead.

Secret Stores ​

Secret stores are the backing stores for the secret folders that contain global secrets. You can use the built-in cribl store or add secret stores that are backed by an external provider such as HashiCorp Vault.

The built-in cribl secret store cannot be deleted, and it persists encrypted global secret values on the Leader. To delete a secret store that is backed by an external provider, you must first delete all of its secret folders.

Cribl Stream uses cribl.secret as the primary encryption key to protect sensitive values in configuration files. It is created when the Leader starts and is stored by default at $CRIBL_HOME/local/cribl/auth/cribl.secret. Global secrets in the built-in cribl store are encrypted with this key.

When you configure an external KMS provider (HashiCorp Vault or AWS KMS) to manage cribl.secret, the key is removed from disk and managed by the KMS provider instead. This protection extends to global secrets in the built-in cribl secret store. The KMS provider configuration is separate from the global secret store. When using an external KMS, ensure that IAM permissions are correctly scoped (for example, kms:Decrypt for AWS KMS). Misconfigured permissions can prevent the Leader from starting.

Back up cribl.secret before major changes such as enabling an external KMS or rotating keys.

Secret Folders ​

Within secret stores, global secrets are organized into secret folders. Each secret folder can only belong to one secret store.

For secret folders backed by the built-in cribl secret store, Cribl persists encrypted secret values on the Leader in per-folder storage. For secret folders that are backed by external secret stores, Cribl stores metadata for folders and global secrets on the Leader and resolves secret values from the external provider at runtime.

Sharing and Access Model ​

Access to global secrets is controlled by sharing secret folders, not individual secrets. You must share secret folders with Worker Groups and Edge Fleets to grant access to the global secrets that the folders contain.

Global secrets are defined once on the Leader within the deployment scope. When you add a secret folder, you can share the folder with Worker Groups and Edge Fleets in the deployment.

Adding a Worker Group or Edge Fleet to the folder’s sharing list makes every global secret in that folder available to the Group or Fleet. If you share a secret folder with an Edge Fleet or Subfleet, its Subfleets inherit access to the global secrets in the folder. Deployment bundles include every global secret in a shared secret folder, so take care to share folders only with the Worker Groups and Edge Fleets that should have access to all of the secrets that the folder contains.

After you share a secret folder with a Worker Group or Edge Fleet, supported resources expose references to the global secrets in the folder. Within one Workspace, any Worker Group or Edge Fleet that you share the folder with can reuse the same global secret definitions.

To remove a Worker Group or Edge Fleet from a secret folder’s sharing list, first remove all references to the global secrets in the folder from resources in the Group or Fleet. This includes references used in Subfleets that will lose inherited access if you remove the parent Fleet or Subfleet from the sharing list.

Leader Restart and Externally Backed Secret Folders ​

When the Leader restarts, it reinitializes each secret store that is backed by an external provider and loads global secrets from the external provider. The Leader keeps externally backed secret values in memory only (they are not persisted on disk).

If credential values changed in the external store since the last commit and deploy, the Leader might resolve the updated values after it restarts. This does not distribute the new credentials to Worker Groups or Edge Fleets. Commit and deploy still controls when updated global secrets reach nodes. To rotate credentials through the normal workflow, see Rotate Global Secrets in Externally Backed Secret Stores.

If the Leader cannot reach the external provider when it restarts, store initialization or secret resolution can fail because it has not fetched and cached global secret values. Cribl surfaces the failure through secret store health checks as system bulletin messages. Deploy is blocked for Worker Groups and Edge Fleets that share secret folders backed by the unhealthy store until the Leader successfully resolves those secrets. You can still commit configuration changes.