Securing MongoDB with TLS
Rate this article
MongoDB has very strong support for TLS that can be granularly controlled. At minimum, TLS will let you validate and encrypt connections into your database or between your cluster member nodes. But MongoDB can also be configured to authenticate users using TLS client certificates instead of a password. This opens up the possibility for more client security using short-lived (16-hour) certificates. The addition of Smallstep step-ca, an open source certificate authority, makes it easy to create and manage MongoDB TLS certificates.
TLS certificates come with a lot of benefits:
- Most importantly, TLS makes it possible to require authenticated encryption for every database connection—just like SSH connections.
- Unlike SSH keys, certificates expire. You can issue ephemeral (e.g., five-minute) certificates to people whenever they need to access your database, and avoid having long-lived key material (like SSH keys) sitting around on people's laptops.
- Certificates allow you to create a trust domain around your database. MongoDB can be configured to refuse connections from clients who don’t have a certificate issued by your trusted Certificate Authority (CA).
- Certificates can act as user login credentials in MongoDB, replacing passwords. This lets you delegate MongoDB authentication to a CA. This opens the door to further delegation via OpenID Connect, so you can have Single Sign-On MongoDB access.
When applied together, these benefits offer a level of security comparable to an SSH tunnel—without the need for SSH.
Here’s an overview of TLS features that can be enabled in MongoDB:
- Channel encryption: The traffic between clients and MongoDB is encrypted. You can enable channel encryption using self-signed TLS certificates. Self-signed certificates are easy to create, but they will not offer any client or server identity validation, so you will be vulnerable to man-in-the-middle attacks. This option only makes sense within a trusted network.
- Identity validation: To enable identity validation on MongoDB, you’ll need to run an X.509 CA that can issue certificates for your MongoDB hosts and clients. Identity validation happens on both sides of a MongoDB connection:
- Client identity validation: Client identity validation means that the database can ensure all client connections are coming from your authorized clients. In this scenario, the client has a certificate and uses it to authenticate itself to the database when connecting.
- Server identity validation: Server identity validation means that MongoDB clients can ensure that they are talking to your MongoDB database. The server has an identity certificate that all clients can validate when connecting to the database.
- Cluster member validation: MongoDB can require all members of a cluster to present valid certificates when they join the cluster. This encrypts the traffic between cluster members.
- X.509 User Authentication: Instead of passwords, you can use X.509 certificates as login credentials for MongoDB users.
- Online certificate rotation: Use short-lived certificates and MongoDB online certificate rotation to automate operations.
To get the most value from TLS with your self-managed MongoDB deployment, you need to run a CA (the fully-managed MongoDB Atlas comes with TLS features enabled by default).
Setting up a CA used to be a difficult, time-consuming hassle requiring deep domain knowledge. Thanks to emerging protocols and tools, it has become a lot easier for any developer to create and manage a simple private CA in 2021. At Smallstep, we’ve created an open source online CA called step-ca that’s secure and easy to use, either online or offline.
Here are the main steps required to secure MongoDB with TLS. If you’d like to try it yourself, you can find a series of blog posts on the Smallstep website detailing the steps:
- Set up a CA. A single step-ca instance is sufficient. When you run your own CA and use short-lived certificates, you can avoid the complexity of managing CRL and OCSP endpoints by using passive revocation. With passive revocation, if a key is compromised, you simply block the renewal of its certificate in the CA.
- For server validation, issue a certificate and private key to your MongoDB server and configure server TLS.
- For client validation, issue certificates and private keys to your clients and configure client-side TLS.
- For cluster member validation, issue certificates and keys to your MongoDB cluster members and configure cluster TLS.
- Deploy renewal mechanisms for your certificates. For example, certificates used by humans could be renewed manually when a database connection is needed. Certificates used by client programs or service accounts can be renewed with a scheduled job.
- To enable X.509 user authentication, you’ll need to add X.509-authenticated users to your database, and configure your clients to attempt X.509 user authentication when connecting to MongoDB.
- Here’s the icing on the cake: Once you’ve set all of this up, you can configure step-ca to allow users to get MongoDB certificates via an identity provider, using OpenID Connect. This is a straightforward way to enable Single Sign-on for MongoDB.
Finally, it’s important to note that it’s possible to stage the migration of an existing MongoDB cluster to TLS: You can make TLS connections to MongoDB optional at first, and only require client validation once you’ve migrated all of your clients.
Ready to get started? In this Smallstep series of tutorials, we’ll take you through this process step-by-step.