Enable data encryption with customer-managed keys in Azure Cosmos DB for PostgreSQL
APPLIES TO: Azure Cosmos DB for PostgreSQL (powered by the Citus database extension to PostgreSQL)
- An existing Azure Cosmos DB for PostgreSQL account.
Enable data encryption with customer-managed keys
Create all the following resources in the same region where your Azure Cosmos DB for PostgreSQL cluster will be deployed.
Create a User-Assigned Managed Identity. Currently, Azure Cosmos DB for PostgreSQL only supports user-assigned managed identities.
Create an Azure Key Vault and add an access policy to the created User-Assigned Managed Identity with the following key permissions: Get, Unwrap Key, and Wrap Key.
Generate a Key in the Key Vault (supported key types: RSA 2048, 3071, 4096).
Select the Customer-Managed Key encryption option during the creation of the Azure Cosmos DB for PostgreSQL cluster and select the appropriate User-Assigned Managed Identity, Key Vault, and Key created in Steps 1, 2, and 3.
User Assigned Managed Identity
Search for Managed Identities in the global search bar.
Create a new User assigned managed Identity in the same region as your Azure Cosmos DB for PostgreSQL cluster.
Learn more about User Assigned Managed Identity..
Using customer-managed keys with Azure Cosmos DB for PostgreSQL requires you to set two properties on the Azure Key Vault instance that you plan to use to host your encryption keys: Soft Delete and Purge Protection.
If you create a new Azure Key Vault instance, enable these properties during creation:
If you're using an existing Azure Key Vault instance, you can verify that these properties are enabled by looking at the Properties section on the Azure portal. If any of these properties aren’t enabled, see the "Enabling soft delete" and "Enabling Purge Protection" sections in one of the following articles.
The key Vault must be set with 90 days for 'Days to retain deleted vaults'. If the existing key Vault has been configured with a lower number, you'll need to create a new key vault as it can't be modified after creation.
Your Azure Key Vault instance must be allow public access from all the networks.
Add an Access Policy to the Key Vault
From the Azure portal, go to the Azure Key Vault instance that you plan to use to host your encryption keys. Select Access configuration from the left menu. Make sure Vault access policy is selected under Permission model and then select Go to access policies.
Select + Create.
In the Permissions Tab under the Key permissions drop-down menu, select Get, Unwrap Key, and Wrap Key permissions.
In the Principal Tab, select the User Assigned Managed Identity you had created in prerequisite step.
Navigate to Review + create select Create.
Create / Import Key
From the Azure portal, go to the Azure Key Vault instance that you plan to use to host your encryption keys.
Select Keys from the left menu and then select +Generate/Import.
The customer-managed key to be used for encrypting the DEK can only be asymmetric RSA Key type. All RSA Key sizes 2048, 3072 and 4096 are supported.
The key activation date (if set) must be a date and time in the past. The expiration date (if set) must be a future date and time.
The key must be in the Enabled state.
If you're importing an existing key into the key vault, make sure to provide it in the supported file formats (
If you're manually rotating the key, the old key version shouldn't be deleted for at least 24 hours.
Enable CMK encryption during the provisioning for a new cluster
Select Customer Managed Key under Data encryption key option.
Select the User Assigned Managed Identity created in the previous section.
Select the Key Vault created in the previous step, which has the access policy to the user managed identity selected in the previous step.
Select the Key created in the previous step, and then select Review+create.
Verify that CMK is encryption is enabled by Navigating to the Data Encryption blade of the Cosmos DB for PostgreSQL cluster in the Azure portal.
Data encryption can only be configured during the creation of a new cluster and can't be updated on an existing cluster. A workaround for updating the encryption configuration on an existing cluster is to restore an existing PITR backup to a new cluster and configure the data encryption during the creation of the newly restored cluster.
When CMK encryption is enabled on the primary cluster, all standby HA replicas are automatically encrypted by the primary cluster’s CMK
CMK encryption can't be enabled on cross region read replicas.
CMK encryption can only be enabled during the creation of a new Azure Cosmos DB for PostgreSQL cluster.
CMK encryption isn't supported with Private access (including VNET).
Changing encryption configuration by performing a PITR
Encryption configuration can be changed from service managed encryption to CMK encryption or vice versa while performing a Point in restore operation to a new cluster.
Monitor the customer-managed key in Key Vault
To monitor the database state, and to enable alerting for the loss of transparent data encryption protector access, configure the following Azure features:
Azure Resource Health: An inaccessible database that has lost access to the Customer Key shows as "Inaccessible" after the first connection to the database has been denied.
Activity log: When access to the Customer Key in the customer-managed Key Vault fails, entries are added to the activity log. You can reinstate access as soon as possible, if you create alerts for these events.
Action groups: Define these groups to send you notifications and alerts based on your preference.