MongoDB Authorization Model - User-defined Roles Part 3
Introduction
In the last part of this series (Part 2), we discussed privileges and how they fit into the MongoDB authorization model. We also created the first of three users and assigned him a userAdminAnyDatabase role. In the third and final installment of this series, we will create the remaining two users and assign the appropriate privileges to them.
Prerequisites
Before we delve any further into our discussion, let’s go over a few prerequisites that need to be in place:
Make sure that MongoDB is properly installed and configured.
You should have at least a basic understanding of MongoDB’s built-in roles.
It’s best to have finished the second part of the series before proceeding with this article.
NOTE: The MongoDB version used throughout this article is v4.0.10
Creating the System Administrator Role
In the previous part of the series, we learned how to create a user and assign it a role of userAdminAnyDatabase. As the name of the role suggests, the user would be capable of creating users for any database.
Now we’ll be creating our next user, “raizel”– the system administrator. Let’s start by outlining the details of her role:
| Responsible For | Not Responsible For |
|---|---|
| Adding and removing of a replica set | Viewing of any collection data |
| Adding and removing of shard in sharded cluster | Listing of collections or databases |
To create this user based on the above table, we’ll need to authenticate ourselves using the security officer’s credentials. Remember that our security officer Yeshua’s account was created in the admin database, so we need to be in that database first.
Use the following commands to access the admin database:
1 | mongo |
1 | use admin |
We can perform the authentication using the following command.
1 | db.auth('yeshua','password') |
Before we move forward with creating the user and granting a role, we need to determine which built-in actions a system administrator will need to perform their tasks.
We know that the user should be able to add and remove shards or members of a particular replica set. After considering the typical duties of a system administrator, it’s clear that we should use the clusterManager role.
The clusterManager role provides both monitoring and management actions on a cluster. The config and the local databases that are used in sharding and replication will be accessible by a user within this role.
The table below shows the actions that can be performed on a cluster within the “clusterManager” role:
| addShard | appendOplogNote | applicationMessage | cleanupOrphaned |
|---|---|---|---|
| flushRouterConfig | listSessions | listShards | removeShard |
| replSetConfigure | replSetGetConfig | replSetGetStatus | replSetStateChange |
| resync |
To add the system administrator user “raizel”, use the following command:
1 | db.createUser({ user:'raizel', pwd: 'braces', roles: [{ role: 'clusterManager', db: 'admin' }]}) |
The output will look something like this:
1 2 3 4 5 6 7 8 9 | Successfully added user: { "user" : "raizel", "roles" : [ { "role" : "clusterManager", "db" : "admin" } ] } |
Let’s try using this new user’s credentials to login:
1 | db.auth('raizel','braces') |
In this case, the Mongo shell returns a value of “1”, which means we’re successfully authenticated using raizel’s credentials. Now we have a system administrator that can perform replica set configuration and cluster maintenance.
Creating the Developer’s Role
In this section, we’ll be creating a user account for the developer “david”. He will be accessing the ‘userAccounts’ database, and he’ll need the following actions to perform his duties properly:
| Responsible For | Not Responsible For |
|---|---|
| listing collections and databases | System Administrator’s Role |
| can perform CRUD operation | Security Officer’s Role |
Now that we have defined what our user needs to perform his tasks, let’s create this user with the role of readWrite. This role grants all the privileges of the read role as well as the following privileges:
| convertToCapped | createCollection | dropCollection |
|---|---|---|
| cerateIndex | dropIndex | insert |
| remove | renameCollectionSameDB | update |
1 | db.createUser({ user:'david', pwd: 'devSlacker', roles: [{ role: 'readWrite', db: 'admin' }]}) |
The output should look something like this:
1 2 3 4 5 6 7 8 9 | Successfully added user: { "user" : "david", "roles" : [ { "role" : "readWrite", "db" : "admin" } ] } |
Now let’s login using “david”‘s account credentials.
1 | db.auth('david','devSlacker') |
Mongo shell returns a value of “1”, which means we’re successfully authenticated using “david”‘s credentials.
Conclusion
Throughout our three-part series of articles, we talked about the MongoDB authentication model, built-in roles and user-defined roles. We were able to put these concepts into practice with the creation of three users, each one requiring a different role to allow them to perform their required tasks. With these examples in mind, you’ll be able to create users in your own MongoDB database and assign them the right roles for their needs.
Pilot the ObjectRocket Platform Free!
Try Fully-Managed CockroachDB, Elasticsearch, MongoDB, PostgreSQL (Beta) or Redis.
Get Started