The Three A’s of MongoDB Security – Authentication, Authorization & Auditing

The three A's of Mongodb security - Authentication, Authorization and Auditing

MongoDB has made impressive strides over the past 18 months. One of the MongoDB areas that’s seen the most significant improvement has been it’s security. Security is of paramout importance for a production database. Existing relational databases provide a number of knobs and controls to help the Database Administrator (DBA) manage the security of their database, and MongoDB is getting to a similar place as well. In this post, we’ll delve deeper into the security features in the areas of authentication, authorization and auditing.

  1. Authentication

    MongoDB offers a variety of mechanisms to authenticate the users connection to the database. Choose the mechanism that provides the best balance of security and management. Although optional, it’s recommended security practice that all production systems have authentication turned on.

    • Challenge Response Authentication (MongoDB-CR)

      This is the traditional username/password-based authentication. Users can be created at the scope of a database or the entire cluster. If a user only needs to access data in a particular database, it’s recommend to only create the user specific to that database. Cluster level access should be restricted for administrators.

    • X.509 Certificate Authentication

      Users can authenticate to their MongoDB database using X.509 certificate. In order to do this, the MongoDB server needs to have SSL enabled. By default, the community builds of MongoDB do not have SSL enabled. You need to roll out your own build or sign up to use the Enterprise edition.  You can create a user in MongoDB for each X.509 certificate with a unique subject. For more step-by-step instructions, refer to the MongoDB X.509 certificate setup.

    • Kerberos Authentication

      The Enterprise builds of MongoDB support authenticating using Kerberos, which is the industry standard for client server authentication. For example, if you’re an enterprise with an Active Directory installation, use can use the Kerberos authentication mechanism to authenticate your users. This avoids the hassle of managing usernames, passwords or certificates. Click here for instructions to integrate MongoDB with Active Directory.

  2. Authorization

    The Authorization system determines which operations users can perform once they’ve completed Authentication. MongoDB supports a Role-Based Access Control (RBAC) model. Each user is assigned specific roles which determine the operations they’re allowed to perform. MongoDB has a set of built-in roles and you can also create your own custom roles. Each role is assigned a set of privileges that pair resources with allowed operations on that resource. MongoDB provides built-in roles at the following scopes:

    • Database User Roles

      read, readWrite

    • Database Administrator (DBA) Roles

      dbAdmin, dbOwner, userAdmin

    • Cluster Administrator Roles

      clusterAdmin, clusterManager, clusterMonitor, hostManager

    • Backup and Restore Roles

      backup, restore

    • All Database Roles

      readAnyDatabase, readWriteAnyDatabase,userAdminAnyDatabase

    • Superuser Roles


    Refer to Built in roles documentation for a more detailed understanding of the roles that need to assigned to your users.

  3. Auditing

    MongoDB Enterprise 2.6 release added support for auditing. You can configure the MongoDB server to generate audit events for interesting MongoDB operations, like user login, DDL changes, replica set configuration changes, etc. This enables you to use your existing enterprise auditing tool to pick up and process the necessary events. For more information, refer to the list of MongoDB events that can be audited.

For more tips on improving the security of your MongoDB databases, please refer to our other blog post – 10 tips to improve your MongoDB security.