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.
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.
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?
There are two key aspects of auth security:
- Authentication: verifying the identity of a client (for example, using a username & password)
- Authorization (aka “access control”): verifying roles and privileges associated with an authenticated user.
security.transitionToAuth setting makes Authentication optional and does not enforce Authorization (so all clients have full access):
security.transitionToAuthdoes 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
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"
This is a perfect explanation. Also, thank you for the pointer to mlaunch!