In the previous blog, we discussed the importance of the SCRAM authentication mechanism and best practices for standalone deployments. However, for production environments, it is always recommended to configure a replica set rather than a standalone instance. Using MongoDB in standalone mode can increase the risk of data loss and downtime. Replica sets and sharded clusters offer better scalability, allowing you to distribute your workload across multiple nodes and handle increasing amounts of data and traffic.

To achieve these benefits, configuring a replica set is essential. But why not ensure your cluster is also secure?

If you want to make your cluster more secure, you should consider implementing the basic security features for an existing replica set without downtime. Below is the procedure to configure Keyfile authentication, also known as internal authentication, and to set up SCRAM authentication.

Terminologies

MongoDB Security Keyfile

A keyfile is a file used by MongoDB instances in a sharded cluster or replica set to store a shared secret. This secret is used for authenticating communication between the instances, ensuring secure interactions within the cluster.

Transition State

When a mongod instance is running with the --transitionToAuth option, it allows both authenticated and unauthenticated connections. During this transitional phase, users connected to the mongod can perform read, write, and administrative operations on any database, regardless of authentication status.

Enabling Internal Security and SCRAM Authentication

Creating a Root User

MongoDB should have a super user in the cluster which is the root user.

 
db.getSiblingDB("admin").createUser(
  {
    user: "rootUser",
    pwd: "StrongPassword_123",
    roles: ["root"]
  }
)
	

Note: The super user credentials should not be shared with all members.

It is important to create an admin user in the cluster even if the authentication is disabled.

Creating Application Users

The user has fewer privileges based on the use case with limited read or write access. It is one of the role-based access control mechanisms.

 
db.getSiblingDB("admin").createUser(
  {
    "user" : "readWriteUser",
      pwd: "StrongPaswword",
    roles: [ { "role" : "readWrite", "db" : "applicationDB" } ] 
  }
)
	

Generating and Configuring the Keyfile

If a node has the same keyfile as the cluster, it can be synchronized with the cluster. Otherwise, the node cannot be added to the replica set.

 
> openssl rand -base64 756 > 
> chmod 400 
> chown mongod:mongod 
	

Conditions for Enabling Internal Security

• The key's length must be between 6 and 1024 characters
• It supports the characters of the base64 set only
• The key file should have only 400 permissions.

FYI: MongoDB strips the white space characters in the key file.

Copy the key file for each replica member

Each member should have the same key file, then only internal authentication will be successfully configured.

Updating Replica Set Configuration

Add the security parameters in the configure file as follows in all the members of the replica set.

 
> vi /etc/mongod.conf
	

 
security:
  keyFile: 
  transitionToAuth: true
  authorization: enabled
replication:
  replSetName: 
	

Restarting Secondary and Primary Nodes

• Start the mongod services on each node.

 
> systemctl restart mongod
	

Note: Always the majority of members should be available, for the Primary availability. so better to do it one by one by validating the cluster health.

• Use the rs.stepDown() command in the MongoDB shell to step down the current primary and initiate an election for a new primary. Wait for about 10 seconds for the node to become a secondary.

 
> rs.stepDown()
	

Note: Wait for 10 seconds, then the node will be converted as secondary.

• Use the rs.status() command to check if a new primary has been elected. Look for the "primary" field in the output to verify the new primary node.

 
> rs.status() # 
	

• Connect to the primary node and shut it down gracefully using the shutdownServer() method. This ensures that the node is stopped safely.

 
> db.getSiblingDB('admin').shutdownServer()
	

• Exit the MongoDB shel

 
> exit
	

• Restart the mongod service on the primary node using the systemctl command or the appropriate command for your system.

 
> systemctl restart mongod
	

Note

The DB nodes have the "transitionToAuth" option enabled. Therefore, the DB deployment will accept users without authentication, although this is not recommended.

Remove the “transitionToAuth” option in the config file

Observe the cluster for some time and validate that the connection strings are properly updated at the application level.

To remove the transitionToAuth option from the MongoDB config file and restart the nodes one by one, follow these steps:

Config file

 
> vi /etc/mongod.conf
	

Remove the transitionToAuth option: Remove the transitionToAuth option from the security section of the config file.

 
security:
  keyFile: 
  authorization : enabled
replication:
  replSetName: 
	

With these meticulous steps, your MongoDB replica set can be fortified with robust security measures, ensuring data integrity and safeguarding against unauthorised access. Remember, a secure cluster is a resilient cluster!

Guarantee top-notch security for your MongoDB replica set! Partner with Mydbops for expert MongoDB Managed Services, Consulting, and Remote DBA expertise. Our team can streamline your security setup, optimize performance, and provide ongoing support. Contact Mydbops today for a free consultation!

{{cta}}