How to manage secrets with Azure Key Vault

Azure Key Vault centralizes secrets, encryption keys, and certificates with hardware-backed protection and fine-grained access control. Combined with managed identity, apps read secrets without storing any credentials themselves, eliminating the bootstrap secret problem.

Prerequisites

• An Azure subscription and the Azure CLI.
• An app on a service that supports managed identity (App Service, Functions, Container Apps).

Steps

1. Create a vault

az keyvault create --name kv-app-$RANDOM --resource-group rg-app --location eastus --enable-rbac-authorization true

RBAC authorization is the modern access model, preferred over legacy access policies.

2. Store a secret

az keyvault secret set --vault-name <vault> --name DbPassword --value 's3cr3t'

3. Enable managed identity

az functionapp identity assign --name <app> --resource-group rg-app

This gives the app an Azure AD identity with no credentials to manage.

4. Grant RBAC access

Assign the app's identity the least-privileged role, Key Vault Secrets User, scoped to the vault:

az role assignment create --assignee <principal-id> \
  --role "Key Vault Secrets User" --scope <vault-resource-id>

5. Read from the app

var client = new SecretClient(new Uri(vaultUrl), new DefaultAzureCredential());
KeyVaultSecret secret = await client.GetSecretAsync("DbPassword");

DefaultAzureCredential uses the managed identity automatically in Azure.

6. Rotate and audit

Set secret expiry and rotation reminders, and stream vault access logs to Log Analytics to audit who read what.

Verification

Run the app and confirm it reads the secret with no credentials in config. Remove the role assignment and confirm access is denied, proving RBAC is enforced. Check the vault's diagnostic logs for the read events.

Next Steps

Use Key Vault references in app settings so you never read the SDK directly, store TLS certificates in the vault for managed renewal, and replicate to a secondary region.