Skip to content

Azure Key Vault Key Store

The Azure Key Vault key store persists encryption keys as secrets in Azure Key Vault. It uses DefaultAzureCredential for authentication, integrating naturally with Azure-hosted applications using managed identities.

Installation

shell
dotnet add package Tayra.KeyStore.AzureKeyVault
powershell
Install-Package Tayra.KeyStore.AzureKeyVault

Basic Setup

The simplest registration takes your vault URI and uses DefaultAzureCredential:

cs
var services = new ServiceCollection();

// Use Azure Key Vault with DefaultAzureCredential
services.AddTayra(opts => opts.LicenseKey = licenseKey)
    .UseAzureKeyVaultKeyStore(
        vaultUri: "https://my-vault.vault.azure.net/");
anchor

Configuration Options

Use the options overload to customize prefix, retry behavior, and soft-delete handling:

cs
var services = new ServiceCollection();

services.AddTayra(opts => opts.LicenseKey = licenseKey)
    .UseAzureKeyVaultKeyStore(
        vaultUri: "https://my-vault.vault.azure.net/",
        options =>
        {
            // Prefix for secret names in Azure Key Vault (default: "tayra-")
            options.KeyPrefix = "myapp-tayra-";

            // Maximum number of retries for transient errors (default: 3)
            options.MaxRetries = 5;

            // Base delay for exponential backoff on retries (default: 100ms)
            options.RetryBaseDelay = TimeSpan.FromMilliseconds(200);

            // Purge secrets after soft-deleting them (default: false)
            options.PurgeOnDelete = false;
        });
anchor

Options Reference

PropertyTypeDefaultDescription
VaultUristring?nullThe Azure Key Vault URI (e.g., "https://my-vault.vault.azure.net/"). Required.
KeyPrefixstring"tayra"Prefix for secret names in Azure Key Vault. All key IDs are prefixed with this value.
MaxRetriesint3Maximum number of retries for transient errors.
RetryBaseDelayTimeSpan100msBase delay for exponential backoff on retries.
PurgeOnDeleteboolfalseWhen true, permanently purges secrets after soft-deleting. When false, secrets remain in soft-deleted state.

Pre-configured SecretClient

If you already have an Azure.Security.KeyVault.Secrets.SecretClient configured (e.g., with a specific TokenCredential), pass it directly:

cs
var services = new ServiceCollection();

var client = new Azure.Security.KeyVault.Secrets.SecretClient(
    new Uri("https://my-vault.vault.azure.net/"),
    new Azure.Identity.ManagedIdentityCredential());

services.AddTayra(opts => opts.LicenseKey = licenseKey)
    .UseAzureKeyVaultKeyStore(client, options =>
    {
        options.KeyPrefix = "myapp-";
    });
anchor

DefaultAzureCredential

When using the URI-based overload, Tayra creates a SecretClient with DefaultAzureCredential, which tries the following credential sources in order:

  1. Environment variables (AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_CLIENT_SECRET)
  2. Managed identity (system-assigned or user-assigned)
  3. Azure CLI (az login)
  4. Azure PowerShell
  5. Visual Studio / VS Code

Local Development

For local development, sign in with az login and DefaultAzureCredential will use your Azure CLI credentials automatically. No code changes needed between development and production.

RBAC Permissions

The identity accessing Azure Key Vault needs the following role assignment:

RoleScopeRequired For
Key Vault Secrets OfficerKey Vault resourceFull CRUD on secrets

Alternatively, use a custom role with these specific data actions:

Microsoft.KeyVault/vaults/secrets/readMetadata/action
Microsoft.KeyVault/vaults/secrets/getSecret/action
Microsoft.KeyVault/vaults/secrets/setSecret/action
Microsoft.KeyVault/vaults/secrets/delete
Microsoft.KeyVault/vaults/secrets/purge/action   (only if PurgeOnDelete = true)

Access Policies vs RBAC

Azure Key Vault supports two permission models: vault access policies and Azure RBAC. Tayra works with either model, but Azure RBAC is recommended for new deployments as it provides finer-grained control and integrates with Azure AD.

Soft-Delete Considerations

Azure Key Vault enables soft-delete by default (and it cannot be disabled for new vaults). When Tayra deletes a key for crypto-shredding:

  • PurgeOnDelete = false (default) -- The secret is soft-deleted. It remains in the vault in a recoverable state for the configured retention period (7-90 days). The key is no longer accessible through normal GetAsync calls, so decryption will return replacement values.

  • PurgeOnDelete = true -- The secret is soft-deleted and then immediately purged. This permanently removes the key with no possibility of recovery. This provides stronger GDPR compliance guarantees but requires the purge permission.

GDPR and Soft-Delete

For GDPR compliance, soft-delete without purge is typically sufficient. Once a key is soft-deleted, Tayra cannot retrieve it, and encrypted fields will return replacement values. The soft-deleted secret will be automatically purged after the vault's retention period expires.

Secret Naming

Tayra stores each encryption key as a separate secret in Azure Key Vault. The secret name follows this pattern:

{key_prefix}{key_id}
ComponentValueSource
key_prefixtayra-KeyPrefix option (default: "tayra-"). Includes the dash separator because Azure Key Vault secret names cannot contain /.
key_iduser-123The Tayra key identifier, sanitized to alphanumeric and dashes only.

For example, with the default prefix tayra- and a key ID of user-123, the secret name is tayra-user-123.

Character Restrictions

Azure Key Vault secret names only allow alphanumeric characters and dashes. Tayra sanitizes key IDs by replacing unsupported characters. Keep key IDs simple to avoid unexpected transformations.

Retry Logic

The Azure Key Vault key store includes built-in retry logic with exponential backoff for transient HTTP errors. The backoff delay doubles on each attempt: for the default settings (base delay = 100ms, max retries = 3), the delays are approximately 100ms, 200ms, and 400ms.

This is in addition to any retry policy configured on the SecretClient itself via SecretClientOptions.Retry.

See Also