Docs Menu
Docs Home
/
MongoDB Manual
/ /

Role-Based Access Control in Self-Managed Deployments

On this page

  • Enable Access Control
  • Roles
  • Users and Roles
  • Built-In Roles and User-Defined Roles
  • LDAP Authorization

MongoDB employs Role-Based Access Control (RBAC) to govern access to a MongoDB system. A user is granted one or more roles that determine the user's access to database resources and operations. Outside of role assignments, the user has no access to the system.

MongoDB does not enable access control by default. You can enable authorization using the --auth or the security.authorization setting. Enabling internal authentication also enables client authorization.

Once access control is enabled, users must authenticate themselves.

A role grants privileges to perform the specified actions on a resource. Each privilege is either specified explicitly in the role or inherited from another role or both.

Roles never limit privileges. If a user has two roles, the role with the greater access takes precedence.

For example, if you grant the read role on a database to a user that already has the readWriteAnyDatabase role, the read grant does not revoke write access on the database.

To revoke a role from a user, use the revokeRolesFromUser command.

Roles can impose authentication restrictions on users, requiring them to connect from specified source and destination IP address ranges.

For more information, see Authentication Restrictions.

A privilege consists of a specified resource and the actions permitted on the resource.

A resource is a database, collection, set of collections, or the cluster. If the resource is the cluster, the affiliated actions affect the state of the system rather than a specific database or collection. For information on the resource documents, see Resource Document on Self-Managed Deployments.

An action specifies the operation allowed on the resource. For available actions see Privilege Actions for Self-Managed Deployments.

A role can include one or more existing roles in its definition, in which case the role inherits all the privileges of the included roles.

A role can inherit privileges from other roles in its database. A role created on the admin database can inherit privileges from roles in any database.

You can view the privileges for a role by issuing the rolesInfo command with the showPrivileges and showBuiltinRoles fields both set to true.

You can assign roles to users during the user creation. You can also update existing users to grant or revoke roles. For a full list of user management methods, see User Management

A user assigned a role receives all the privileges of that role. A user can have multiple roles. By assigning to the user roles in various databases, a user created in one database can have permissions to act on other databases.

Note

The first user created in the database should be a user administrator who has the privileges to manage other users. See Enable Access Control on Self-Managed Deployments.

MongoDB provides built-in roles that provide set of privileges commonly needed in a database system.

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

Note

Starting in MongoDB 8.0, LDAP authentication and authorization is deprecated. LDAP is available and will continue to operate without changes throughout the lifetime of MongoDB 8. LDAP will be removed in a future major release.

For details, see LDAP Deprecation.

MongoDB Enterprise supports querying an LDAP server for the LDAP groups the authenticated user is a member of. MongoDB maps the Distinguished Names (DN) of each returned group to roles on the admin database. MongoDB authorizes the user based on the mapped roles and their associated privileges. See LDAP Authorization for more information.

Back

List