MongoDB Authorization Model - The Built-in Roles

Introduction

In this tutorial will explain the authorization model for MongoDB. MongoDB follows a very simple and common authorization model known as Role Based Access Control, or RBA. As the name suggests, RBAC is where roles can be assigned to any given user with that particular role being assigned over a given namespace. There are several built-in roles for MongoDB and each role will be placed in a specific category for easier reference.

Prerequisites

MongoDB must be properly installed and configured before beginning.

NOTE: MongoDB v4.0.10 is used in the examples in this tutorial.

Understanding the Function of a Role in MongoDB

When explaining role based access control it is important to understand what a role actually is and does. Role is defined as “A group, or groups, of privileges, actions or resources that are granted to users over a given namespace, commonly referred to as a database“. A breakdown of the these terms follows:

1. Actions — All operations and commands that a user can perform in MongoDB.

2. Resources — The database, the collection, a set of collections or the cluster.

3. Privileges — An action against a given resource; grouping of multiple privileges is called a “role.”

Why MongoDB Uses Role Based Access Control

With a generally understanding of what roles are in the context of MongoDB, it is also important to understand why MongoDB uses RBAC.

RBAC grants the ability to provide different users in an organization’s database access in relation to what each user needs and the function each performs in the organization. In other words, RBAC provides the capability to isolate each responsibility for each user for each operational task.

MongoDB Built-in Roles

With an understanding of what roles are and why roles are used, the next step is to understand the built-in, or default, roles for MongoDB. These default roles are best understood by dividing the roles into categories.

The Database User roles category

The first category contains two of the most commonly used roles.

1. Read — This role grants the following privileges:

1. ReadWrite — This role grants all of the privileges of the read role as well as the following privileges:

The readWrite role demonstrates role inheritance, a powerful feature of the RBAC authorization system.

The Database Administration Roles Category

The next category is the database administration role.

1. dbAdmin role — This role grants the following privileges:

• The above privileges are tailored to a database administrator’s daily functions.

1. userAdmin — This role grants users within a database the following privileges:

• This role governs anything that involves user management or user administration.

1. dbOwner — This role inherits all of the privileges of readWrite, adAdmin and the userAdmin roles.

The All Database roles category

In the “All Databases roles” category the roles are almost the same, but grant privileges on different resources, as specified here:

1. readAnyDatabase — Inherits the privileges of the read role.
2. readWriteAnyDatabase — Inherits the privileges of the readWrite role.
3. userAdminAnyDatabase — Inherits the privileges of the userAdmin.
4. dbAdminAnyDatabase — Inherits the privileges of the dbAdmin.

• Each of these roles hold the named privileges, however, these roles now grant privileges for any database.

The Cluster Administration category

The Cluster Admin category allows actions across the entire cluster, replica set or a shared cluster.

1. clusterManager — This role provides both monitoring and management actions on a cluster. The config and the local databases that are used in sharding and replication are accessible by a user within this role.

• “clusterManager” provides the following action on a cluster:

• “clusterManager” also provides the following action on all databases in the cluster:

1. clusterMonitor — This is a read only role for monitoring the cluster and only grants stat reading privileges, as follows:

• clusterMonitor provides the following action on all databases in the cluster”

1. hostManager — This role provides the ability to monitor, just as the clusterManger role does, but also grants privileges to manage servers.

• This role provides us the following privileges:

1. clusterAdmin — This role inherits all three of the above roles:

2. clusterManager

3. clusterMonitor
4. hostManager

• This role also provides the dropDatabase function.

The Backup and Restore category

This category allows users to execute backups of the database and also restore the database from the backup.

1. Backup — This role provides minimal privileges that only allow for backup of the database.

• This role provides the following privileges:

1. Restore — This Role provides privileges to restore the database from the backup.

NOTE: This role is applicable only when restoring data with mongorestore without the –oplogReplay option.

• This role provides the following privileges:

The Superuser Roles category

This category allows a user to assume any and all roles.

1. dbOwner — When assigned to the admin database, this roles allows a user to assign any role on any database.

2. userAdmin — As this feature was inherited by the dbOwner role, this role also allows a user to assign any role they wish on any database when assigned to the admin database.

3. userAdminAnyDatabase — This role includes the userAdmin on the admin database that allows assignment of a role on any database.

4. root — This role provides access to all operations and resources of the following roles combined:

a. readWriteAnyDatabase

b. dbAdminAnyDatabase

c. userAdminAnyDatabase

d. clusterAdmin

e. backup and restore

NOTE: Exercise proper discretion when assigning this role to an individual as the user will have unlimited privileges.

The Internal role

The internal role has only the __system role (underscore underscore system role) that entitles the user to take any action against any object or resources in the database. As this role is only used by the server for special internal operations, this permission should not be given to a user except under the most extraordinary circumstances.

Conclusion

This tutorial discussed the Mongodb Authorization Model and the model’s “built-in roles”. The discussion included explaining the function of a role in MongoDB, why MongoDB uses RBAC and the Built-in Roles and the category for each role. Remember never to grant internal role privileges to a user, except under very special circumstances, as this will give the user the ability to modify any part of any database.