MongoDB is revolutionizing the world of ‘Database’ with its scalable, secure, replicating database. With MongoDB Enterprise Advanced customers get the ability to protect sensitive data with built-in encryption, and a convenient, standards-based interface for encryption key management based on the industry standard Key Management Interoperability Protocol, or KMIP. Here at Townsend Security we fully support the MongoDB Enterprise Advanced key management architecture, and have certified our Alliance Key Manager with MongoDB for both Intel and IBM Power architectures. And, Alliance Key Manager supports real-time key mirroring between one or more failover key servers to ensure that you never have a service interruption because of a failed connection to a key server!
Customers often ask us how to design a resilient key management strategy with MongoDB. So let’s look at three common scenarios.
First, a note about the use of a load balancer
The key management interface for MongoDB Enterprise Advanced only allows for the definition of one key management server. In order to define one or more failover key servers, the following scenarios use a load balancer to allow connecting to the failover key server. As their name implies, load balancers are normally used to balance workload requests among multiple servers, and are available in all platforms where MongoDB is supported (VMware, cloud, etc.). In this case you use a load balancer to provide a failover mechanism. Future versions of MongoDB may support the definition of multiple key servers in the MongoDB configuration file - if that occurs the use of a load balancer would not be required.
Scenario 1: A primary and one local secondary replication set
Imagine a simple implementation of MongoDB that involves one primary node and one secondary node to provide for data recovery and high availability. In this scenario the secondary node is deployed locally, or in the cloud across regions or availability zones, to the primary node. However, many MongoDB customers deploy the secondary node in a remote location to improve business recovery (see the next session).
Our goal in this scenario is to minimize or eliminate business interruption in the event the primary node fails or the key server for the primary node fails. To achieve this, we leverage the KMIP interface of MongoDB, a load balancer, and the key mirroring capabilities of Alliance Key Manager.
From the mongod.conf configuration file:
It is important to note that we don’t have to worry about redundancy and failover of MongoDB itself. This is very nicely handled by MongoDB. What we are striving to achieve is to implement an equally resilient interface to key servers.
The primary MongoDB node has a KMIP configuration that points to the load balancer. The load balancer itself is configured to connect to the primary key server and a failover key server. Note that the failover key server is actually the key server for the secondary MongoDB node. In this scenario each key server functions as the primary key server for the local node, and as the failover key server for the other node. In the event the primary key server cannot be reached due to a network failure or a key server failure, the load balancer uses the secondary key server.
Alliance Key Manager supports real-time key mirroring between one or more failover key servers. In the above scenario if the primary key server fails, the secondary key server will have a copy of the necessary encryption key. Note that Alliance Key Manager can mirror keys to more than one failover key server if needed.
The result of this type of implementation is a fully redundant key server deployment to protect both the primary MongoDB node as well as a fully redundant key server deployment for the secondary MongoDB node.
Scenario 2: A primary and multiple secondary replication sets
MongoDB customers often deploy more complex implementations with multiple secondary replication sets. This might be done to provide high performance for data ingestion (writes) into the primary node, while secondary nodes provide high performance query support and data redundancy. This type of scenario involves multiple nodes each with its own availability and recovery requirements. There can be many key managers involved in supporting this environment.
This scenario also leverages the use of load balancers to provide for automatic failover to a secondary key server. See the notes above about load balancers.
Primary and secondary MongoDB nodes have KMIP configurations that point to a load balancer. The load balancers are configured to connect to the defined failover key server when needed. Note that the failover key server is a different key server on another MongoDB node. In this scenario each key server functions as the primary key server for the local node, and as the failover key server for the other node. In the event the primary key server cannot be reached due to a network failure or a key server failure, the load balancer uses the secondary key server.
Alliance Key Manager supports real-time key mirroring between one or more failover key servers. In the above scenario if a key server fails, the secondary key server will have a copy of the necessary encryption key. Note that Alliance Key Manager can mirror keys to more than one failover key server if needed.
The result of this type of implementation is a fully redundant key server deployment to protect both of the MongoDB nodes.
Scenario 3: Complex, geographically distributed nodes
In complex MongoDB deployments that involve many geographically dispersed nodes, the same principles can be used to create highly redundant and resilient key management services. In this case the key managers are mirroring encryption keys and access policy across geographically dispersed locations. An encryption key management server and its backup mirrored server are available in all regions.
This scenario uses multiple key management servers to provide a very high level of resilience and redundancy. The primary MongoDB node runs a primary and secondary server in order to ensure a high level of hot failover support. The remote MongoDB nodes also run a primary and secondary key server for the same reason - to provide the maximum availability of the secondary MongoDB databases. It is also important to note that this key server deployment leverages the ability of Alliance Key Manager to replicate keys to more than one additional key server.
In this example there may be many geographic regions that participate in the MongoDB replication group. Note that it is possible that multiple MongoDB nodes can share one set of key servers. There is no requirement that each MongoDB node needs to have its own key server.
This more complex MongoDB configuration demonstrates the scalability of Alliance Key Manager to serve even very complex deployments of MongoDB. And you can start with a simple deployment of MongoDB and scale up the key management deployment as you grow MongoDB.
Summary
Hopefully the above scenarios will help you understand and plan your MongoDB encryption key management needs, and provide a template for the growth of your MongoDB platforms. With Alliance Key Manager it is easy to start with a simple MongoDB deployment and then scale it as you invest more deeply in MongoDB technology. You won’t paint yourself in a corner with your early configurations!
Important note about MongoDB Atlas:
At the time this blog was written there is no support for key management using KMIP for MongoDB Atlas, the cloud-based solution. The MongoDB Atlas service only supports AWS Key Management Service (KMS) and Azure Key Vault. Full encryption key management support is available by running MongoDB Enterprise Advanced as an AWS EC2 instance, Microsoft Azure virtual machine, or Google Cloud Platform virtual machine. We will update this blog if MongoDB Atlas implements the KMIP interface for key management.
Resources