Manage Customer Keys with Azure Key Vault

Prerequisites

To enable customer-managed keys with Azure Key Vault for a MongoDB project, you must:

• Use an M10 or larger cluster.
• Use Cloud Backups to encrypt your backup snapshots. Legacy Backups are not supported.

• Have the Tenant ID (or Directory ID) for an Active Directory tenant.
• Have the Client ID (or Application ID) and a non-expired application Password for an Azure Application associated to the Active Directory tenant.
• Have the Resource Group name of an Azure Resource Group containing the Key Vault.
• Have an Active Directory Application with the role of Azure key Vault Reader assigned to it.

• Have the Subscription ID and Key Vault Name of an Azure Key Vault. Ensure the Key Vault resource group matches the resource group name specified to Resource Group.

  The Key Vault must have the following Access Policies:

  • Key Management Operations

    • GET
    • LIST

  • Cryptographic Operations

    • ENCRYPT
    • DECRYPT

• Have the Key Identifier for a key in the specified Azure Key Vault.

  Atlas uses these resources when enabling encryption at rest for a cluster in the Atlas project. Consider creating an Azure Application, Resource Group, and Key Vault specifically for use with the Atlas project.

  To learn how to configure the referenced Azure components, see the Azure Documentation.

• To help users easily create or change a cluster, you can allow public access to the key. To narrow the scope of the key and mitigate risks, use controls such as TLS and authentication.

• For restricted access to defined IP ranges, allow access from Atlas IP addresses and the public IP addresses of your cluster nodes. Ensure Atlas can communicate with your key vault. To avoid connectivity interruptions, update your configuration whenever node IP addresses change.

  • If you restrict access to the key vault, you create more complexity when IP addresses change. For example, when you create or update a cluster, you must grant access in the Azure Key Vault to any new IP addresses. You should implement a process to remove IP addresses and keys when you delete a cluster or remove nodes.

Enable Customer-Managed Keys for a Project

You must enable customer key management for a project before you can enable it on a cluster in that project.

https://{keyvault-name}.vault.azure.net/{object-type}/{object-name}/{object-version}

Enable Customer Key Management for an Atlas Cluster

After you Enable Customer-Managed Keys for a Project, you must enable customer key management for each Atlas cluster that contains data that you want to encrypt.

For new clusters, toggle the Manage your own encryption keys setting to Yes when you create the cluster.

For existing clusters:

Disable Customer-Managed Keys for a Project

You must disable customer key management on each cluster in a project before you can disable the feature for the project.

Revoke Access to an Encryption Key

You can revoke Atlas's access to an encryption key from within AKV. Atlas automatically pauses your clusters when you revoke access to the encryption key unless your AKV IP access list restricts the Atlas control plane.

To allow automatic pausing of your cluster, you must either:

• Disable the IP access list for your AKV
• Allow access to your AKV from the Atlas control plane.

If the IP access list for your AKV restricts access from the Atlas control plane when you revoke access to an encryption key, you must pause your clusters manually to revoke Atlas's access.

Alerts

Atlas automatically creates an encryption key rotation alert once you configure customer key management for a project.

To reset this alert, Rotate your Azure Key Identifier.

Prerequisites

You must create a new key in the Azure Key Vault associated to the Atlas project.

Procedure

The following procedure documents how to rotate your Atlas project Key Identifier by specifying a new key identifier in Atlas.

Alerts

Atlas resets the encryption key rotation alert alert at the completion of this procedure.