How to Achieve Data-at-Rest Encryption for MongoDB (Community Edition) Container Using eCryptfs
In this post, we will examine one method of encrypting data-at-rest, specifically how to achieve Data-at-Rest Encryption for MongoDB Community Edition (CE) containers through eCryptfs.
Our goal at Pentera was to implement a solution that prevents data discovery upon theft when the system is offline (e.g. if a host is stolen or someone is able to gain physical access to a host without permission). We wanted to find a solution that would allow us to secure our clients’ data and that even in the case of their hardware being stolen, the thieves would not be able to decipher nor understand the data without the right keys.
Data-at-Rest Encryption (DARE) is a form of encryption that provides such a solution, as it protects the data while it’s stored on the disk. It provides an extra layer of security for cloud and on-premise deployments.
When trying to implement encryption-at-rest to our MongoDB, we faced a new challenge. Following an evaluation of the requirements, we began searching for over-the-counter solutions.
We found a few, but they were extremely expensive and part of a larger bundle of services we did not require.
So we decided to try and build an in-house encryption solution instead. Here’s how we did it:
To get started, you will need:
- MongoDB Community Edition container image from Docker Hub or Microsoft Azure. You can find the most recent version here.
- In this post, I’ll be drawing on your previous knowledge of Docker containers, their volumes, and their use of the host’s kernel as we tackle this problem.
Encrypting your Data-at-Rest
Let’s take a look at your system’s components.
The host machine runs a container (in yellow), such as Docker. MongoDB is running in the container. In case the container shuts down, we have a volume/mounting between it and the host to maintain data persistence. By default, MongoDB uses the data/db directory on the container to communicate with and store its data in.
As a first step, we want to encrypt all the files on the host. In this way, data in the host will not be discovered if it is stolen.
Create a Persistent Volume and Mounting Point for the MongoDB
Let’s make sure that you have a volume between the host and the container, the container directory for the volume will be data/db
Then create a separate directory on the container to store decrypted data for MongoDB to read and write. In place of data/db, we’ll create a new directory called /mongodb-decrypted.
Then connect MongoDB with the new directory, to work with it instead of data/db.
MongoDB then flows data to the new directory, where it resides decrypted, and data will flow encrypted using eCryptFS from that directory to the directory used as a volume directory (data/db).
Creating Encrypted-Decrypted Mounting
Next, you’ll need to set the eCryptfs configuration. These will be used to encrypt/decrypt data flow between /data/db and /mongodb-decrypted and vise versa.
Before you can encrypt your data, you first have to create a mounting between the two directories on the container.
A mount point is a directory that is used to store the encrypted data. The mount point has to be created in the container of the mongoDB Community Edition (CE) and will be mounted later on using eCryptfs (a POSIX-compliant enterprise-class stacked cryptographic filesystem for Linux) to the mongoDB working directory set before. It’s important that you make sure that this directory exists before attempting to mount anything on it, otherwise you’ll get an error message.
By mounting the eCryptfs mount point directory to the MongoDB working directory on the MongoDB container, you’ll be able to generate an encryption flow from the database to the host.
Here is what the final result will look like:
Now you are ready to use a MongoDB container with at-rest encryption!
Encryption is a process of taking plain text data and converting it into an unreadable format. It provides confidentiality by preventing unauthorized access to information.
Data storage for MongoDB can be encrypted using eCryptfs, which is an open source file encryption utility, built in the Linux operating system and is part of the Linux kernel. As such, eCryptfs enables you to encrypt directories or individual files on your file system as it adds metadata to the file header, thus ignoring the file system type underneath, so files can be transferred whilst encrypted from one file system to another, with strong encryption so that only authorized users can access them.
Data-at-rest encryption can be used to protect your database in cloud and on-prem objects storage. The use of data-at-rest encryption is a critical security measure, especially when the infrastructure has multiple points of access.
Thanks to Alex Spivakovsky, our VP research for reviewing the security aspects of the solution, to Avishay Dana and the entire DevOps team for implementing this POC and embedding it into our product, and to other talented colleagues at Pentera for their contributions to the integration of Data-at-Rest Encryption for MongoDB.
To learn more about Pentera’s world class engineering efforts, behind-the-scenes hacking techniques, product developments and more, explore our Engineering Series.
Despite major investments in their security suites, organizations continue to be breached. Our Co-founder and CTO, Arik Liberzon, recently sat down with CyberNews to discuss the value of the adversarial perspective and where his inspiration from Pentera came from. Starting out, I arrived at the idea for Pentera and Automated Security Validation in a pretty...
After CentOS 8 was declared end-of-life (EOL), we had to find an alternative operating system (OS) for our on-premise solution, as did many other teams and organizations. Although our deployment is container-based, we still had to prepare the groundwork for different OS areas, from security patches and network modifications to installing required packages. We had...
In this article, we will show how it’s possible to use reflective loading to run Mimikatz while evading detection by Windows Defender. While this is a known attack method, recent improvements in windows defender blocked the method from working properly, so we needed to find a new way to handle dependencies. Read on to see...