After we have configured authentication to verify that 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 or a database or any collections or any databases.
The command's format is:
{ db: <database>, collection: <collection> }
If we specify "" (empty string) for either db or collection it means any db or collection.
For example:
{ db: "mongo_books", collection: "" }
This would apply our action in every collection in database mongo_books.
Similar to the preceding, we can define:
{ db: "", collection: "" }
We define this to apply our rule to all collections across all databases, except 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, as 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 most widely used actions are:
- 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:
- 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 is because it is. The flexibility that MongoDB allows in 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 the 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.