Overview

By default, MongoDB does not enable authentication or access control. This document describes using Role-Based Access Control (RBAC) with  MongoDB, users and roles for developers and configurators along with how this model is used in deployed environments. It is also important to note that due to cost implications of required licenses to use LDAP/AD integration the security model will not cover direct LDAP/AD integration.

Intended Audience

The primary intended audience for this document is the DevOps who will be implementing the components. Other audiences include Architects, Project managers, developer leads, developers and configurators.

Layered Security Model

The aim is to provide a security framework that can be used to provide authentication, access control to Mongo and support the various tasks associated with support while also supporting developers and configurators. The intention is for all consumers of MongoDB services to leverage the same model with the only difference being what users are created in each deployment, local, on-premise or cloud. For example, for developers and configurators working locally, the design will seed a set of users against the required roles.

Levels of access

We have six layers of required access that reflects the different activities performed by the different groups:

1. SuperUser access – provides access to the operations and all the resources.
2. Application access –  provides access to the Catalyst database with readWrite.
3. Monitoring access –  provides access to MongoDB with clusterMonitor and listCollections so the monitoring agent can collect metrics.
4. Support access –  provides support access to the Catalyst database with read-only.
5. Datafix access –   provides access to the Catalyst database with readWrite.
6. User Administration access – Provides the ability to create and modify roles and users on the current database. 

By leveraging built-in roles, we define user roles to provide the required access control. 

Please see https://docs.mongodb.com/manual/reference/built-in-roles/ for more details on Mongo built-in roles.

Access Control – Roles

Here is an overview of the access roles and leveraged built-in roles

Super User Role

Super Users are assigned privileges that enable them to create collections and indexes on all databases. This role provides access to all operations and all the resources of the readWriteAnyDatabase, dbAdminAnyDatabase, userAdminAnyDatabase, clusterAdmin, restore, and backup roles combined. The intended users of this role are DBAs.

Application Server Role

This role is for use by the application and enables access to the Catalyst collection using readWrite. 
The built-in readWrite role provides the following actions on the Catalyst collection:

• collStats
• convertToCapped
• createCollection
• dbHash
• dbStats
• dropCollection
• createIndex
• dropIndex
• find
• insert
• killCursors
• listIndexes
• listCollections
• remove
• renameCollectionSameDB
• update

Application Datafix Role

This role enables users to run data fixes by creating, updating and deleting data inside the Catalyst collection and leverages the built-in readWrite role.

Support Role

This role is used the support team to run queries against the Catalyst collection on is READONLY.
The built-in read role provides read access by granting the following actions on the Catalyst collection:

• changeStream
• collStats
• dbHash
• dbStats
• find
• killCursors
• listIndexes
• listCollections

Monitoring Role

This role is a user-defined role and is used by the monitoring system to gather data about collections.

Run against mongo shell

db.createRole({role: "listCollections",privileges: [{resource: {db:"",collection:""},actions: ["listCollections"]}],roles: []})

More details on this role and it usage can be found here: https://docs.newrelic.com/docs/integrations/host-integrations/host-integrations-list/mongodb-monitoring-integration

User Administration Role

This role is a built-in role and is used by the operation team to manage uses. This built-in read role provides the ability to create and modify roles and users on the current database. Since the userAdmin role allows users to grant any privilege to any user, including themselves, the role also indirectly provides superuser access to either the database or, if scoped to the admin database, the cluster.

The userAdmin role explicitly provides the following actions:

• changeCustomData
• changePassword
• createRole
• createUser
• dropRole
• dropUser
• grantRole
• revokeRole
• setAuthenticationRestriction
• viewRole
• viewUser

It is important to understand the security implications of granting the role: a user with this role for a database can assign themselves any privilege on that database. Granting the userAdmin role on the admin database has further security implications as this indirectly provides superuser access to a cluster. With admin scope a user with the userAdmin role can grant cluster-wide roles or privileges including userAdminAnyDatabase.

Authentication Mechanisms

MongoDB supports a number of authentication mechanisms that clients can use to verify their identity. These mechanisms allow MongoDB to integrate into your existing authentication system.

MongoDB supports multiple authentication mechanisms:

• SCRAM (Default)
• x.509 Certificate Authentication.

In addition to supporting the aforementioned mechanisms, MongoDB Enterprise also supports the following mechanisms:

• LDAP proxy authentication, and
• Kerberos authentication.

Authentication – Users SCRAM (default)

Username Standards

These are the username format standards.

User	Username Format
Super User DBA	dba
Super Users	<firstname>.<lastname>.dba
Application User	catalyst
Datafix User	<firstname>.<lastname>.datafix
Support User	<firstname>.<lastname>.support
Monitor User	monitor
User Admin User	<firstname>.<lastname>.useradmin