After we have configured the authentication to verify that the users are who they claim they are when connecting to our MongoDB server, we need to configure the rights that each one of them will have in our database.
This is the authorization aspect of permissions. MongoDB uses role-based access control to control permissions for different user classes.
Every role has permissions to perform some actions on a resource.
A resource can be a collection/collections or a database/databases.
The command's format is as follows:
{ db: <database>, collection: <collection> }
If we specify "" (an empty string) for either db or collection, it means any db or collection. An example of this is as follows:
{ db: "mongo_books", collection: "" }
This would apply our action in every collection in the mongo_books database.
Similar to the preceding option, we can define the following:
{ db: "", collection: "" }
We define this to apply our rule to all of the collections across all of the databases, except for system collections, of course.
We can also apply rules across an entire cluster, as follows:
{ resource: { cluster : true }, actions: [ "addShard" ] }
The preceding example grants privileges for the addShard action (adding a new shard to our system) across the entire cluster. The cluster resource can only be used for actions that affect the entire cluster, rather than a collection or database (for example, shutdown, replSetReconfig, appendOplogNote, resync, closeAllDatabases, and addShard).
What follows is an extensive list of cluster-specific actions, and some of the most widely used actions.
The list of the most widely used actions is as follows:
- find
- insert
- remove
- update
- bypassDocumentValidation
- viewRole/viewUser
- createRole/dropRole
- createUser/dropUser
- inprog
- killop
- replSetGetConfig/replSetConfigure/replSetStateChange/resync
- getShardMap/getShardVersion/listShards/moveChunk/removeShard/addShard
- dropDatabase/dropIndex/fsync/repairDatabase/shutDown
- serverStatus/top/validate
Cluster-specific actions are as follows:
- unlock
- authSchemaUpgrade
- cleanupOrphaned
- cpuProfiler
- inprog
- invalidateUserCache
- killop
- appendOplogNote
- replSetConfigure
- replSetGetConfig
- replSetGetStatus
- replSetHeartbeat
- replSetStateChange
- resync
- addShard
- flushRouterConfig
- getShardMap
- listShards
- removeShard
- shardingState
- applicationMessage
- closeAllDatabases
- connPoolSync
- fsync
- getParameter
- hostInfo
- logRotate
- setParameter
- shutdown
- touch
- connPoolStats
- cursorInfo
- diagLogging
- getCmdLineOpts
- getLog
- listDatabases
- netstat
- serverStatus
- top
If this sounds too complicated, that's because it is! The flexibility that MongoDB allows for configuring different actions on resources means that we need to study and understand the extensive lists, as described previously.
Thankfully, some of the most common actions and resources are bundled in built-in roles.
We can use these built-in roles to establish the baseline of permissions that we will give to our users, and then fine-grain these based on the extensive list.