Role-Based Access Control (RBAC) in MongoDB

As more people get online in this digital age, there’s an increased need for defining permissions and roles to ensure security and manage access to applications and systems. Role-based access control is an authorization model used to control access to resources based on users' predefined roles. 

With MongoDB's RBAC model, actions are represented in the form of roles, which are assigned to the right users. For example, instead of assigning several individual permissions, you can assign a single role (e.g., dbAdmin), which automatically includes the defined set of permissions (e.g., read on collections in the database). This model makes it easy to manage user access in a scalable way.

Enabling RBAC in MongoDB

With the core RBAC model, access is denied by default, which means users cannot access resources without having a role. Users can be assigned multiple roles, and each role can have a specific set of privileges or permissions to access certain capabilities.

RBAC Core Concepts

Here are some of the key concepts you need to know about RBAC:

Users

In the RBAC model, a user is an entity that is granted one or more roles that determine the user's access to database resources and operations. A user won’t have access to a system if there are no role assignments. To get access to a system, users must authenticate and must be assigned at least one role.

Roles

MongoDB provides built-in roles and privileges for self-managed deployments as well as MongoDB Atlas. Some common built-in roles are read, readWrite, and dbAdmin/atlasAdmin roles. Database admin roles have higher privileges compared to any other database user roles, including the privilege to manage the privileges of other roles.

If these built-in roles cannot provide the desired set of privileges, MongoDB provides methods to create and modify user-defined roles.

A role is a set of privileges assigned to the user.

For example, a “read” role could have read-only privileges, an “admin” role could have read and write privileges, while the “owner” role can have read, write, and delete privileges to a particular item (a database, a document, etc).  A role grants privileges to perform the specified actions on resources. Each privilege is either specified explicitly in the role or inherited from another role, or both.

User-Defined Roles / Custom Roles

MongoDB provides a number of built-in roles that administrators can use to control access to a MongoDB system. However, if the existing roles cannot describe the specific privileges you want, you can define and assign new roles to users in a database - that’s a custom role. With the exception of roles created in the admin database, a role can only include privileges that apply to its database and can only inherit from other roles in its database.

To create a new role, use the db.createRole() method, specifying the privileges in the privileges array and the inherited roles in the roles array.

MongoDB uses the combination of the database name and the role name to uniquely define a role, and MongoDB stores all role information in the admin.system.roles collection in the admin database.

Example: This example creates a custom role (sales_attendant) that can only insert documents into the sales collection within the sales_db database.

use sales
db.createRole(
   {
     role: "sales_attendant",
     privileges: [
       {
         resource: { db: "sales_db", collection: "sales" },
         actions: [ "insert" ]
       }
     ],
     roles: []
   }
)

Built-in roles 

Built-in roles are pre-created roles assigned to users that allow them to perform operations such as read and write on collections in a database. Examples of built-in roles are read, write, readWrite, dbAdmin, and readAnyDatabase.

• read and readWrite (database-level access): These roles grant access to perform read-only or read/write operations, respectively, on all non-system collections within a specified database.
• dbAdmin: This role grants administrative rights necessary for managing a specific database, such as creating, dropping, and modifying indexes and collections. This is suitable for development teams or database maintenance scripts.
• clusterAdmin (operational access): This role is a high-privilege role mostly reserved for operations (DevOps/Ops) personnel. It grants permissions necessary for managing the entire MongoDB deployment, which includes creating periodic backups, configuring replica sets, and sharding.

Privileges (permissions)

Privileges are a set of actions (e.g., find, insert) that are allowed on a capability. For

example, if the capability is to “inform the customer about their current balance,” then the user privileges (let’s say the bank teller) could be read-only. If the capability is to increase the transactional limit of a bank account, the privileges could be read and write.

Inherited Privileges

A role can include one or more existing roles (including all the privileges). For example, a dbAdmin role may include read, write, and update roles(which can be individual roles) that come with its privileges.

Resources

A resource is a database, collection, set of collections, or the cluster. 

Implementing the Principle of Least Privilege

In modern database security, the Principle of Least Privilege (PoLP) is crucial. This principle states that every user should be assigned the minimum permissions necessary to perform their required tasks.

Here is an example of the best practice: Instead of using a global readWrite user, create application-specific users. For example, if your inventory service only interacts with the app_data database, the application user should only be granted readWrite access to that single database. This compartmentalization prevents a compromised service from gaining unauthorized access to other databases (like billing or users).

Code example: 

Creating a least-privilege user. This example creates a user (branch_manager) with read/write access limited strictly to the bank_data database.

use admin
db.createUser(
   {
     user: "branch_manager",
     pwd: passwordPrompt(),
     roles: [ 
       { role: "readWrite", db: "bank_data" }
     ]
   }
)

Best Practices

• Create and assign well-defined roles and policies in advance.
• Follow the principle of least privilege to ensure tight security.
• Use built-in roles when possible; audit assigned roles periodically to spot anomalies.