Secure MongoDB Self-Managed: AuthN and AuthZ / Manage Database Users and Custom Roles

6:46
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. 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 authorize 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, cluster admin, read write any database, and read any database. 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 cluster admin role includes privileges like performing administrative tasks across all databases, managing shards, and configuring database settings. The read write any database role, as its name suggests, allows users to perform both read and write operations on any database within the cluster. Meanwhile, the read any database role permits users to read data from all databases, but doesn't allow any modifications. MongoDB also provides superuser roles, such as user admin and DB owner, which grant extensive privileges. The user admin role allows management of user accounts and roles throughout the database, while the DB owner 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 action. 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 roles from 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 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 focus 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 stream, we'll include the new user with the custom role. Once we've successfully connected, let's switch to the catalog database. Okay. 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.