Today, I want to clarify an important point about users authentication in a MongoDB sharded cluster because this seems to be misunderstood by some people.
In a such environment, there are two notions to understand about user authentication, especially when you are DBA:
- cluster authentication, that is, the authentication made when connected trough a “mongos” process.
- local authentication, that is, the authentication made when connected locally on a shard trough a “mongod” process.
To illustrate my words, I will use a simple cluster configuration as follows (replica set secondary members are not represented because they are not important for this topic):
- “config:2018”: the mongodb config server running on port 27018
- “mongos:27017”: the mongos running on port 27017
- “rs01:27018”: the primary server for shard rs01 running on port 27018
- “rs02:27018”: the primary server for shard rs02 running on port 27018
When you establish a connection to a MongoDB sharded cluster trough a “mongos” process, authentication informations are in fact checked in the “system.users” collection on the “admin” database of the config server.
Your shards (rs01 and rs02 in my example) doesn’t know anything about the user/password you use to connect.
In the same way: each time you create a new user connected trough mongos, its informations (username, password, roles, database) are only stored in the “system.users” collection on the “admin” database of the config server.
You can try it by yourself: create a new user trough mongos and try to connect to a shard (rs01 for example) with the same credentials: you will receive an “Authentication failed” error.
However, because users created via mongos are stored on the config server, you can use the same credentials to connect locally on config server and trough mongos… and reciprocally! Every users created when connected locally on a config server can be used to connect trough mongos.
When you establish a connection to a shard of a MongoDB sharded cluster trough a “mongod” process (rs01 or rs02 in my example), authentication informations are, this time, checked in the “system.users” collection on the “admin” database of the node you are trying to connect to.
In the same way as cluster authentication: each time you create a new user connected locally to a shard, its informations (username, password, roles, database) are only stored in the “system.users” collection from the “admin” database of the node you are connected to.
You can not use a user that you create this way to connect via a mongos process.
Furthermore, a user can be created only on a specific shard or have different password/privileges on each shard of your cluster (although this may cause problems for password management, but it’s your choice!). A user with the same name may also exist on your cluster (config server).
This is very important information for database administrators, because some operations must be done when you are connected locally (replicaset configuration, stepdown, …) and others when you are connected via mongos (sharding configuration, …). Some tools may also need that you create a user with the same name and same password on the cluster and locally on each shards of your configuration.
I hope you find this information useful. Stay tuned for more DBA stuff!