MongoDB Atlas takes care of full disk encryption automatically. It's enabled by default without any configuration needed. But what happens if your organization requires encryption at the database storage engine level as well? In this video, we'll explore the bring your own key or BYOK approach and walk you through enabling it in Atlas. We'll also verify that everything is working properly once your custom keys are in place. Let's get started. Atlas encrypts all cluster storage and snapshot volumes at rest by default. However, some organizations have strict security policies governing key management and life cycles, often making it necessary to bring your own keys for compliance. Luckily, Atlas lets you bring your own keys when configuring encryption at rest, giving you greater control and flexibility over your data security. With BYOK, you can manage your own encryption master key, which means you can enforce key rotation and revocation on your terms. This level of control helps you meet strict compliance and regulatory requirements. BYOK reduces the risk of unauthorized access by giving you the ability to respond quickly to security incidents by revoking or rotating keys as needed. Plus, Atlas integrates seamlessly with your preferred key management services, including AWS, Google Cloud, and Azure, making it easy to align with your organization's security policies. In short, BYOK gives you the option of greater control over encryption at rest when necessary. So how does it work? Atlas uses a method known as envelope encryption. In this process, your data encryption keys are encrypted with higher level keys called key encryption keys. Here's how it works. Atlas uses your customer managed key stored in an external KMS to encrypt each node's master key. These master keys are automatically rotated every ninety days to enhance security. The node's master key in turn encrypts each database encryption key or DEK, which is responsible for encrypting and decrypting the actual data in your database. If you revoke your customer managed key, Atlas will lose the ability to read the data because the master key remains encrypted. The master key can only be decrypted once you reinstate access with your managed key. Enabling the use of your own encryption keys provides you with complete control over the security of your data, ensuring it meets your organization's specific compliance and security requirements. Now let's configure this feature for your Atlas deployments. The first step is to decide which project within your Atlas organization will leverage your customer managed keys. Once you've set up and configured your encryption keys at the project level, you can then enable BYOK for individual clusters within that project. This allows you to customize key management on per cluster basis to meet the unique needs of each workload. To get started, we'll need an M10 or higher Atlas cluster and access to a supported KMS. For this example, we'll use AWS KMS with a symmetric key generated by the KMS. It's important to ensure that your chosen cloud provider grants Atlas access to this encryption key. Since we are using AWS, we'll also need an AWS Identity and Access Management (IAM) role that grants MongoDB Atlas the necessary permissions to perform "DescribeKey", "Encrypt", and "Decrypt" actions on your encryption key. We configured this role prior to this demonstration. And finally, since we'll use the Atlas Admin API to configure BYOK, we need to be authenticated and have the appropriate organization level permissions to make changes to your Atlas environment. But if you're unsure about any of these steps or need additional guidance, MongoDB's documentation provides comprehensive information to help you complete the setup. We'll begin by configuring access to the keys stored in the KMS for the project we selected using the Atlas Admin API in the terminal. We'll create a curl command passing in our Atlas API credentials. Next, we specify our headers to send and receive data in JSON. After that, we specify the encryption at rest endpoint. Make sure that the correct project ID is included in here. Now we define the fields we want to update. Since we're using AWS KMS, we need to update the "awsKms" field. If you use a different provider, you'll need to use their corresponding field. The "awsKms" field is an object with a few fields we need to update. First, set "enabled" to true. Next, specify the "roleId" that Atlas uses to access the KMS. After that, we specify the key (in the field "customerMasterKeyID") we want to use from the KMS. And finally, we provide the "region" of the AWS KMS. Let's run this command. Now that we've configured our Atlas project to use our cloud KMS, let's verify that our keys are being used. To do this, we'll use the Atlas Admin API to send a GET HTTP request to the encryption at rest endpoint. We must use the same project ID ("projectId") that we used earlier. After running the command, we should see a field for the KMS we used. In our case, we used "awsKms". Here, we can see that our key is indeed enabled and valid. Nice. Now that we have our AWS KMS configured with Atlas, the next step is to enable it for a specific cluster in our project. Before doing so, you should consider that every time you enable and disable your keys, it requires an initial sync on the cluster. Given this, we enable this during a slow workload period to avoid any potential issues. With that in mind, let's visit the Atlas UI to edit the configuration settings for the correct cluster. In configuration settings, under additional settings, locate manage your own encryption keys. Click to toggle on and select your provider from the drop down. Now that Atlas is using custom keys, let's explore key validation. Atlas automatically verifies your KMS key every fifteen (15) minutes and whenever you add or update credentials. For immediate verification, you can also trigger an on demand check using the Atlas Admin API. But what happens when a key becomes invalid? Atlas takes a protective approach. It shuts down all MongoD processes until you provide a valid key. When this occurs, the project owner receives a notification that lists every affected cluster. This way, your data remains safe even if key management issues arise. Let's quickly recap what we learned in this video. First, we learned that encryption at rest is enabled by default with Atlas and that Atlas automatically manages both master keys and database encryption keys. Atlas also allows you to bring your own keys. With BYOK, you manage your own encryption master key, which means you can enforce key rotation and revocation on your terms. This helps with adhering to regulations and organizational standards. Next, we learned how to configure an Atlas project to have access to our cloud KMS. Finally, we learned that Atlas validates keys every fifteen minutes or if the credentials were updated. If keys become invalid, Atlas will shut down all the affected clusters and notify the project owner.