noy-db
stable

azure-keyvault

Seals the managed-secret vault key via Azure Key Vault RSA Encrypt/Decrypt, with Key Vault audit logs recording every vault open.

@noy-db/at-azure-keyvault · pnpm add @noy-db/at-azure-keyvault Cloud-KMS sealing — the key lives in Azure Key Vault, access controlled by RBAC/Key Vault policy.

What it does

atAzureKeyvault({ keyId }) seals and unseals the hub-generated managed-mode secret via RSA encrypt/decrypt against a Key Vault key, with Key Vault audit logging recording every vault open. Its pid is azure-kv:<keyId> (e.g. azure-kv:https://my-noydb-vault.vault.azure.net/keys/noydb-sealing/0123456789abcdef). Credentials resolve via DefaultAzureCredential (managed identity, AZURE_CLIENT_ID/AZURE_TENANT_ID/AZURE_CLIENT_SECRET, or az login); never pass raw credentials in the options — inject a pre-built cryptographyClient instead.

Version-bound — always pin a versioned key id. Azure's CryptographyClient resolves the key version at construction, and every decrypt call is pinned to that version. A versionless URL (…/keys/<name>) resolves to "latest," so if the key auto-rotates, every secret sealed under the previous version becomes permanently undecryptable. Rotation is a deliberate migration (unseal under the old version, seal under the new), not transparent like the AWS/GCP providers.

Usage

import { atAzureKeyvault } from '@noy-db/at-azure-keyvault'

const sealingKey = atAzureKeyvault({
  keyId: 'https://my-noydb-vault.vault.azure.net/keys/noydb-sealing/0123456789abcdef',
})
sealingKey.id // → 'azure-kv:https://my-noydb-vault.vault.azure.net/keys/noydb-sealing/0123456789abcdef'

See also

aws-kms

env