On This Page

Home / Edge/ Secure Your Deployment/ Centralize and Reuse Global Secrets/Connect HashiCorp Vault Secret Stores

Connect HashiCorp Vault Secret Stores

Global secrets are supported only in Cribl.Cloud.

Configure a secret store that is backed by HashiCorp Vault to retrieve global secrets from the KV v2 secrets engine. The KV v1 secret engine is not supported.

  1. In Global Settings > Security > Secret Stores, select Add Secret Store.

  2. In the New Secret Store modal, configure the store using the following fields:

    • Store name: Unique identifier for the secret store.

    • Description: Brief description of the secret store (optional).

    • Vault URL: URL where your HashiCorp Vault instance is running (for example, https://vault.example.com:8200).

    • Namespace: Full path to the HashiCorp Vault Enterprise namespace where Cribl should retrieve global secrets. Enter the full path from the root namespace, not only the leaf segment (such as admin/engineering/sre for HashiCorp Cloud Platform (HCP) Vault or root/engineering/sre for on-prem Vault). Omit if you do not use Vault namespaces.

      • HashiCorp Vault Enterprise namespaces are isolated and do not inherit authentication configurations from parent namespaces. If you store secrets in more than one Vault namespace, add a separate Vault-backed secret store in Cribl for each namespace.

      • In each namespace, your Vault administrator must configure an authentication method and policies that allow Cribl to authenticate and read the paths that you provide when you add a global secret.

      • When you add a global secret, Cribl validates each path against the namespace you provide. If HashiCorp Vault does not have a secret at the specified path (for example, because the secret is in a different namespace), Cribl will not add the global secret.

    • Mount: Mount point of the HashiCorp Vault KV v2 secrets engine to retrieve global secrets from. Default is secret. The KV v1 secrets engine is not supported.

    • Authentication > Authentication provider: Provider to use for authenticating to HashiCorp Vault.

      • Token: In the Token field, enter your HashiCorp Vault authentication token.

      • AWS IAM:

        • Authentication method: Select Auto or Manual.
          • Auto: Use credentials from the environment. Cribl authenticates to HashiCorp Vault from the Workspace Leader using the Leader’s attached IAM role or AWS environment variables.
          • Manual: Use static credentials. Enter your Access key and Secret key credentials.
        • Vault AWS IAM Server ID: Value for the X-Vault-AWS-IAM-Server-ID header. Must match the value configured for IAM authentication on your HashiCorp Vault server.
        • Vault role: Name of the role configured in the HashiCorp Vault AWS auth method that grants Cribl access to secrets stored in Vault.
          • If you provided the path to a HashiCorp Vault Enterprise namespace in the Namespace field, this role must be configured in the same namespace. Namespaces do not inherit authentication configurations from parent namespaces.
        • Custom authentication path: Auth method mount path in HashiCorp Vault, if different from the default aws (optional).
        • AssumeRole > Enable for Vault Auth: Toggle on to assume a different IAM role via AWS Security Token Service (STS) before authenticating to HashiCorp Vault. Use when the Cribl instance’s own IAM role does not have direct Vault access, such as for cross-account access.
        • AssumeRole > AssumeRole ARN: ARN of the IAM role to assume. Required when AssumeRole is enabled.
        • AssumeRole > External ID: Identifier required to authorize third-party access. Required when the role’s trust policy enforces an external ID condition.
        • AssumeRole > Duration (seconds): Duration of the Assumed Role session, in seconds. Minimum is 900 (15 minutes). Maximum is 43200 (12 hours). Default is 3600 (1 hour).

        Your Vault administrator must allow the IAM principal that matches the Authentication method and AssumeRole settings. In multi-Workspace deployments within the same AWS account, each Workspace authenticates with a different IAM principal, so the Vault role must include every principal that needs access.

      • AWS EC2:

        • Vault role: Name of the HashiCorp Vault role to authenticate against when using AWS EC2 authentication.
        • Custom authentication path: Auth method mount path in HashiCorp Vault, if different from the default aws (optional).
      • AppRole:

        • Role ID: Identifier for the AppRole defined in HashiCorp Vault.
        • Secret ID: Secret credential associated with the AppRole defined in HashiCorp Vault.
        • Custom authentication path: Auth method mount path in HashiCorp Vault, if different from the default approle (optional).
    • TLS Settings (Client Side):

      • Validate server certs: Toggle on to reject connections to HashiCorp Vault if the server certificate cannot be verified against the configured Certificate Authority (CA).

      • Server name (SNI): Server Name Indication (SNI) value to send in the TLS handshake. Use when the HashiCorp Vault server certificate CN or SAN does not match the Vault URL hostname.

      • Minimum TLS version: Minimum TLS version that Cribl will accept when connecting to HashiCorp Vault.

      • Maximum TLS version: Maximum TLS version that Cribl will accept when connecting to HashiCorp Vault.

    • Health Check > Health check endpoint: HashiCorp Vault API path to use for health checks to validate Vault connectivity. Default is /v1/sys/health.

  3. Select Test and Save.

On-Prem Vault and IP Allowlists

When the Workspace Leader resolves global secrets from a self-hosted HashiCorp Vault instance, it makes outbound connections to your Vault server to authenticate and resolve secrets. These connections come from the Leader’s egress IP address. If your HashiCorp Vault server uses an IP allowlist to restrict inbound connections, your Vault administrator must add the Leader’s egress IP address to the Vault allowlist.

Cribl.Cloud Workspaces use public egress by default, and the Leader’s egress IP is ephemeral. When Cribl replaces the Leader during upgrades or maintenance, the egress IP changes, and the allowlist entry that uses the existing egress IP stops working. You must use a stable Leader egress IP for a reliable integration if your HashiCorp Vault server uses an IP allowlist.

To enable static egress for a Workspace, contact Cribl Support. With static egress enabled, Cribl provisions one stable egress IP per Availability Zone. Your Vault administrator must add every egress IP to your HashiCorp Vault allowlist.

Static egress is irreversible. You cannot disable static egress after it is enabled for a Workspace or return to public egress.