Guidance for Atlas Authorization

MongoDB Atlas supports a variety of authorization methods to ensure robust access to resources. Atlas requires all users to authenticate. Once the user is authenticated, authorization determines the user's access to resources.

When implementing Atlas authorization, you must use Role-Based Access Control (RBAC). Using an Identity Federation Provider's groups with RBAC simplifies management.

The following recommendations apply to both workforce (human) and workload (application) users in all deployment paradigms.

Recommendations for Authorization: Single-Region and Multi-Region

Single-Region Deployment Recommendations

Recommendations that apply only to deployments in a single region

Singe-region deployments have no unique considerations for authorization. See the next section for "All Deployment Paradigm Recommendations".

Multi-Region and Multi-Cloud Deployment Recommendations

Recommendations that apply only to deployments across multiple regions or multiple cloud providers

Multi-region and multi-cloud deployments have no unique considerations for authorization. See the next section for "All Deployment Paradigm Recommendations".

All Deployment Paradigm Recommendations

The following recommendations apply to all deployment paradigms.

RBAC and Predefined Roles

Atlas uses Role-Based Access Control (RBAC) to simplify management of user authorization. Atlas includes predefined user roles that provide specific levels of access commonly needed for managing the Atlas with the UI and APIs. To simplify management, you can then map the roles to to IdP groups.

For connecting to Atlas clusters, use fine-grained custom database roles to provide granular scoping based on the access required for the role to perform its function. This approach enables you to follow the principle of least privilege.

Note

You should always restrict access by assigning the lowest-needed RBAC roles. You should also use domain restrictions.

There are two levels of roles that you can assign: organization-level and project-level.

Organization-Level Roles

Organization-level roles are used by service accounts to automate tasks such as creating new projects, managing IAM, and billing. They may also be used for platform team members.

The Organization Owner role should be heavily restricted and not assigned to a human, as it has the ability to change organization-wide settings and delete configurations. This role should be assigned to a service account which you use only to initially set up and configure the organization. Minimize configuration changes after the initial creation. To avoid account lockouts, you can create the following items:
- SAML Organization Owner group with Just-in-Time Access.
- Service account with the Organization Owner role. Keep it in a secure place with strong access management for break-glass emergency scenarios.
The Organization Member role should be for admins on the operations and platform team that can view settings and configuration for the organization.
The Organization Project Creator role should be a programmatic service account used to create projects on behalf of new applications for development and product teams.
The Organization Billing Admin role should be a programmatic service account used to pull invoices programmatically from the Billing API and feed them into your FinOps tool. This same service account should have access to all linked organizations for which it is responsible for reporting usage.

Project-Level Roles

Project-level roles are for the development, test, and product teams that are responsible for application development and maintenance. As with organization-level roles, you should always follow the principle of least privilege. For example, the Project Owner role should only be used for governance enforced by the operations and provisioning team. Because a Project Owner can create and delete clusters, you should assign this role to a programmatic service account unless you are working in a sandbox environment.

To learn more about project-level roles, see:

Federated Identity Providers

By integrating Atlas with a federated identity provider, you can use just-in-time provisioning by mapping identity provider groups to Atlas roles. This streamlines access management and ensures secure and organized role assignments throughout the platform. You can grant access programmatically based on the provisioning process of your orchestration layer.

You should use a modern Federated Identity Provider (FIP) that provides SSO, such as Azure Entra ID, Okta, or Ping Identity. This makes the authorization process more secure and supports the flexibility needed to programmatically assign IdP groups to Atlas roles. You should restrict access to your company's domain, which prevents users from logging into Atlas when they are not authorized for access.

To learn more about mapping roles to Federated Identity provider groups, see Role Mapping Process.

Just-in-Time Access

Atlas also supports creating temporary database users that automatically expire after the predefined times. A user can be created for 6 hours, 1 day, or 1 week.

To learn more, see Configure Database Users.

Back

Authentication

Data Encryption