WiredTiger Encryption at Rest with Percona Server for MongoDB

wired-tiger-encryptionEncryption has become an important function in the database industry, as most companies are taking extra care to keep their data safe. It is important to keep the data safe on disk as well as when it is moving in the network. This restricts any unauthorized access to the data. These two types of protection are known as encryption at REST for the data in storage, and encryption in TRANSPORT for the data moving in the network.

In upstream MongoDB software, data encryption at rest is available – but in the Enterprise version only. So those who are using the community version and want to implement encryption at rest have to use disk level encryption or file system encryption (like LUKS or DM-crypt) to achieve the same effect. This seems to solve for encrypting the data, but it comes with the added complexity of implementing and maintaining an extra set of operations. We have seen some customers face trouble after implementing the encryption at storage level due to the bugs in the encryption software.

Now the good NEWS!

Percona Server for MongoDB now provides WiredTiger encryption at rest with Percona Server for MongoDB 3.6.8-2.0 in BETA, and it is free to use. This useful feature applies encryption to only the MongoDB data, rather than full storage encryption. More importantly, it requires very minimal steps and is easy to implement when starting the DB. This is available only for the WiredTiger engine now, and can encrypt the data with the local key management via a keyfile. We expect that future releases will support third-party key management and vaults.

How to implement encryption:

Local key management Deprecation Note:

This article describes using the security.encryptionKeyFile option, which is not recommended if you can use Hashicorp Vault server for key management instead. Please see documentation or the blog post Using Vault to Store the Master Key for Data at Rest Encryption on Percona Server for MongoDB on how to use the server.vault.* options instead.”

The example below shows how to implement WiredTiger encryption at rest in Percona Server for MongoDB:

Add the encryption options below into mongod.conf:

By default, Percona Server for MongoDB uses the AES256-CBC cipher mode. If you want to use the AES256-GCM cipher mode, then use the encryptionCipherMode parameter to change it. In general, CBC and GCM cipher modes work differently. CBC is faster and GCM is safer (compared to each other). I found some interesting discussion and benchmark here and here.

Create your key with openssl as below:

Now start Percona Server for MongoDB:

How to confirm that you have enabled encryption at rest in Percona Server for MongoDB:

To check whether you have enabled the encryption successfully in the database, you can use the command below to check:

Search for the string “percona_encryption_extension_init” in your log file:

Hope this helped with how to encrypt your MongoDB data with the Percona Server MongoDB 3.6.8-2.0 package. We will let you know as we make future versions support third-party key management and vaults soon!

Photo by Wayne Chan on Unsplash

Share this post

Comments (6)

  • Nils

    Great feature addition, with one caveat:
    Other than being able to check of an item during an audit, what is the value of an encrypted system when you keep the key in plain-text on the hard drive? It’s a pattern I see rather often.. With local key management it’ll probably happen that the key is stored with the data and is available at rest rendering the whole encryption moot.

    This is great to measure the impact of encryption, but in production I’d rather have some other way to supply the key (even just obtaining it from a command instead would be enough).

    November 2, 2018 at 4:51 am
    • milsf

      Nils, the idea is that the key file is readable by only the process that runs mongodb (chmod 600). If you are using a non-login account, then only the root user can read the file. Yes, KMIP would be better, but if your root user is compromised, they probably have all the credentials they need to just do in and dump the data anyways.

      November 20, 2018 at 3:22 pm
  • Adam

    I have the same observation as Nils. Love the feature. Wish I had integration with a key provider, and I only mention that as a story for a future release.

    November 14, 2018 at 11:32 am
  • Preetham

    How does this work, when i am migrating the existing encrypted data on the Percona server to AWS document DB? i am quite confused here please explain me

    January 11, 2020 at 10:23 am
  • Sandeep

    I have setup new mongodb server with encryption enabled by following all the steps mentioned in https://www.percona.com/blog/2020/04/21/using-vault-to-store-the-master-key-for-data-at-rest-encryption-on-percona-server-for-mongodb/. I took dump of non-encrypted data using mongodump and restored on new server with encryption enabled using mongorestore. Now I am not sure how to verify whether restored data is encrypted or not. When I compare the data size it is almost same.

    September 11, 2020 at 12:21 pm

Comments are closed.

Use Percona's Technical Forum to ask any follow-up questions on this blog topic.