Compliance Storage

Chronicle stores encryption keys alongside the rest of your application data by default. When you configure a dedicated compliance storage, those keys are stored in a separate, independently secured backend — such as HashiCorp Vault — so that key material never resides in the same database as the encrypted events.

If no compliance storage is explicitly configured, Chronicle uses the general storage backend for encryption keys.

Configuration

The compliance section now contains an encryption subsection that holds the storage configuration. Set a type and connectionDetails inside compliance.encryption.storage:

{
  "compliance": {
    "encryption": {
      "storage": {
        "type": "<storage-type>",
        "connectionDetails": "<connection-string-or-url>"
      }
    }
  }
}

Vault

HashiCorp Vault provides a purpose-built secrets backend that is well-suited for storing PII encryption keys. Chronicle uses the KV v2 secrets engine to store each key revision at a distinct path.

Authentication

Chronicle authenticates to Vault using a token. The token is read from the VAULT_TOKEN environment variable at startup. Ensure this variable is set before the Chronicle server process starts.

Configuration

{
  "compliance": {
    "encryption": {
      "storage": {
        "type": "vault",
        "connectionDetails": "http://vault:8200"
      }
    }
  }
}

Set VAULT_TOKEN in the environment:

export VAULT_TOKEN=s.myVaultToken

Note: Never include the Vault token in the connectionDetails string or in chronicle.json. Always pass it through the environment to avoid storing secrets in your configuration files.

KV v2 mount point

Chronicle uses the secret KV v2 mount point by default. Encryption keys are organized under a path derived from the event store name, namespace, and subject identifier.

Key paths

Encryption keys are stored at:

secret/<event-store>/<namespace>/<identifier>/<revision>

Each revision is an independent secret, which means individual revisions can be deleted without affecting others (for example, when rotating keys or when the full key history is required for a limited time).

Property	Type	Required	Description
type	string	Yes	Must be `vault`
connectionDetails	string	Yes	The Vault server address, for example `http://vault:8200`

Azure Key Vault

Azure Key Vault provides a fully managed, cloud-native secrets backend for storing PII encryption keys. Chronicle uses the Azure Key Vault Secrets API to store each key revision as a distinct secret.

Authentication

Chronicle authenticates to Azure Key Vault using DefaultAzureCredential. This supports multiple authentication methods in order:

Environment variables (AZURE_CLIENT_ID, AZURE_CLIENT_SECRET, AZURE_TENANT_ID)
Workload identity
Managed identity
Azure CLI credentials
Visual Studio / VS Code credentials

Ensure that the identity used has the Key Vault Secrets Officer role (or at minimum Get, List, Set, and Delete secret permissions) on the target Key Vault.

Configuration

{
  "compliance": {
    "encryption": {
      "storage": {
        "type": "azure-key-vault",
        "connectionDetails": "https://my-vault.vault.azure.net"
      }
    }
  }
}

Secret naming

Encryption keys are stored as individual secrets. Secret names follow this pattern:

chronicle--{event-store}--{namespace}--{identifier}--{revision}

Each component is sanitized to lowercase alphanumeric characters with single hyphens replacing any other character sequences. Double hyphens (--) serve as unambiguous separators between components.

Property	Type	Required	Description
type	string	Yes	Must be `azure-key-vault`
connectionDetails	string	Yes	The Azure Key Vault URI, for example `https://my-vault.vault.azure.net`