Video Transcript (English)

Once a user has authenticated, they have the ability to access resources within the system. Next is when authorization comes into play. We should authorize users to access only the resources they need to perform their jobs.

In this lesson, we'll cover how authorization works in MongoDB focusing on role-based access control (RBAC) . Then, we’ll learn how to create a custom role tailored to specific needs. Finally, we’ll use this custom role on a new database user.

Authorization is the process of determining the resources that a user can access and actions they can take in the system.

To do this, we use Role-Based Access Control, or RBAC. RBAC is a method for restricting system access to authorized users based on their roles. Roles are essentially collections of privileges granting the ability to perform specific operations.

With RBAC, you can assign users to roles that have specific privileges, clearly defining the exact actions permitted, such as reading or writing data. It's similar to how employees in a company have job titles with defined responsibilities.

For example, in a project team, you might have roles like 'Developer', 'Tester', and 'Project Manager'. Each role has distinct permissions, ensuring that users can only perform the tasks relevant to their role.

MongoDB makes this easy by providing a robust set of built-in roles to use. Let’s first look at three roles: clusterAdmin, readWriteAnyDatabase, and readAnyDatabase. While we'll only cover these three, there are many built-in roles you can choose from. Check out the MongoDB docs to learn more.

For instance, the clusterAdmin role includes privileges like performing administrative tasks across all databases, managing shards, and configuring database settings.

The readWriteAnyDatabase role, as its name suggests, allows users to perform both read and write operations on any database within the cluster.

Meanwhile, the readAnyDatabase role permits users to read data from all databases but doesn't allow any modifications.

MongoDB also provides superuser roles, such as userAdmin and dbOwner, which grant extensive privileges.

The userAdmin role allows management of user accounts and roles throughout the database, while the dbOwner role grants full administrative control over a specific database.

Due to the significant level of access these roles provide, it’s important to use them sparingly and only when absolutely necessary.

But what if you need more fine-grained control over what a DB user can access and do?

For instance, if a user only needs to read and write data from a specific database, they shouldn't have access to perform any other actions. This aligns with the principle of least privilege, which ensures that users only have access they need to fulfill their responsibilities.

MongoDB’s flexibility allows us to define these precise privileges. By creating a custom role, you can specify which actions the role will permit across multiple collections or databases, ensuring users have only the permissions they need.

Let’s create a custom role to analyze sales data from a database named catalog. We’ll limit the role so it can only read data from the appropriate collections. This role won't be able to change any data, like inserting or deleting data.

To start, switch to the database you want the role to be able to access. Custom roles can only include privileges and inherit from roles within their respective databases. For our example, we're using a database named 'catalog.' If your custom role needs access to multiple databases, create the role in the 'admin' database.

Next, we use the create role method on the desired database. Here, we pass in the custom roles configuration, starting with the name. It’s always a good idea to use a descriptive name to keep things organized and easy to read.

Next, let's define the privileges this role will have. We'll give this role the ability to run Find operations on the sales collection within the catalog database. We'll apply the same permission to the returns collection.

Last, we come to the roles field, which allows this role to inherit privileges from another role. For this specific role, we'll leave it empty because we only want it to read from the sales and returns collections.

With that complete, we can create our custom database user role.

Now, let’s shift our attention to creating a new database user that uses the custom role.

For this, we’ll create a database user in the admin database, providing the username and password for SCRAM authentication., We'll also supply the custom role in the roles field.

Great, now we can test out if our role is correctly set up by logging in with our new user and attempting to insert a document.

We’ll use mongosh to connect to our cluster via the admin database. In the connection string, we’ll include the new user with the custom role.

Once we've successfully connected, let's switch to the catalog database.

Ok, let’s try inserting a test document into the sales collection to see what happens. Remember, we just wanted this user to have read privileges to the sales and returns collections.

When we run the command, we receive an error. It's not often that getting an error is a good sign, but in this case it is. The error is telling us that our database user is not authorized to perform an insert operation on the given collection.

This is exactly what we wanted to happen since this user is only allowed to read from the sales and returns collections.

This was just a small sample of the different roles and privileges available for database users. For a full list, make sure you check out the MongoDB documentation.

Awesome work. We've created a custom role and given a database user the authorization to access specific resources in our MongoDB Cluster.

Let's take a moment to recap what we've learned about database user authorization in MongoDB

We began by discussing the roles and privileges available to database users, highlighting both built-in roles and superuser roles, and emphasizing the importance of using them with caution.

We then explored the need for more precise access control, which led us to the creation of custom roles that grant specific privileges tailored to our needs.

Last, we walked through a code example demonstrating how to create a custom role and assign it to a new user.