Azure Key Vault
@purista/azure-secret-store connects to Azure Key Vault. It is the natural choice for Azure-hosted workloads — secrets are versioned, access is controlled with Azure RBAC and managed identities, and operations are logged to Azure Monitor.
Capabilities
| Feature | Support |
|---|---|
Read (getSecret) | ✅ |
Write (setSecret) | ✅ (opt-in) |
Delete (removeSecret) | ✅ (opt-in, soft-delete) |
| Managed identity auth | ✅ |
| Secret versioning | ✅ |
| Azure Monitor audit logs | ✅ |
| Azure RBAC | ✅ |
Install
npm install @purista/azure-secret-store
Setup
import { AzureSecretStore } from '@purista/azure-secret-store'
const secretStore = new AzureSecretStore({
vaultUrl: process.env.AZURE_VAULT_URL ?? 'https://my-vault.vault.azure.net',
// Uses DefaultAzureCredential — works with managed identity, env vars, CLI login:
enableSet: true,
enableRemove: true,
})
const myService = await myV1Service.getInstance(eventBridge, { secretStore })
The store uses @azure/identity’s DefaultAzureCredential — it automatically picks up managed identity in AKS/App Service, environment variables (AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_CLIENT_SECRET), or Azure CLI credentials in development.
Usage inside a handler
.setCommandFunction(async function (context, payload) {
const { dbConnectionString } = await context.secrets.getSecret('dbConnectionString')
// use dbConnectionString to connect to your database
})
Access policy
Assign the Key Vault Secrets User role for read-only access, or Key Vault Secrets Officer for read/write. Use managed identities instead of service principal credentials wherever possible.
Operational tips
- Enable Key Vault soft-delete and purge protection to prevent accidental permanent deletion
- Use separate Key Vaults per environment (dev/staging/prod) scoped with distinct RBAC assignments
- Monitor access logs in Azure Monitor — set alerts on unexpected access patterns
- Key Vault has service limits; use caching at the application layer for high-throughput reads