What Is MongoDB Authorization?
MongoDB is a document-oriented NoSQL database that can store large amounts of data. Unlike traditional relational database management systems (RDBMS), MongoDB uses collections and documents instead of tables and rows.
MongoDB authorization is a MongoDB security process that lets administrators define which authenticated users should have access to which resources, and what operations they should be allowed to perform on the resources. MongoDB provides extensive authorization features including role-based access control (RBAC), LDAP authorization, and dynamic field level security.
In this article:
MongoDB Authorization Features
MongoDB has multiple features that allow organizations to control user access to database information.
Role-Based Access Control (RBAC)
In an RBAC authorization system, permissions are assigned to roles and roles are assigned to users. MongoDB provides predefined roles that support regular user and administrator database privileges. These include dbAdmin, dbOwner, clusterAdmin, and readWrite.
Administrators can further customize roles to assign fine-grained permissions to users based on data access and processing requirements.
Delegating roles across teams simplifies account configuration and maintenance. This ensures that policies are applied consistently across specific data processing functions within the organization. MongoDB provides the ability to specify user permissions at database and collection level granularity.
The auditing capabilities of MongoDB Enterprise Advanced allow organizations to define specific administrative actions for each role and log all actions. Organizations can then implement end-to-end operational management and maintain visibility into compliance and reporting operations.
LDAP Authorization
MongoDB supports authentication using the Lightweight Directory Access Protocol (LDAP). In addition, it lets you use LDAP to authorize users. MongoDB Enterprise Advanced lets you reuse existing user permissions stored in the LDAP server, mapping them to MongoDB roles, without having to re-create users in MongoDB.
When an LDAP server is configured for authorization, MongoDB allows user authentication via a number of methods, including LDAP, Active Directory, Kerberos, or X.509 without the need to store local user documents in the $external database.
The $external database is used when users store their credentials outside of MongoDB. When a user is successfully authenticated, MongoDB queries the LDAP server to get all groups to which the user belongs. The group is then converted to an equivalent MongoDB role.
LDAP authentication and authorization can be configured either through the command line or via the MongoDB Ops Manager UI.
Learn more: Read our guide to MongoDB authentication
Field-Level Security Using Read-Only Views
Developers and database administrators (DBAs) have several ways to implement field-level security.
DBAs can define unmaterialized views that expose only a subset of the data in the underlying MongoDB collection. For example, a view can exclude sensitive data fields, such as personal identifiable information (PII), from sales data and health records. This greatly reduces the risk of data breaches.
DBAs can also define aggregate views based on multiple collections or multiple existing views. The permissions granted to the view are separate from those granted to the underlying views or collections.
This makes it easy for organizations to meet compliance standards in regulated industries. By restricting access to sensitive data, data can be partitioned to reflect different access rights, without creating separate silos.
Additionally, views can show calculated fields without exposing underlying customer data or affecting the structure or content of the original source collection. Developers and DBAs can change the schema of the underlying collection without affecting the applications that use the view.
Views are defined using the standard MongoDB query language and aggregation pipeline, and can use:
- Including or excluding fields
- Masking field values
- Filtering
- Transforming schema
- Grouping, sorting, limiting, and joining of data using $lookup and $graphLookup to another collection
Log Redaction
MongoDB Enterprise Advanced can be configured with log redaction, to prevent potentially sensitive information such as personal identifiers from being written to the diagnostic log.
Developers and DBAs who access logs for database performance optimization or maintenance tasks can still view metadata such as error or operation codes, line numbers, and source file names. However, they cannot view personal data related to database events.
Enabling MongoDB Authorization Using RBAC
When you use RBAC to manage MongoDB access, users are assigned one or more roles that determine access to database resources and operations. This works as follows:
- Users can only access the system if an administrator assigns them a role.
- A role can contain one or more existing roles. In this case, the role inherits all permissions of the containing role.
- A role can also inherit permissions from other roles in the database. Roles created in the main admin database can inherit permissions from any database role.
MongoDB does not enable access control by default. DBAs can enable authorization using the –auth or security.authorization setting. When you enable authentication, this also automatically enables client authorization.
The MongoDB RBAC system uses the following authorization elements:
- Roles—grants permission to perform specified actions on a resource. Each permission can be explicitly assigned in one role, inherited from another, or both.
- Privileges—consists of allowed actions on a given resource.
- Resource—a database, collection, set of collections, or database cluster.
- Action—specifies the actions allowed for the resource.
MongoDB provides the following built-in roles, which you can use as-is or customize to your needs. You can also create new custom roles.
- Database user roles—read, readWrite
- Database administrative roles—dbAdmin, dbOwner, userAdmin
- Cluster administrative roles—clusterAdmin, clusterManager, clusterMonitor, hostManager
- Backup roles—backup, restore
- All-database roles—readAnyDatabase, readWriteAnyDatabase, userAdminAnyDatabase, dbAdminAnyDatabase
- Superuser role—root
For full details of the permissions each of these roles provides, see the official documentation.
Learn more: When does RBAC for Data Access Stop Making Sense?
Best Practices for MongoDB Authorization
Here are a few ways you can control access to MongoDB and improve data protection.
Grant Minimal Access to Entities
Provide users and service accounts the minimal database access they need to perform their functions. For example, if your application requires access to a logical database, you should restrict operations to that database and prevent access to other logical databases. This prevents malicious access, accidental access, and unauthorized data modification.
Group Common Access Privileges into Roles
Group entities into functional roles such as Developer, DBA, and Application Server. Role permissions are centrally managed and users can be added to or removed from roles as needed.
Roles simplify access control management. You can define sets of rules that apply to specific entity classes rather than individually for each user.
Control Which Actions an Entity Can Perform
When granting access to a database, consider the specific tasks or commands that each entity must have permission to perform.
For example, an application may require read/write access to a database, but a reporting tool may be limited to read-only access. Some users can insert new data into the database, but cannot update or delete existing data.
You should provide only a minimal set of permissions. If an attacker gains internal or external access, the credentials of the account they compromise will determine the level of damage they can do.
Control Access to Sensitive Data
Avoid data silos by limiting the permissions of individual fields based on security permissions. For example, some fields in a record should be accessible to all users in the database, while other fields containing sensitive information should be restricted to users with specific security privileges.
MongoDB Security with Satori
Satori’s data security platform enables a move from persistent permissions to JIT and need-to-know access to data.
To learn more:
