> For the complete MongoDB documentation index, see www.mongodb.com/docs/llms.txt # Encryption at Rest using Customer Key Management **Note:** This page applies to both Atlas Infinite and Atlas Core. You can add another layer of security to your data by enabling database-level Encryption at Rest with Customer-Managed Keys. You own and control the encryption keys, which are stored in your cloud provider's KMS (Key Management Service). To learn how Atlas encrypts your data at rest and how the available key types differ, see [Atlas Encryption at Rest Overview.](https://www.mongodb.com/docs/atlas/security-encryption-at-rest-overview.md#std-label-atlas-encryption-at-rest-overview) Configuring Encryption at Rest using your Key Management incurs extra charges for the Atlas project. To learn more, see [Advanced Security.](https://www.mongodb.com/docs/atlas/billing/additional-services.md#std-label-advanced-security) **Note:** The MongoDB Atlas Shared Responsibility Model defines the complementary duties of MongoDB and its customers in maintaining a secure and resilient data environment. Under this framework, MongoDB manages the security and operational integrity of the underlying platform, while customers are responsible for the configuration, management, and data policies of their specific deployments. For a detailed breakdown of ownership across security and operational excellence, see [Shared Responsibility Model.](https://www.mongodb.com/resources/products/fundamentals/shared-responsibility) To enforce that Customer-Managed Keys for encryption at rest are enabled on all clusters and dedicated search deployments in a project, use [Atlas Resource Policies](https://www.mongodb.com/docs/atlas/atlas-resource-policies.md#std-label-atlas-resource-policies-overview). You can use resource policies to require CMK before you create or change clusters or search deployments. **Important: Feature unavailable in Flex Clusters** Flex clusters don't support this feature at this time. To learn more, see [Atlas Flex Limitations.](https://www.mongodb.com/docs/atlas/reference/flex-limitations.md#std-label-flex-cluster-limitations) You can use one or more of the following customer key management providers when configuring Encryption at Rest for the Atlas project: - [Amazon Web Services Key Management Service](https://www.mongodb.com/docs/atlas/security-aws-kms.md#std-label-security-aws-kms) - [Azure Key Vault](https://www.mongodb.com/docs/atlas/security-azure-kms.md#std-label-security-azure-kms) - [Google Cloud Platform Key Management Service](https://www.mongodb.com/docs/atlas/security-gcp-kms.md#std-label-security-gcp-kms) **Note:** Some Atlas Infinite public preview limitations apply to customer key management. For the complete list, see [public preview limitations.](https://www.mongodb.com/docs/atlas/infinite/atlas-infinite-landing.md#std-label-atlas-infinite-availability) In public preview, Atlas supports customer-managed keys on Atlas Infinite only through [AWS KMS](https://www.mongodb.com/docs/atlas/security-aws-kms.md#std-label-security-aws-kms). Azure Key Vault and Google Cloud KMS are not supported. When an Atlas Infinite cluster uses customer-managed keys, you restore a snapshot within the project that created it; cross-project and cross-organization restores are not supported. After configuring at least one key management provider for the Atlas project, you can enable customer key management for each Atlas cluster for which they require encryption. The key management provider doesn't have to match the cluster cloud service provider. On an Atlas Infinite cluster, you can migrate between default encryption and a customer-managed key in either direction. Atlas Infinite treats the migration as a key rotation: your cluster stays available, and the previous key stays valid until the migration completes. To learn more, see [Atlas Infinite Encryption.](https://www.mongodb.com/docs/atlas/security-encryption-at-rest-overview.md#std-label-atlas-infinite-encryption-at-rest) **Note:** When you enable or disable customer key management, Atlas performs an initial sync to re-encrypt your cluster data. It also rebuilds MongoDB Search and MongoDB Vector Search indexes on the cluster. Alternatively, for projects with `M10` or larger Atlas clusters deployed on only Azure (Microsoft Azure) regions, you can use the Atlas Administration API to automatically create Azure Private Link in your AKV (Azure Key Vault) that enables Atlas to securely communicate with your AKV (Azure Key Vault) over Azure (Microsoft Azure)'s private network interfaces. To learn more, see [Manage Customer Keys with Azure Key Vault.](https://www.mongodb.com/docs/atlas/security-azure-kms.md#std-label-security-azure-kms) If your KMS (Key Management Service) provider becomes unavailable, this doesn't disable your cluster while it still runs. If you decide to restart such a cluster, Atlas disables it if its key is revoked. To learn about recommendations for encryption, including data classification levels and the types of encryption to use, see [Recommendations for Atlas Data Encryption](https://www.mongodb.com/docs/atlas/architecture/current/data-encryption.md#std-label-arch-center-data-encryption-recs) in the Atlas Architecture Center. **Note:** For clusters with encryption at rest using customer-managed keys, Atlas [data validation](https://www.mongodb.com/docs/atlas/data-validation.md#std-label-data-validation) requires extra access to your KMS (Key Management Service) to decrypt data. To learn more, see [Data Validation KMS Usage.](https://www.mongodb.com/docs/atlas/security-kms-encryption.md#std-label-data-validation-kms-usage) ## Required Access To configure customer key management, you must have [`Project Owner`](https://www.mongodb.com/docs/atlas/reference/user-roles.md#mongodb-authrole-Project-Owner) access to the project. Users with [`Organization Owner`](https://www.mongodb.com/docs/atlas/reference/user-roles.md#mongodb-authrole-Organization-Owner) access must add themselves to the project as a `Project Owner`. ## Configure Atlas with Customer Key Management Encryption at Rest using Key Management requires valid key management provider credentials and an encryption key. To give these details and enable Customer Key Management: 1. In Atlas, go to the Advanced page for your project. If it's not already displayed, select the organization that contains your project from the Organizations menu in the navigation bar. If it's not already displayed, select your project from the Projects menu in the navigation bar. In the sidebar, click Database & Network Access under the Security heading. In the sidebar, click Advanced. The [Advanced](https://cloud.mongodb.com/go?l=https%3A%2F%2Fcloud.mongodb.com%2Fv2%2F%3Cproject%3E%23%2Fsecurity%2Fadvanced) page displays. 2. Toggle the button next to Encryption at Rest using your Key Management to On. 3. (Optional) Toggle the button next to Search Node Data Encryption to On. You can optionally enable encryption for all data on [Search Nodes](https://www.mongodb.com/docs/search/deployment/deployment-options.md#std-label-what-is-search-node). You can also enable this feature later. To learn more, see [Enable Customer Key Management for Search Nodes.](https://www.mongodb.com/docs/atlas/security-kms-encryption.md#std-label-enable-search-node-encryption) 4. Enter your key management provider account credentials and provide an encryption key. 5. Click Save. 6. (Optional) Allow access to or from the Atlas control plane. To learn more, see [Allow Access From the Atlas Control Plane.](https://www.mongodb.com/docs/atlas/security-kms-encryption.md#std-label-atlas-ear-allow-access-via-control-plane) ## Allow Access From the Atlas Control Plane Depending on your KMS (Key Management Service) configuration, you might have to add the following IP addresses to your KMS (Key Management Service) access list so that Atlas can communicate with your KMS (Key Management Service): - Atlas control plane outbound IP addresses - Atlas cluster nodes' public IP addresses (data plane) - [Atlas Gateway IP addresses](https://www.mongodb.com/docs/atlas/setup-cluster-security.md#std-label-atlas-required-gateway-access) To enable communication between Atlas and KMS: 1. Send a GET request to the `returnAllControlPlaneIpAddresses` endpoint. The [API endpoint](https://www.mongodb.com/docs/api/doc/atlas-admin-api-v2/operation/operation-listcontrolplaneipaddresses) returns a list of inbound and outbound Atlas control plane IP addresses in CIDR categorized by cloud provider and region. To learn more, see the prerequisites for managing customer keys with [AWS](https://www.mongodb.com/docs/atlas/security/aws-kms-over-public-network.md#std-label-aws-ksm-prereqs), [Azure](https://www.mongodb.com/docs/atlas/security/azure-kms-over-public-network.md#std-label-azure-kms-prereqs), and [GCP.](https://www.mongodb.com/docs/atlas/security-gcp-kms.md#std-label-gcp-kms-prereqs) 2. Add the returned outbound IP addresses to your cloud provider's IP access list. See the prerequisites for managing customer keys with [AWS](https://www.mongodb.com/docs/atlas/security/aws-kms-over-public-network.md#std-label-aws-ksm-prereqs), [Azure](https://www.mongodb.com/docs/atlas/security/azure-kms-over-public-network.md#std-label-azure-kms-prereqs), and [GCP](https://www.mongodb.com/docs/atlas/security-gcp-kms.md#std-label-gcp-kms-prereqs) for more information. ## Enable Customer Key Management for an Atlas Cluster After you [Configure Atlas with Customer Key Management](https://www.mongodb.com/docs/atlas/security-kms-encryption.md#std-label-atlas-configure-kms), you must enable customer key management for each Atlas cluster that has data that you want to encrypt. **Note:** You must have the [`Project Owner`](https://www.mongodb.com/docs/atlas/reference/user-roles.md#mongodb-authrole-Project-Owner) role to enable customer key management for clusters in that project. For new clusters: 1. Enable cluster encryption. Toggle the Manage your own encryption keys setting to Yes on the cluster configuration form. 2. Review and apply your changes. Click Review Changes. Review your changes, then click Apply Changes to deploy your cluster. 3. Optional: Add IP addresses from the new cluster nodes. Depending on your Key Management configuration, you may have to add Atlas cluster node IP addresses to your cloud provider KMS access list, so that the cluster can communicate with your KMS. To enable communication between the cluster and KMS: Send a GET request to the `ipAddresses` endpoint. The [returnAllIpAddresses API endpoint](https://www.mongodb.com/docs/atlas/reference/api-resources-spec/v2/#tag/Projects/operation/returnAllIpAddresses) returns a list of IP addresses from the new cluster nodes, similar to the following: ```json { "groupId": "xxx", // ObjectId "services": { "clusters": [ { "clusterName": "Cluster0", "inbound": [ "3.92.113.229", "3.208.110.31", "107.22.44.69" ], "outbound": [ "3.92.113.229", "3.208.110.31", "107.22.44.69" ] } ] } } ``` Add the returned IP addresses to your cloud provider's IP access list. You must modify your IP access list before the provisioning plan rolls back. The cluster attempts provisioning for up to three days before the provisioning plan rolls back from IP access restrictions. See the prerequisites for managing customer keys with [AWS](https://www.mongodb.com/docs/atlas/security/aws-kms-over-public-network.md#std-label-aws-ksm-prereqs), [Azure](https://www.mongodb.com/docs/atlas/security/azure-kms-over-public-network.md#std-label-azure-kms-prereqs), and [GCP](https://www.mongodb.com/docs/atlas/security-gcp-kms.md#std-label-gcp-kms-prereqs) for more information. **Note:** If you need more time to update the IP access list, you can: - Provision the cluster without Encryption at Rest then enable it after you update the IP access list. - Configure a more inclusive IP access list on your cloud provider's Key Management Service, launch the cluster with Encryption at Rest, then modify the IP access list. For existing clusters: 1. In Atlas, go to the Clusters page for your project. If it's not already displayed, select the organization that contains your desired project from the Organizations menu in the navigation bar. If it's not already displayed, select your desired project from the Projects menu in the navigation bar. In the sidebar, click Clusters under the Database heading. The [Clusters](https://cloud.mongodb.com/go?l=https%3A%2F%2Fcloud.mongodb.com%2Fv2%2F%3Cproject%3E%23%2Fclusters) page displays. 2. Modify the cluster's configuration. For the cluster that contains data that you want to encrypt, click the , then select Edit Configuration. 3. Enable cluster encryption. Expand the Additional Settings panel. Toggle the Manage your own encryption keys setting to Yes. Verify the status of the Require Private Networking setting for your cluster. If you configured Encryption at Rest Using CMK (customer-managed key) (Over Private Networking) for Atlas at the project level, the status is Active. If you haven't configured any private endpoint connection for your project, the status is Inactive. 4. Review and apply your changes. Click Review Changes. Review your changes, then click Apply Changes to update your cluster. ## Enable Customer Key Management for Search Nodes When [configuring Customer Key Management for your project](https://www.mongodb.com/docs/atlas/security-kms-encryption.md#std-label-atlas-configure-kms), you can also enable encryption with Customer Key Management for your [Search Nodes](https://www.mongodb.com/docs/search/deployment/deployment-options.md#std-label-what-is-search-node). This ensures that your MongoDB Search and MongoDB Vector Search workloads, including indexes, are fully encrypted with your customer-managed keys. This feature is available across KMS (Key Management Service) providers. To enable Search Node Data Encryption with customer-managed keys: 1. In Atlas, go to the Advanced page for your project. If it's not already displayed, select the organization that contains your project from the Organizations menu in the navigation bar. If it's not already displayed, select your project from the Projects menu in the navigation bar. In the sidebar, click Database & Network Access under the Security heading. In the sidebar, click Advanced. The [Advanced](https://cloud.mongodb.com/go?l=https%3A%2F%2Fcloud.mongodb.com%2Fv2%2F%3Cproject%3E%23%2Fsecurity%2Fadvanced) page displays. 2. Enable Encryption at Rest with Customer Key Management or edit your configuration. If you haven't already configured Customer Key Management, follow the steps in [Configure Atlas with Customer Key Management.](https://www.mongodb.com/docs/atlas/security-kms-encryption.md#std-label-atlas-configure-kms) Otherwise, click the Edit button next to Encryption at Rest using your Key Management. 3. Toggle the button next to Search Node Data Encryption to On. 4. Click Save. After you enable Search Node Data Encryption at the project level, Atlas enables it at the cluster level when you [configure cluster encryption](https://www.mongodb.com/docs/atlas/security-kms-encryption.md#std-label-atlas-enable-cluster-encryption-at-rest) for any new or existing clusters with Search Nodes. Atlas encrypts the Search Nodes using the customer-managed key and rebuilds any search indexes. The length of this process depends on the size and number of your indexes. **Note:** If you disable Customer Key Management at the project level or if your customer-managed key becomes invalid, Atlas pauses your cluster and removes the Search Nodes, making database queries unavailable. When you re-enable Customer Key Management or fix your key configuration, Atlas unpauses your cluster, provisions new Search Nodes, and performs an [initial sync](https://www.mongodb.com/docs/search/performance/index-performance.md#std-label-troubleshoot-initial-sync). Search functionality resumes when the initial sync completes. ## Add Nodes to an Encrypted Atlas Cluster 1. Add nodes or shards to your replica set cluster or sharded cluster. You can [add electable nodes](https://www.mongodb.com/docs/atlas/cluster-config/multi-cloud-distribution.md#std-label-add-electable-node) to M10+ clusters or [increase the number of shards](https://www.mongodb.com/docs/atlas/scale-cluster.md#std-label-scale-cluster-shardNum) in your sharded cluster. 2. Optional: Add IP addresses from the new cluster nodes or shards. Depending on your Key Management configuration, you may have to add Atlas cluster node IP addresses to your cloud provider KMS access list, so that the cluster can communicate with your KMS. To enable communication between the cluster and KMS: Send a GET request to the `ipAddresses` endpoint. The [returnAllIpAddresses API endpoint](https://www.mongodb.com/docs/atlas/reference/api-resources-spec/v2/#tag/Projects/operation/returnAllIpAddresses) returns a list of IP addresses from the new cluster nodes or shards, similar to the following: ```json { "groupId": "xxx", // ObjectId "services": { "clusters": [ { "clusterName": "Cluster0", "inbound": [ "3.92.113.229", "3.208.110.31", "107.22.44.69" ], // List "outbound": [ "3.92.113.229", "3.208.110.31", "107.22.44.69" ] } ] } } ``` Add the returned IP addresses to your cloud provider's IP access list. You must modify your IP access list before the provisioning plan rolls back. The cluster attempts provisioning for up to three days before the provisioning plan rolls back from IP access restrictions. See the prerequisites for managing customer keys with [AWS](https://www.mongodb.com/docs/atlas/security/aws-kms-over-public-network.md#std-label-aws-ksm-prereqs), [Azure](https://www.mongodb.com/docs/atlas/security/azure-kms-over-public-network.md#std-label-azure-kms-prereqs), and [GCP](https://www.mongodb.com/docs/atlas/security-gcp-kms.md#std-label-gcp-kms-prereqs) for more information. ## Validate your KMS Configuration Atlas validates your KMS (Key Management Service) configuration: - When you add or update credentials. - Every 15 minutes. - On-demand with the [Encryption at Rest API endpoint.](https://www.mongodb.com/docs/api/doc/atlas-admin-api-v2/operation/operation-getgroupencryptionatrest) Atlas shuts down all [`mongod`](https://www.mongodb.com/docs/manual/reference/program/mongod.md#mongodb-binary-bin.mongod) and [`mongos`](https://www.mongodb.com/docs/manual/reference/program/mongos.md#mongodb-binary-bin.mongos) processes on the next scheduled validity check if one of the following conditions exist: - your key management provider credentials become invalid - someone deletes or disables your encryption key If Atlas *can't connect* to your key management provider, or if Atlas detects a probable false alarm, Atlas doesn't shut down your processes. The [`Encryption at Rest KMS network access denied`](https://www.mongodb.com/docs/atlas/reference/alert-conditions.md#mongodb-alert-Encryption-at-Rest-KMS-network-access-denied) alert is enabled by default for all new projects to communicate any KMS network access failures. You can [configure your alert settings.](https://www.mongodb.com/docs/atlas/alerts.md#std-label-alerts) If Atlas shuts down your clusters, the following events occur: - Atlas sends an email to the [`Project Owner`](https://www.mongodb.com/docs/atlas/reference/user-roles.md#mongodb-authrole-Project-Owner) listing all affected clusters. - The Clusters page reflects that Atlas disabled your clusters because of invalid Encryption at Rest settings. You can't read or write data on disabled clusters. You *can* submit updates to disabled clusters, such as disk and instance size changes. Atlas processes these changes once someone restores your encryption key. Atlas continues to perform maintenance and apply security patches. Disabled clusters retain all your data, so billing continues. **Note: Virtual Machine Power** While a cluster is disabled, Atlas doesn't stop the Virtual Machine (VM) the cluster is running on. Atlas may perform patches that reboot the server, but VM power isn't cycled. To regain access to your data: - [Update your credentials](https://www.mongodb.com/docs/atlas/security-kms-encryption.md#std-label-atlas-configure-kms) if they have changed since configuring Atlas with Customer Key Management. - [Restore your key](https://www.mongodb.com/docs/atlas/security-kms-encryption.md#std-label-atlas-restore-deleted-kms-key) if it has been disabled or deleted. ![The Try Again button is to the right of the Customer Master Key ID field in Atlas Advanced Security settings](/images/encryptionatrest-try-again.png) After updating your configuration, click Try Again to validate it. If you don't, Atlas validates on its next scheduled check. All `mongod` and `mongos` processes restart after Atlas determines your configuration to be valid. **Warning:** If your key was deleted, restore that key to regain access to your clusters. You can't change a key or disable Encryption at Rest using Customer Key Management without a valid key. ## Restore a Deleted Key To restore a deleted key, see your key management provider's documentation: - **AWS KMS:** [Delete customer master keys](http://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys.html) - **Azure Key Vault:** [Recover deleted key](https://learn.microsoft.com/en-us/rest/api/keyvault/keys/recover-deleted-key/recover-deleted-key) - **GCP KMS:** [Destroy and restore key versions](https://cloud.google.com/kms/docs/destroy-restore) ## Data Validation KMS Usage For clusters with encryption at rest using customer-managed keys, Atlas [data validation](https://www.mongodb.com/docs/atlas/data-validation.md#std-label-data-validation) requires extra KMS (Key Management Service) access to decrypt data during validation checks. Data validation is enabled by default for all projects. You can [opt out](https://www.mongodb.com/docs/atlas/data-validation.md#std-label-data-validation-disable) if the extra KMS costs, requests, or security considerations don't align with your requirements. ### Key Management Service Usage When data validation is enabled, validation instances make more requests to your KMS (Key Management Service) to decrypt data from encrypted clusters. **Request Volume:** Atlas makes about one decrypt request per replica set member per hour during validation. A standard three-node replica set with a seven-day validation window generates about 500 more KMS requests. **Estimated Costs:** For most clusters, validation-related KMS costs are minimal. For current pricing, see your cloud provider's documentation. **Security Considerations:** - Validation instances appear as extra principals in your KMS audit logs. - If you use IP allowlists for your KMS (Key Management Service), you might need to add validation instance IP ranges to your allowlist. - Validation instances use the same customer-managed keys as your cluster nodes. For the current list of validation instance IP ranges, contact [MongoDB Support](https://support.mongodb.com/welcome). ### IP Allowlist Configuration for Encrypted Clusters Most KMS (Key Management Service) configurations don't require extra IP allowlist changes for data validation. However, if your KMS (Key Management Service) uses IP-based access controls (for example, Azure Key Vault with firewall restrictions), you must add validation instance IP ranges to your allowlist. Otherwise, validation fails. To configure IP allowlists for your KMS (Key Management Service): ### AWS KMS AWS (Amazon Web Services) KMS (Key Management Service) typically allows access by IAM role. No additional IP allowlist configuration is required for validation instances if your IAM policy permits the Atlas role. To learn more about data validation, see [Data Validation for Cluster Consistency.](https://www.mongodb.com/docs/atlas/data-validation.md#std-label-data-validation) ## Learn More - [Atlas Encryption at Rest Overview](https://www.mongodb.com/docs/atlas/security-encryption-at-rest-overview.md#std-label-atlas-encryption-at-rest-overview) - [Storage Engine and Cloud Backup Encryption](https://www.mongodb.com/docs/atlas/backup/cloud-backup/cloud-backup-encryption.md#std-label-encrypted-cloud-provider-snapshot) - [Access an Encrypted Snapshot](https://www.mongodb.com/docs/atlas/tutorial/access-encrypted-snapshot.md#std-label-access-encrypted-snapshot) - [Restore from a Snapshot Using Encryption at Rest](https://www.mongodb.com/docs/atlas/backup/cloud-backup/restore-from-ear.md#std-label-restore-from-ear)