Overview

By default, the storage account created for your Cribl Lake Azure Storage Location encrypts all data at rest with Microsoft-managed keys. If your organization requires control over the encryption keys, you can switch the storage account to customer-managed keys (CMK) backed by your own Azure Key Vault.

Because the storage account lives within your Azure subscription, CMK is a storage account setting you can control directly. You can enable it at any time after deploying the Cribl Lake Azure Resource Manager (ARM) template, and change or rotate the key later, without involving Cribl.

Note: This is a self-service Azure configuration. Cribl doesn't need to be reconfigured before or after you enable CMK, and there's no CMK setting in the Cribl Lake Azure Storage Location UI.
 

How CMK Works with Cribl Lake

Azure Storage encrypts data at rest in two layers: your data is encrypted with an account encryption key, and that key is itself wrapped ("encrypted") by your key in Key Vault. The unwrap operation is performed by the storage account's own managed identity against your Key Vault. This happens entirely inside Azure Storage.

Cribl Lake reads and writes blobs through the Storage Blob Data Contributor role granted by the ARM template. Encryption and decryption are transparent to that data path:

• No Cribl configuration change is required. The Cribl service principal never accesses your key and needs no Key Vault permission.
• Read/write behavior is unchanged. Cribl Stream, Cribl Search, and Dataset operations continue exactly as before.
• Revocation is your kill-switch. If you disable or delete the key in Key Vault, the storage account becomes inaccessible and all read/write operations fail until you re-enable the key. This is the intended way to revoke access to your data.

Prerequisites

Before you enable CMK, ensure that you have:

• An Azure Storage Location storage account is already deployed via the Cribl Lake ARM template.
• An Azure Key Vault in the same tenant, with both soft delete and purge protection enabled (both are required for CMK). Soft delete is on by default on new vaults and can't be disabled; purge protection must be enabled explicitly. We recommend using Azure RBAC for the vault's permission model.
• A key created in that Key Vault (RSA or RSA-HSM, 2048-, 3072-, or 4096-bit).
• Permission to create a managed identity and to assign roles on the Key Vault, typically Owner or User Access Administrator + Contributor on the relevant scopes.

Note: The Key Vault should reside in the same region as the storage account for optimal performance and in the same subscription for the simplest role assignment flow.

Note: The Key Vault Crypto Service Encryption User role used in the Configuration Steps section grants the minimum key permissions Azure Storage needs: wrapkey, unwrapkey, and get. If your vault uses the legacy access-policy model instead of Azure RBAC, grant those three permissions directly.

Configuration Steps

Enable CMK in three parts: create a managed identity, grant it access to your key, then point the storage account at the key using that identity.

Azure Portal

1. Create a user-assigned managed identity

1. In the Azure Portal, search for Managed Identities and select + Create.
2. Choose the subscription, resource group, and region (match the storage account's region).
3. Give the identity a name (for example, cribl-lake-cmk-identity) and select Review + create, then Create.

Note: Because the Azure Storage Location storage account already exists, it can use either a user-assigned or a system-assigned managed identity. We recommend a user-assigned identity because it lets you grant the Key Vault role before binding the key to the storage account, avoiding an ordering problem. (New storage accounts, by contrast, require a user-assigned identity at creation time.)

2. Grant the identity access to your key

1. Navigate to your Key Vault and select Access control (IAM).
2. Select Add > Add role assignment.
3. Select the Key Vault Crypto Service Encryption User role and choose Next.
4. Under Members, select Managed identity, then select the user-assigned identity you created in step 1.
5. Select Review + assign.

3. Enable CMK on the storage account

1. Navigate to your storage account and select Encryption under Security + networking.
2. For Encryption type, select Customer-managed keys.
3. For Encryption key, choose Select from key vault, then pick your Key Vault and key.
   • Leave the version unselected so Azure automatically uses the latest key version and picks up rotations.
4. For User-assigned identity, select the identity you created in step 1.
5. Select Save.

Encryption re-wrapping happens in the background with no downtime and no impact on the Azure Storage Location or Datasets.

Azure CLI

Replace the placeholder values in angle brackets with your own.

# Variables
resourceGroup="<your-resource-group>"
location="<region>"                 # match the storage account region
storageAccount="<cribl-lake-storage-account>"
keyVaultName="<your-key-vault>"
keyName="<your-key>"
identityName="cribl-lake-cmk-identity"

# 1. Create a user-assigned managed identity

identityResourceId=$(az identity create \
  --name "$identityName" \
  --resource-group "$resourceGroup" \
  --location "$location" \
  --query id --output tsv)

identityPrincipalId=$(az identity show \
  --name "$identityName" \
  --resource-group "$resourceGroup" \
  --query principalId --output tsv)

# 2. Grant the identity access to the key vault

keyVaultResourceId=$(az keyvault show \
  --name "$keyVaultName" \
  --query id --output tsv)

az role assignment create \
  --role "Key Vault Crypto Service Encryption User" \
  --assignee-object-id "$identityPrincipalId" \
  --assignee-principal-type ServicePrincipal \
  --scope "$keyVaultResourceId"

# 3. Point the storage account at the key using that identity
#   (omit --encryption-key-version so Azure auto-rotates to the latest version)

keyVaultUri=$(az keyvault show \
  --name "$keyVaultName" \
  --query properties.vaultUri --output tsv)

az storage account update \
  --name "$storageAccount" \
  --resource-group "$resourceGroup" \
  --identity-type UserAssigned \
  --user-identity-id "$identityResourceId" \
  --encryption-key-source Microsoft.Keyvault \
  --encryption-key-vault "$keyVaultUri" \
  --encryption-key-name "$keyName" \
  --key-vault-user-identity-id "$identityResourceId"

# 4. Verify the storage account is now using your key
# Returns "Microsoft.Keyvault" for CMK (or "Microsoft.Storage" for Microsoft-managed keys)

az storage account show \
  --name "$storageAccount" \
  --resource-group "$resourceGroup" \
  --query encryption.keySource --output tsv

Use Azure Key Vault Managed HSM

If your key lives in an Azure Key Vault Managed HSM rather than a standard Key Vault, the flow is the same as the Configuration Steps, with two differences:

• Role: Grant the identity the Managed HSM Crypto Service Encryption User role instead of the standard Key Vault role. Microsoft recommends scoping this role to the individual key rather than to the entire HSM to grant the fewest privileges.
• Key type: Managed HSM keys are RSA-HSM. As with standard Key Vault, the storage account, vault, and HSM can be in different regions and subscriptions, though the same region is still recommended for latency.

Note: The Microsoft Managed HSM walkthrough uses a system-assigned identity (az storage account update --assign-identity), but a user-assigned identity works the same way. Reuse the steps in the Configuration Steps section and swap the role name.

Key Rotation

Azure Storage doesn't rotate the key for you; it references the key you configured.

• Automatic version pickup: If you left the key version unset (as recommended in the Configuration Steps section), Azure Storage checks Key Vault for a new version approximately once per day and automatically adopts it. Configure key auto-rotation in Key Vault, or create a new version manually, and Azure Storage picks it up.
• Wait before disabling old versions: After rotating, wait at least 24 hours before disabling the previous version so Azure Storage has time to detect the new one.

Changing or rotating the key doesn't affect Cribl Lake and causes no downtime.

Revoke Access

To temporarily revoke access to the storage account, disable the key in Key Vault. After the key is disabled, all read and write operations on the storage account fail, including those for Cribl Lake, until you re-enable it. Your data remains encrypted and intact while the key is disabled.

Switch Back to Microsoft-Managed Keys

You can revert at any time.

Portal: On the storage account Encryption page, set the Encryption type to Microsoft-managed keys, then select Save.

CLI:

az storage account update \
  --name "$storageAccount" \
  --resource-group "$resourceGroup" \
  --encryption-key-source Microsoft.Storage

Related

• Microsoft: Customer-managed keys for Azure Storage encryption
• Microsoft: Configure customer-managed keys for a new storage account
• Microsoft: Configure customer-managed keys for an existing storage account
• Microsoft: Configure customer-managed keys in a managed HSM
• Microsoft: Check the encryption key model for a storage account

• Cribl Lake Azure Storage Location ARM Template Reference

• Cribl Lake Azure Storage Locations