Incrementally enabling authentication

We have a sharded cluster that we want to enable authentication for. However, we would like to phase it in by creating an account and configuring it for a couple app servers running nodejs/mongoose. Once we are confident in the configs, then we want to deploy to all the app servers than enable authentication enforcement on the sharded cluster… is this possible? Any tips on how to enable authentication on a running mongodb cluster would be appreciated. Especially if the goal is zero downtime.

Hi @AmitG,

You can use the security.transitionToAuth configuration parameter (MongoDB 3.4+) to perform a rolling upgrade to enable authentication. There’s a tutorial in the documentation: Update Sharded Cluster to Keyfile Authentication (No Downtime).

The link I’ve provided is to the latest production version of MongoDB (currently 4.4), but if you are using an older version of MongoDB server please select the matching MongoDB manual version from the navigation near the top left of this tutorial page.

Regards,
Stennie

2 Likes

Thank you for this Stennie. Just to clarify, does this configuration only apply for internal connections between MongoD and MongoS instances? Or will this allow us to transitionToAuth between a nodejs client and MongoS instance as well?

HI @AmitG,

There are two key aspects of auth security:

The security.transitionToAuth setting makes Authentication optional and does not enforce Authorization (so all clients have full access):

A mongod or mongos running with security.transitionToAuth does not enforce user access controls. Users may connect to your deployment without any access control checks and perform read, write, and administrative operations.

The implication of transitionToAuth for client/driver connections is that:

  • clients connecting without authentication credentials have unrestricted access
  • clients connecting with valid authentication credentials have unrestricted access
  • clients connecting with invalid authentication credentials will receive an authentication failure

You can use this setting to transition your Node clients to using authentication, with the caveat that access control will not be enforced until you finish setting up your deployment and remove transitionToAuth.

I recommend testing out this admin scenario in a development/staging environment. I find mlaunch (an open source community tool) extremely convenient for standing up local test deployments.

For example, to create a single shard test cluster with access control and an initial user:

mlaunch init --shards 1 --repl --auth
launching: "mongod" on port 27018
launching: "mongod" on port 27019
launching: "mongod" on port 27020
launching: config server on port 27021
replica set 'configRepl' initialized.
replica set 'shard01' initialized.
launching: mongos on port 27017
adding shards. can take up to 30 seconds...
sent signal Signals.SIGTERM to 5 processes.
launching: config server on port 27021
launching: "mongod" on port 27018
launching: "mongod" on port 27019
launching: "mongod" on port 27020
launching: mongos on port 27017
Username "user", password "password"

Regards,
Stennie

1 Like

This is a perfect explanation. Also, thank you for the pointer to mlaunch!

1 Like