For the complete documentation index, see llms.txt. This page is also available as Markdown.

Azure Key Vault Encryption

Protect Secrets Manager connection details with Azure Key Vault Keys

Keeper Secrets Manager integrates with Azure Key Vault in order to provide encryption for Keeper Secrets Manager configuration files. With this integration, you can protect connection details on your machine while taking advantage of Keeper's zero-knowledge encryption of all your secret credentials.

Features

  • Encrypt and Decrypt your Keeper Secrets Manager configuration files with Azure Key Vault.

  • Protect against unauthorized access to your Secrets Manager connections.

  • Requires only minor changes to code for immediate protection. Works with all Keeper Secrets Manager SDK functionality.

  • Supports RSA Asymmetric keys from Azure.

Prerequisites

Setup

1. Install Module

Setting up project using Gradle or Maven

Gradle

Maven

The Secrets Manager Azure Key Vault module can be installed using npm

The Secrets Manager Storage module can be installed using pip:

The Azure backend requires three additional packages:

The Secrets Manager KSM modules are located in the Keeper Secrets Manager storage module which can be installed using dotnet

2. Configure Azure Key Vault Connection

Ensure that you have an Azure Key Vault instance available. The following parameters are needed to connect to Azure Key Vault: AZURE_TENANT_ID: The Microsoft Entra tenant (directory) ID.

AZURE_CLIENT_ID: The client (application) ID of an App Registration in the tenant.

AZURE_CLIENT_SECRET: A client secret that was generated for the App Registration.

You will need an Azure App directory App to use the Azure Key Vault integration.

For more information on Azure App Directory App registration and Permissions see the Azure documentation:

3. Add Azure Key Vault Storage to Your Code

Once the Azure connection has been configured, you can use Azure Key Vault to encrypt and decrypt KSM configurations. Tell the Secrets Manager SDK to utilize Key Vault as storage.

Using Azure Key Vault Integration

Once setup, the Secrets Manager Azure Key Vault integration supports all Secrets Manager SDK functionality. Your code will need to be able to access the Azure Keys in order to manage the encryption and decryption of the KSM configuration file. Using Specified Connection credentials

To do this, create AzureKeyValueStorage instance and use this in SecretManagerOptions constructor.

The AzureKeyValueStorage will require the name of the Secrets Manager configuration file with azure_key_id , azure_keyvault_URL and configuration.

To do this, use AzureKeyValueStorage as your Secrets Manager storage in the SecretsManager constructor.

The storage will require an Azure Key ID, as well as the name of the Secrets Manager configuration file which will be encrypted by Azure Key Vault.

To do this, use AzureKeyValueStorage as your Secrets Manager storage in the SecretsManager constructor as config along with a token.

The storage will require a Azure Key ID, as well as the location of the Secrets Manager configuration file which will be encrypted by Azure-KSM Integration and Azure session configuration as shown below.

Upgrading from v1.0.x? v1.1.0 includes these behavioral changes:

  • AES-GCM nonce corrected from 16 to 12 bytes per NIST SP 800-38D. Existing encrypted configs remain readable.

  • decrypt_config() now defaults to autosave=False — call decrypt_config(autosave=True) to preserve the previous behavior.

  • Encrypt and decrypt failures now raise exceptions instead of silently corrupting storage state.

  • Corrupt or non-UTF8 config files now raise "is not a valid encrypted config file" instead of leaking JSONDecodeError.

  • Config writes are now atomic (write-then-rename), so a failed write no longer truncates the existing config to zero bytes.

  • delete_all() now removes the encrypted config file from disk instead of writing an empty encrypted blob.

  • AzureKeyValueStorage is now thread-safe for concurrent reads and writes.

To do this, use AzureKeyValueStorage as your Secrets Manager storage in the SecretsManager constructor.

The storage will require an Azure Key ID, as well as the name of the Secrets Manager configuration file which will be encrypted by Azure Key Vault. Optionally AzureSessionConfig can be provided. If credentials are not provided the default credentials are used.

Additional Options

Change Key

We can change key that is used for encrypting the KSM configuration, examples below show the code needed to use it

Decrypt Config

We can decrypt the config if current implementation is to be migrated onto a different cloud or if you want your raw credentials back. The function accepts a boolean which when set to true will save the decrypted configuration to file and if it is false, will just return decrypted configuration.

Check out the KSM SDKs documentation for more examples and functionality

Last updated