The bundler object in cribl.yml allows you to deploy files to GitOps that are usually excluded via .gitignore, like cribl.secret and secrets.yml. This facilitates loading custom secrets per environment and Worker Group.

Files listed in the bundler object are deployed, but they are never committed to GitOps. You must implement your own logic (outside GitOps) to place the correct secret files for each environment and Worker Group prior to deployment to ensure that the correct secrets are present. This approach safeguards sensitive information while leveraging the bundler functionality within your GitOps workflow.

To leverage this functionality for deployment-critical files, configure the Leader’s cribl.yml file located at $CRIBL_HOME/local/cribl/cribl.yml using the bundler.bundleGitIgnoredPatterns setting. This ensures essential files reach Workers, even if they are not tracked with version control due to customer-specific .gitignore rules. It is not necessary to restart the Leader after editing the Leader’s cribl.yml file.

Example: Use .gitignore with bundler ​

To exclude all Cribl secrets from Git, in .gitignore, enter local/cribl/auth/cribl.secret to exclude the Leader’s cribl.secret file as well as the glob pattern **/local/cribl/auth/cribl.secret to exclude all cribl.secret files located in the local/cribl/auth subdirectory of any Worker Group within the groups directory, regardless of the groupName.

# Exclude Leader's cribl.secret
local/cribl/auth/cribl.secret

# Exclude cribl.secret for all Worker Groups
**/local/cribl/auth/cribl.secret

To exclude only a specific Worker Group’s cribl.secret file, use groups/{groupName}/local/cribl/auth/cribl.secret to .gitignore instead of **/local/cribl/auth/cribl.secret.

In bundler.bundleGitIgnoredPatterns, add local/cribl/auth/cribl.secret to ensure that the cribl.secret file is included in the config bundle during deployment without being included in version control. Patterns in bundler.bundleGitIgnoredPatterns are evaluated with a base directory of $CRIBL_HOME/groups/<group>. The bundler does not require the Leader’s cribl.secret.

bundler:
  bundleGitIgnoredPatterns:
    - 'local/cribl/auth/cribl.secret'

If you want to avoid tracking custom certificates as well, use the path for the directory in which the secrets/certificates reside: local/cribl/auth.

bundler:
  bundleGitIgnoredPatterns:
    - 'local/cribl/auth'

CRIBL Section ​

Do Not Remove CRIBL SECTION or CUSTOM SECTION Headers ​

Under the CRIBL SECTION header, Cribl Stream specifies the files that Git will ignore by default. Further files for Git to ignore should be listed under the CUSTOM SECTION header.

Do not add any lines to the CRIBL SECTION block, because the next update will just overwrite them anyway. The only modifications that will survive updates are commented lines.

Do not remove any section header lines, or unexpected behavior might occur on update.

CUSTOM Section ​

User-defined, custom patterns/rules can be safely defined under the CUSTOM SECTION. Cribl Stream will not modify the contents of CUSTOM SECTION.

Good candidates to add here include large lookup files - especially large binary database files. For details, see Git Push Errors: Large Files Detected.

Files Skipped with .gitignore ​

If you have files that you’ve set .gitignore to skip, you will need to back them up and restore them by means other than Git. For example, you can periodically copy/rsync them to a backup destination, and then restore them to their original locations after you complete the steps above.

Files specified in .gitignore are not only excluded from pushes to the remote repo, but are also excluded from Worker Group config bundles. When Workers load a new config that references a skipped (and missing) file, this can produce unexpected results, and usually errors.

For example, if you add **/auth/certs/leader* to .gitignore, this will prevent the leader.crt and leader.key files from leaking to Workers in config deployments.

Configs that you .gitignore in this way on the Leader will not persist on Workers after they receive their next deploy. However, these configs will be available in the next few rolling backup bundles in state/.