{"id":1025,"date":"2026-06-09T08:45:54","date_gmt":"2026-06-09T08:45:54","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/?p=1025"},"modified":"2026-06-09T08:45:55","modified_gmt":"2026-06-09T08:45:55","slug":"mongodb-the-complete-mongodb-atlas-authentication-authorization-tutorial","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/mongodb-the-complete-mongodb-atlas-authentication-authorization-tutorial\/","title":{"rendered":"MongoDB: The Complete MongoDB Atlas Authentication & Authorization Tutorial"},"content":{"rendered":"\n

MongoDB Atlas security becomes simple once you stop treating \u201cAtlas access\u201d and \u201cdatabase access\u201d as one thing.<\/p>\n\n\n\n

They are two different systems<\/strong>:<\/p>\n\n\n\n

Atlas access        = Who can manage Atlas?\nDatabase access     = Who can connect to MongoDB and read\/write data?\n<\/code><\/pre>\n\n\n\n
MongoDB\u2019s own docs make this separation clear: Atlas users access the Atlas application<\/strong>, while database users access MongoDB databases<\/strong>. Atlas Admin API access also does not<\/strong> allow reading or writing cluster data; for that, a client must authenticate to the cluster as a database user with the right roles. (MongoDB<\/a>)<\/p>\n\n\n\n
\n\n\n\n
1. Big Picture: The Two Security Planes<\/h1>\n\n\n\n
MongoDB Atlas has two major security planes.<\/p>\n\n\n\n
Control Plane: Atlas Management Access<\/h2>\n\n\n\n
This is for managing Atlas itself.<\/p>\n\n\n\n
Examples:<\/p>\n\n\n\n
Create organization\nCreate project\nCreate cluster\nCreate database users\nManage backups\nManage IP access list\nManage private endpoints\nManage alerts\nUse Atlas UI\nUse Atlas Administration API\n<\/code><\/pre>\n\n\n\n
The identities here are:<\/p>\n\n\n\n
Atlas users\nTeams\nService accounts\nLegacy API keys\n<\/code><\/pre>\n\n\n\n
The permissions here are:<\/p>\n\n\n\n
Organization roles\nProject roles\n<\/code><\/pre>\n\n\n\n
Data Plane: MongoDB Database Access<\/h2>\n\n\n\n
This is for connecting to the actual database.<\/p>\n\n\n\n
Examples:<\/p>\n\n\n\n
Connect with mongosh\nConnect from application code\nUse MongoDB Compass\nRun find \/ insert \/ update \/ delete\nRead collections\nWrite documents\nCreate indexes\nRun aggregation\n<\/code><\/pre>\n\n\n\n
The identities here are:<\/p>\n\n\n\n
Database users\nApplication identities\nWorkload identities\n<\/code><\/pre>\n\n\n\n
The permissions here are:<\/p>\n\n\n\n
MongoDB database roles\nBuilt-in roles\nCustom database roles\nSpecific privileges\n<\/code><\/pre>\n\n\n\n
\n\n\n\n
2. The Most Important Diagram<\/h1>\n\n\n\n
flowchart TD\n    A[Human or Machine] --> B{What are they trying to access?}\n\n    B -->|Manage Atlas| C[Atlas Control Plane]\n    B -->|Read or write documents| D[MongoDB Data Plane]\n\n    C --> C1[Atlas User]\n    C --> C2[Team]\n    C --> C3[Service Account]\n    C --> C4[Legacy API Key]\n\n    C1 --> C5[Organization Role]\n    C2 --> C5\n    C3 --> C5\n    C4 --> C5\n\n    C5 --> C6[Project Role]\n    C6 --> C7[Can manage projects, clusters, users, backup, network, alerts]\n\n    D --> D1[Network Access Check]\n    D1 --> D2[Database Authentication]\n    D2 --> D3[Database Authorization]\n    D3 --> D4[Can read\/write database resources]\n\n    D2 --> D5[Database User]\n    D3 --> D6[MongoDB Role: read, readWrite, custom role, etc.]\n<\/code><\/pre>\n\n\n\n
Translation:<\/p>\n\n\n\n
Atlas role decides what you can do in Atlas.\nDatabase role decides what you can do inside MongoDB.\nNetwork access decides whether you can reach the cluster at all.\n<\/code><\/pre>\n\n\n\n
Tiny but deadly important.<\/p>\n\n\n\n
\n\n\n\n
3. Authentication vs Authorization<\/h1>\n\n\n\n
Authentication<\/h2>\n\n\n\n
Authentication answers:<\/p>\n\n\n\n
Who are you?\n<\/code><\/pre>\n\n\n\n
Examples:<\/p>\n\n\n\n
Atlas UI login with username\/password, SSO, MFA\nService account OAuth token for Atlas Admin API\nDatabase username\/password using SCRAM\nAWS IAM database authentication\nX.509 database authentication\nOIDC database authentication\nLDAP database authentication\n<\/code><\/pre>\n\n\n\n
Atlas supports several authentication mechanisms across UI, API, and database access, including service accounts for API access and database authentication options such as SCRAM, X.509, AWS IAM, LDAP, and OIDC\/OAuth-based approaches depending on the access type and setup. (MongoDB<\/a>)<\/p>\n\n\n\n
Authorization<\/h2>\n\n\n\n
Authorization answers:<\/p>\n\n\n\n
What are you allowed to do?\n<\/code><\/pre>\n\n\n\n
Examples:<\/p>\n\n\n\n
Can this user create a project?\nCan this user pause a cluster?\nCan this user create database users?\nCan this app read orders?\nCan this app write payments?\nCan this analyst read only reporting data?\n<\/code><\/pre>\n\n\n\n
Atlas uses RBAC for management authorization, and MongoDB uses role-based authorization for database-level privileges. MongoDB roles grant actions on resources, and those resources can be scoped as tightly as database or collection level. (MongoDB<\/a>)<\/p>\n\n\n\n
\n\n\n\n
4. Atlas Resource Hierarchy<\/h1>\n\n\n\n
Atlas resources are usually organized like this:<\/p>\n\n\n\n
flowchart TD\n    ORG[Organization] --> TEAM[Teams]\n    ORG --> USER[Atlas Users]\n    ORG --> SA[Service Accounts \/ API Keys]\n    ORG --> PROJECT[Project]\n\n    PROJECT --> CLUSTER[Cluster]\n    PROJECT --> NET[Network Access]\n    PROJECT --> DBACCESS[Database Access]\n    PROJECT --> BACKUP[Backups]\n    PROJECT --> ALERTS[Alerts]\n    PROJECT --> LOGS[Logs]\n    PROJECT --> CUSTOMROLES[Custom Database Roles]\n\n    CLUSTER --> DB1[Database: app_db]\n    CLUSTER --> DB2[Database: reporting_db]\n    DB1 --> C1[Collection: users]\n    DB1 --> C2[Collection: orders]\n    DB2 --> C3[Collection: daily_sales]\n<\/code><\/pre>\n\n\n\n
Organization<\/h2>\n\n\n\n
The organization<\/strong> is the top-level administrative boundary.<\/p>\n\n\n\n
It contains:<\/p>\n\n\n\n
Projects\nAtlas users\nTeams\nBilling settings\nOrganization-level service accounts \/ API keys\nOrganization roles\n<\/code><\/pre>\n\n\n\n
Typical organization-level roles include:<\/p>\n\n\n\n
Role<\/th>Meaning<\/th><\/tr><\/thead>
Organization Owner<\/td>Root-level organization access<\/td><\/tr>
Organization Project Creator<\/td>Can create projects<\/td><\/tr>
Organization Billing Admin<\/td>Can manage billing<\/td><\/tr>
Organization Billing Viewer<\/td>Can view billing<\/td><\/tr>
Organization Read Only<\/td>Can view organization settings, users, and projects<\/td><\/tr>
Organization Member<\/td>Can view organization settings\/users and only projects they belong to<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
An Organization Owner gets broad root-level organization access, including Project Owner access to all projects, organization administration, user\/database-user management, and the combined privileges of other organization roles. (MongoDB<\/a>)<\/p>\n\n\n\n
Project<\/h2>\n\n\n\n
A project<\/strong> is one of the most important security boundaries in Atlas.<\/p>\n\n\n\n
A project contains:<\/p>\n\n\n\n
Clusters\nDatabase users\nCustom database roles\nIP access list\nPrivate endpoint configuration\nBackups\nAlerts\nProject-level Atlas users \/ teams \/ service accounts\n<\/code><\/pre>\n\n\n\n
Most teams use projects to separate environments:<\/p>\n\n\n\n
dev project\nqa project\nstaging project\nprod project\n<\/code><\/pre>\n\n\n\n
That gives you clean boundaries:<\/p>\n\n\n\n
Developers can have broad access in dev.\nDevelopers can have limited access in staging.\nDevelopers can have read-only or no data access in prod.\nProduction apps get production-only database users.\nCI\/CD gets specific project-level service account roles.\n<\/code><\/pre>\n\n\n\n
\n\n\n\n
5. Atlas Users<\/h1>\n\n\n\n
An Atlas user<\/strong> is a human account that logs in to Atlas.<\/p>\n\n\n\n
Example:<\/p>\n\n\n\n
rajesh@example.com logs in to cloud.mongodb.com\n<\/code><\/pre>\n\n\n\n
An Atlas user can be granted:<\/p>\n\n\n\n
Organization roles\nProject roles\n<\/code><\/pre>\n\n\n\n
That user may be able to:<\/p>\n\n\n\n
View projects\nCreate clusters\nManage database users\nView metrics\nUse Data Explorer\nManage IP access list\nManage backups\nInvite users\n<\/code><\/pre>\n\n\n\n
But remember:<\/p>\n\n\n\n
Atlas user \u2260 MongoDB database user\n<\/code><\/pre>\n\n\n\n
An Atlas user may manage a database user, but that does not automatically mean the same human can connect to the database using that Atlas login.<\/p>\n\n\n\n
\n\n\n\n
6. Teams<\/h1>\n\n\n\n
A team<\/strong> is a group of Atlas users inside an organization.<\/p>\n\n\n\n
You use teams to avoid assigning project roles user-by-user.<\/p>\n\n\n\n
Example:<\/p>\n\n\n\n
Team: Backend Developers\nMembers:\n  - Alice\n  - Bob\n  - Rajesh\n\nProject: dev\nRole:\n  - Project Data Access Read\/Write\n\nProject: prod\nRole:\n  - Project Read Only\n<\/code><\/pre>\n\n\n\n
Teams are very useful for real companies because people join, move teams, or leave. Instead of changing every project manually, you update the team membership.<\/p>\n\n\n\n
flowchart LR\n    U1[Alice] --> T[Backend Team]\n    U2[Bob] --> T\n    U3[Rajesh] --> T\n\n    T --> P1[dev project: Data Access Read\/Write]\n    T --> P2[staging project: Read Only]\n    T --> P3[prod project: Read Only]\n<\/code><\/pre>\n\n\n\n
The Project Access Manager<\/strong> role can add or remove teams and manage team roles within a project. (MongoDB<\/a>)<\/p>\n\n\n\n
\n\n\n\n
7. Atlas Project Roles<\/h1>\n\n\n\n
Project roles control what someone can do inside a project<\/strong>.<\/p>\n\n\n\n
Common project roles:<\/p>\n\n\n\n
Project role<\/th>What it is for<\/th><\/tr><\/thead>
Project Owner<\/td>Full project administration<\/td><\/tr>
Project Cluster Manager<\/td>Edit, pause, and resume clusters<\/td><\/tr>
Project Cluster Creator<\/td>Create clusters<\/td><\/tr>
Project Access Manager<\/td>Manage project users, teams, API keys, service accounts<\/td><\/tr>
Project Database Access Admin<\/td>Manage database users and custom database roles<\/td><\/tr>
Project Network Access Manager<\/td>Manage access lists, VPC peering, PrivateLink\/private endpoint settings<\/td><\/tr>
Project Data Access Admin<\/td>Use Atlas UI Data Explorer with broad data permissions<\/td><\/tr>
Project Data Access Read\/Write<\/td>Use Atlas UI Data Explorer to view\/modify documents<\/td><\/tr>
Project Data Access Read Only<\/td>Use Atlas UI Data Explorer to view documents<\/td><\/tr>
Project Read Only<\/td>View project metadata, metrics, activity, users, roles<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
A very important nuance: Project Data Access roles are for Atlas UI data access, especially Data Explorer. They do not allow reading or writing data through the Atlas Administration API.<\/strong> MongoDB states this explicitly for Data Access Admin and Data Access Read\/Write roles. (MongoDB<\/a>)<\/p>\n\n\n\n
So:<\/p>\n\n\n\n
Project Data Access Read\/Write\n  \u2705 Can modify documents through Atlas UI Data Explorer\n  \u274c Cannot use Atlas Admin API to query documents\n<\/code><\/pre>\n\n\n\n
\n\n\n\n
8. Atlas Admin API Access<\/h1>\n\n\n\n
Atlas Admin API access is for automation.<\/p>\n\n\n\n
Use it for:<\/p>\n\n\n\n
Terraform\nCI\/CD\nPlatform engineering\nCluster provisioning\nDatabase user management\nNetwork access automation\nBackup automation\nAlert automation\nCompliance reporting\n<\/code><\/pre>\n\n\n\n
Modern Atlas Admin API authentication supports:<\/p>\n\n\n\n
Service accounts with OAuth 2.0 access tokens\nLegacy API keys using HTTP Digest authentication\n<\/code><\/pre>\n\n\n\n
MongoDB recommends service accounts instead of API keys<\/strong> for the Atlas Administration API, and marks API keys as a legacy authentication method. (MongoDB<\/a>)<\/p>\n\n\n\n
Service Accounts<\/h2>\n\n\n\n
A service account is a machine identity for the Atlas Admin API.<\/p>\n\n\n\n
It has:<\/p>\n\n\n\n
Client ID\nClient secret\nRoles\nOptional access list restrictions\nShort-lived access tokens\n<\/code><\/pre>\n\n\n\n
Service accounts use OAuth 2.0 client credentials. They can be assigned roles like users, but they cannot log in to the Atlas UI and cannot access cluster data. Service account tokens are valid for one hour according to MongoDB\u2019s docs. (MongoDB<\/a>)<\/p>\n\n\n\n
sequenceDiagram\n    participant CI as CI\/CD Pipeline\n    participant OAuth as Atlas OAuth Token Endpoint\n    participant API as Atlas Admin API\n    participant Atlas as Atlas Project\n\n    CI->>OAuth: Send client ID + secret\n    OAuth-->>CI: Return short-lived access token\n    CI->>API: Call API with Bearer token\n    API->>API: Check service account role\n    API->>Atlas: Create\/update Atlas resource\n<\/code><\/pre>\n\n\n\n
What Atlas API Can Do<\/h2>\n\n\n\n
Create clusters\nPause or resume clusters\nCreate database users\nUpdate IP access list\nConfigure backups\nRead project metadata\nManage alerts\nManage service accounts\n<\/code><\/pre>\n\n\n\n
What Atlas API Cannot Do<\/h2>\n\n\n\n
Read documents\nInsert documents\nUpdate documents\nDelete documents\nRun aggregation queries\nDump collection data\n<\/code><\/pre>\n\n\n\n
That last part matters a lot. Atlas Admin API can create a database user, but it does not magically become that database user. MongoDB explicitly says the Atlas Administration API does not provide access to data stored in clusters. (MongoDB<\/a>)<\/p>\n\n\n\n
\n\n\n\n
9. Database Access: The Data Plane<\/h1>\n\n\n\n
To access data in MongoDB Atlas, a client needs three things:<\/p>\n\n\n\n
1. Network path to the cluster\n2. Valid database authentication\n3. Database authorization role\n<\/code><\/pre>\n\n\n\n
Think of it as three locked doors:<\/p>\n\n\n\n
flowchart LR\n    APP[Application \/ Compass \/ mongosh] --> N{Network allowed?}\n    N -->|No| DENY1[Connection blocked]\n    N -->|Yes| A{Database authentication valid?}\n    A -->|No| DENY2[Authentication failed]\n    A -->|Yes| Z{Role allows operation?}\n    Z -->|No| DENY3[Unauthorized]\n    Z -->|Yes| OK[Operation succeeds]\n<\/code><\/pre>\n\n\n\n
A correct username\/password is not enough.<\/p>\n\n\n\n
A correct database role is not enough.<\/p>\n\n\n\n
You need all three.<\/p>\n\n\n\n
\n\n\n\n
10. Network Access<\/h1>\n\n\n\n
Before MongoDB even checks your database username\/password, Atlas checks whether your client can reach the cluster.<\/p>\n\n\n\n
Common network controls:<\/p>\n\n\n\n
IP access list\nTemporary IP access list entries\nVPC\/VNet peering\nPrivate endpoints \/ PrivateLink \/ Private Service Connect\nTLS\nFirewall rules\n<\/code><\/pre>\n\n\n\n
Atlas network security starts restrictive: database connections are blocked unless you explicitly allow inbound access through a public IP access list entry, peering\/private IPs, or private endpoints. Atlas also enforces mandatory TLS for database connections. (MongoDB<\/a>)<\/p>\n\n\n\n
IP Access List<\/h2>\n\n\n\n
An IP access list says:<\/p>\n\n\n\n
Only these IP addresses or CIDR ranges can connect to this project\u2019s clusters.\n<\/code><\/pre>\n\n\n\n
Example:<\/p>\n\n\n\n
203.0.113.10\/32        office IP\n10.20.0.0\/16           private network CIDR\n<\/code><\/pre>\n\n\n\n
Atlas project IP access list entries apply to all clusters in the project, and MongoDB documents that Atlas also supports temporary entries that expire within a configurable period. (MongoDB<\/a>)<\/p>\n\n\n\n
Private Endpoint<\/h2>\n\n\n\n
A private endpoint lets your application connect to Atlas without sending traffic over the public internet.<\/p>\n\n\n\n
Recommended production pattern:<\/p>\n\n\n\n
Application VPC\/VNet\n  -> Private endpoint\n  -> Atlas cluster\n<\/code><\/pre>\n\n\n\n
MongoDB recommends private endpoints for staging and production projects because they reduce the network trust boundary and are usually easier than managing large IP allowlists at scale. (MongoDB<\/a>)<\/p>\n\n\n\n
Control Plane vs Data Plane IP Lists<\/h2>\n\n\n\n
There are two different IP-list concepts:<\/p>\n\n\n\n
Atlas API\/service account IP access list\n  Controls where Atlas API calls can come from.\n\nProject cluster IP access list\n  Controls where database connections can come from.\n<\/code><\/pre>\n\n\n\n
MongoDB explicitly distinguishes API\/programmatic access IP access lists from project data-plane IP access lists for cluster connections. (MongoDB<\/a>)<\/p>\n\n\n\n
\n\n\n\n
11. Database Users<\/h1>\n\n\n\n
A database user<\/strong> is the identity used to connect to the MongoDB cluster.<\/p>\n\n\n\n
Example connection string shape:<\/p>\n\n\n\n
mongodb+srv:\/\/app_user:<password>@cluster-name.mongodb.net\/app_db\n<\/code><\/pre>\n\n\n\n
The database user is usually created under:<\/p>\n\n\n\n
Atlas UI -> Project -> Database & Network Access -> Database Users\n<\/code><\/pre>\n\n\n\n
Or by:<\/p>\n\n\n\n
Atlas CLI\nAtlas Administration API\nTerraform\nAtlas Kubernetes Operator\n<\/code><\/pre>\n\n\n\n
MongoDB says Atlas database users must be managed through Atlas-supported tools such as the Atlas UI, Atlas CLI, Atlas Administration API, or supported integrations; otherwise Atlas may roll back manual user modifications. (MongoDB<\/a>)<\/p>\n\n\n\n
\n\n\n\n
12. Database User Authentication Methods<\/h1>\n\n\n\n
Atlas supports multiple database user authentication methods.<\/p>\n\n\n\n
Method<\/th>Best for<\/th><\/tr><\/thead>
Password \/ SCRAM<\/td>Simple development and test setups<\/td><\/tr>
AWS IAM<\/td>Apps running in AWS, secret reduction<\/td><\/tr>
X.509<\/td>Certificate-based authentication \/ mTLS style access<\/td><\/tr>
LDAP<\/td>Enterprise directory integration<\/td><\/tr>
OIDC \/ OAuth 2.0<\/td>Modern identity federation for workforce\/workload access<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
MongoDB currently recommends service accounts for Atlas API access, while database authentication can use mechanisms such as SCRAM, AWS IAM, X.509, LDAP, and OIDC depending on your cluster and identity setup. MongoDB\u2019s architecture guidance also says SCRAM is supported but recommends it primarily for development and test environments; for stronger production posture, prefer identity-based or certificate-based methods where appropriate. (MongoDB<\/a>)<\/p>\n\n\n\n
\n\n\n\n
13. Database Authorization: Roles<\/h1>\n\n\n\n
Database authorization is role-based.<\/p>\n\n\n\n
A database user gets one or more roles.<\/p>\n\n\n\n
A role says:<\/p>\n\n\n\n
On this database or collection,\nallow these actions.\n<\/code><\/pre>\n\n\n\n
MongoDB roles grant privileges to perform actions on resources. A role can apply to a database and can grant access down to collection-level granularity. (MongoDB<\/a>)<\/p>\n\n\n\n
Common Database Roles<\/h2>\n\n\n\n
Role<\/th>Scope<\/th>Meaning<\/th><\/tr><\/thead>
read<\/code><\/td>One database<\/td>Can read data<\/td><\/tr>
readWrite<\/code><\/td>One database<\/td>Can read and write data<\/td><\/tr>
dbAdmin<\/code><\/td>One database<\/td>Can perform database administration tasks<\/td><\/tr>
readAnyDatabase<\/code><\/td>All databases<\/td>Can read across databases<\/td><\/tr>
readWriteAnyDatabase<\/code><\/td>All databases<\/td>Can read\/write across databases<\/td><\/tr>
atlasAdmin<\/code><\/td>Broad Atlas database admin role<\/td>Powerful admin role; avoid for apps<\/td><\/tr>
Custom role<\/td>Database\/collection\/action-specific<\/td>Fine-grained least privilege<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
For applications, avoid broad roles unless absolutely necessary.<\/p>\n\n\n\n
Bad app user:<\/p>\n\n\n\n
role: atlasAdmin\ndatabase: admin\n<\/code><\/pre>\n\n\n\n
Good app user:<\/p>\n\n\n\n
role: readWrite\ndatabase: app_db\ncluster scope: app-prod-cluster\n<\/code><\/pre>\n\n\n\n
Even better if the app only needs a subset of operations:<\/p>\n\n\n\n
custom role:\n  db: app_db\n  collection: orders\n  actions:\n    - find\n    - insert\n    - update\n<\/code><\/pre>\n\n\n\n
\n\n\n\n
14. Built-In Roles vs Custom Roles<\/h1>\n\n\n\n
Built-In Roles<\/h2>\n\n\n\n
Built-in roles are convenient and cover common cases:<\/p>\n\n\n\n
read@app_db\nreadWrite@app_db\nreadAnyDatabase\nreadWriteAnyDatabase\nclusterMonitor\nbackup\natlasAdmin\n<\/code><\/pre>\n\n\n\n
Atlas CLI role syntax uses this shape:<\/p>\n\n\n\n
roleName@databaseName.collectionName\n<\/code><\/pre>\n\n\n\n
For example:<\/p>\n\n\n\n
readWrite@app_db\nread@reporting_db\n<\/code><\/pre>\n\n\n\n
The Atlas CLI docs describe the --role<\/code> format as roleName[@dbName[.collection]]<\/code>, where the role can be built-in or custom, and database\/collection are required for built-in roles. (MongoDB<\/a>)<\/p>\n\n\n\n
Custom Roles<\/h2>\n\n\n\n
Custom roles are for least privilege.<\/p>\n\n\n\n
Use them when built-in roles are too broad.<\/p>\n\n\n\n
Example use cases:<\/p>\n\n\n\n
Analyst can read only reporting_db.daily_sales\nApplication can insert orders but not delete them\nSupport user can read limited customer metadata\nETL job can read source collection and write target collection\n<\/code><\/pre>\n\n\n\n
Atlas custom roles can be created when built-in roles do not match the desired privileges. Atlas applies custom roles together with built-in roles and specific privileges assigned to the database user. A single database user can have multiple custom roles. (MongoDB<\/a>)<\/p>\n\n\n\n
Important behavior: if multiple assigned roles grant different permissions for the same object, Atlas honors the highest permissions granted by any role. (MongoDB<\/a>)<\/p>\n\n\n\n
That means there is no useful \u201cdeny role\u201d pattern like:<\/p>\n\n\n\n
grant readWrite\nthen deny delete\n<\/code><\/pre>\n\n\n\n
Instead, create a smaller custom role that only grants what you need.<\/p>\n\n\n\n
\n\n\n\n
15. Project-Wide Database Users vs Cluster-Scoped Database Users<\/h1>\n\n\n\n
This is one of the biggest \u201coops\u201d areas in Atlas.<\/p>\n\n\n\n
By default, when you create a database user with Atlas built-in roles, Atlas adds that user to all clusters in the project. To narrow that, use Restrict Access to Specific Clusters<\/strong> or define more specific privileges\/custom roles. (MongoDB<\/a>)<\/p>\n\n\n\n
Risky Design<\/h2>\n\n\n\n
Project: production\nClusters:\n  - prod-app-cluster\n  - prod-analytics-cluster\n  - prod-archive-cluster\n\nDatabase user:\n  app_user with readWrite@app_db\n\nProblem:\n  app_user may exist across all project clusters unless scoped.\n<\/code><\/pre>\n\n\n\n
Better Design<\/h2>\n\n\n\n
Project: production\n\nDatabase user:\n  prod_app_user\n  role: readWrite@app_db\n  scope: prod-app-cluster only\n<\/code><\/pre>\n\n\n\n
Best Design for Many Teams<\/h2>\n\n\n\n
Use separate projects for different environments:<\/p>\n\n\n\n
dev project\nstaging project\nprod project\n<\/code><\/pre>\n\n\n\n
Then also scope users carefully inside each project.<\/p>\n\n\n\n
\n\n\n\n
16. Atlas UI Data Explorer vs Database Connection<\/h1>\n\n\n\n
Atlas UI Data Explorer is a feature inside Atlas.<\/p>\n\n\n\n
It lets authorized Atlas users view or manipulate data through the Atlas UI.<\/p>\n\n\n\n
That is different from connecting with:<\/p>\n\n\n\n
mongosh\nMongoDB Compass\nPython driver\nNode.js driver\nJava driver\nGo driver\n<\/code><\/pre>\n\n\n\n
Example<\/h2>\n\n\n\n
A developer has:<\/p>\n\n\n\n
Atlas role:\n  Project Data Access Read Only\n<\/code><\/pre>\n\n\n\n
That means:<\/p>\n\n\n\n
\u2705 They may view documents in Atlas UI Data Explorer.\n\u274c They cannot use that Atlas login as a MongoDB database username.\n\u274c They cannot query documents through Atlas Admin API.\n<\/code><\/pre>\n\n\n\n
For actual database connection, they need:<\/p>\n\n\n\n
Database user:\n  dev_reader\nRole:\n  read@app_db\n<\/code><\/pre>\n\n\n\n
\n\n\n\n
17. Access Flow: Atlas UI Login<\/h1>\n\n\n\n
sequenceDiagram\n    participant User as Human User\n    participant AtlasLogin as Atlas Login \/ IdP\n    participant Atlas as Atlas UI\n    participant RBAC as Atlas RBAC\n    participant Project as Atlas Project\n\n    User->>AtlasLogin: Sign in\n    AtlasLogin-->>Atlas: Authenticated identity\n    Atlas->>RBAC: Check org\/project roles\n    RBAC-->>Atlas: Allowed actions\n    Atlas->>Project: Show\/manage permitted resources\n<\/code><\/pre>\n\n\n\n
Example:<\/p>\n\n\n\n
Rajesh logs in to Atlas.\nAtlas authenticates Rajesh.\nAtlas checks his organization and project roles.\nAtlas shows only what his roles allow.\n<\/code><\/pre>\n\n\n\n
If Rajesh has Project Read Only<\/code>, he can view project metadata but cannot access Data Explorer or retrieve process\/audit logs. (MongoDB<\/a>)<\/p>\n\n\n\n
\n\n\n\n
18. Access Flow: Atlas Admin API<\/h1>\n\n\n\n
sequenceDiagram\n    participant Pipeline as CI\/CD Pipeline\n    participant Token as OAuth Token Service\n    participant API as Atlas Admin API\n    participant RBAC as Atlas Project RBAC\n    participant Atlas as Atlas Resource\n\n    Pipeline->>Token: Request access token using service account\n    Token-->>Pipeline: Access token\n    Pipeline->>API: API call with token\n    API->>RBAC: Check service account role\n    RBAC-->>API: Allow or deny\n    API->>Atlas: Change Atlas configuration\n<\/code><\/pre>\n\n\n\n
Example:<\/p>\n\n\n\n
CI\/CD service account wants to create a database user.\nIt must have a project role that allows managing database access.\n<\/code><\/pre>\n\n\n\n
Good role:<\/p>\n\n\n\n
Project Database Access Admin\n<\/code><\/pre>\n\n\n\n
Too broad:<\/p>\n\n\n\n
Project Owner\n<\/code><\/pre>\n\n\n\n
The Project Database Access Admin role can manage database access and custom database roles, but it does not create clusters, access Data Explorer, or retrieve process\/audit logs. (MongoDB<\/a>)<\/p>\n\n\n\n
\n\n\n\n
19. Access Flow: Application Connecting to MongoDB<\/h1>\n\n\n\n
sequenceDiagram\n    participant App as Application\n    participant Net as Atlas Network Rules\n    participant Cluster as Atlas Cluster\n    participant Auth as Database Authentication\n    participant Authz as MongoDB Authorization\n    participant Data as Database \/ Collection\n\n    App->>Net: Connect from source IP\/private endpoint\n    Net-->>App: Allowed or blocked\n\n    App->>Cluster: Start TLS connection\n    Cluster->>Auth: Validate database user credentials\n    Auth-->>Cluster: Authenticated\n\n    App->>Authz: Request operation: insert into app_db.orders\n    Authz-->>Cluster: Role allows insert?\n    Cluster->>Data: Execute operation if allowed\n<\/code><\/pre>\n\n\n\n
Example:<\/p>\n\n\n\n
app_user connects from Kubernetes.\nAtlas checks whether the Kubernetes egress IP or private endpoint is allowed.\nMongoDB checks app_user credentials.\nMongoDB checks whether app_user has insert permission on app_db.orders.\nOnly then does the insert succeed.\n<\/code><\/pre>\n\n\n\n
\n\n\n\n
20. Hands-On Tutorial: Build a Secure Atlas Access Model<\/h1>\n\n\n\n
Let\u2019s design a realistic setup.<\/p>\n\n\n\n
Scenario<\/h2>\n\n\n\n
You have:<\/p>\n\n\n\n
Company: ExampleCorp\nEnvironment: dev, staging, prod\nApplication: ecommerce-api\nDatabase: ecommerce\nCollections:\n  - users\n  - orders\n  - payments\n  - products\n<\/code><\/pre>\n\n\n\n
Teams:<\/p>\n\n\n\n
Platform Team\nBackend Developers\nData Analysts\nAuditors\nCI\/CD Automation\nProduction Application\n<\/code><\/pre>\n\n\n\n
\n\n\n\n
Step 1: Create Organization and Projects<\/h2>\n\n\n\n
Recommended project layout:<\/p>\n\n\n\n
Organization: ExampleCorp\n\nProjects:\n  ecommerce-dev\n  ecommerce-staging\n  ecommerce-prod\n<\/code><\/pre>\n\n\n\n
Why separate projects?<\/p>\n\n\n\n
Cleaner access control\nSeparate database users\nSeparate IP access lists\nSeparate backup settings\nSeparate alerts\nSafer production boundary\n<\/code><\/pre>\n\n\n\n
Mermaid:<\/p>\n\n\n\n
flowchart TD\n    ORG[ExampleCorp Organization]\n    ORG --> DEV[ecommerce-dev Project]\n    ORG --> STG[ecommerce-staging Project]\n    ORG --> PROD[ecommerce-prod Project]\n\n    DEV --> DEVCLUSTER[dev cluster]\n    STG --> STGCLUSTER[staging cluster]\n    PROD --> PRODCLUSTER[prod cluster]\n<\/code><\/pre>\n\n\n\n
\n\n\n\n
Step 2: Create Atlas Teams<\/h2>\n\n\n\n
Suggested teams:<\/p>\n\n\n\n
Team<\/th>Purpose<\/th><\/tr><\/thead>
atlas-org-admins<\/code><\/td>Very small admin group<\/td><\/tr>
platform-engineers<\/code><\/td>Cluster\/network\/backup operations<\/td><\/tr>
backend-developers<\/code><\/td>Development team<\/td><\/tr>
data-analysts<\/code><\/td>Reporting and analytics<\/td><\/tr>
security-auditors<\/code><\/td>Read-only audit access<\/td><\/tr>
support-readonly<\/code><\/td>Limited support access<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
Step 3: Assign Atlas Roles<\/h2>\n\n\n\n
Suggested access matrix:<\/p>\n\n\n\n
Team<\/th>dev<\/th>staging<\/th>prod<\/th><\/tr><\/thead>
atlas-org-admins<\/td>Project Owner<\/td>Project Owner<\/td>Project Owner<\/td><\/tr>
platform-engineers<\/td>Project Owner or Cluster Manager<\/td>Cluster Manager<\/td>Cluster Manager + Network Access Manager<\/td><\/tr>
backend-developers<\/td>Data Access Read\/Write<\/td>Data Access Read Only<\/td>Project Read Only<\/td><\/tr>
data-analysts<\/td>Data Access Read Only<\/td>Data Access Read Only<\/td>Data Access Read Only, preferably limited<\/td><\/tr>
security-auditors<\/td>Project Read Only<\/td>Project Read Only<\/td>Project Read Only<\/td><\/tr>
support-readonly<\/td>Project Read Only<\/td>Project Read Only<\/td>Project Read Only<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Production hot take: do not give developers broad prod write access by default. That is how \u201cI was just checking something\u201d becomes a postmortem title.<\/p>\n\n\n\n
\n\n\n\n
Step 4: Configure Network Access<\/h2>\n\n\n\n
For dev:<\/p>\n\n\n\n
Temporary IP access entries may be acceptable.\nDeveloper office\/VPN IPs may be allowed.\n<\/code><\/pre>\n\n\n\n
For staging:<\/p>\n\n\n\n
Prefer private network access.\nAllow CI\/CD and staging app network only.\n<\/code><\/pre>\n\n\n\n
For prod:<\/p>\n\n\n\n
Use private endpoints where possible.\nAvoid 0.0.0.0\/0.\nAllow only production app network.\nAllow only production CI\/CD network for automation.\n<\/code><\/pre>\n\n\n\n
Bad prod setting:<\/p>\n\n\n\n
0.0.0.0\/0\n<\/code><\/pre>\n\n\n\n
Better prod setting:<\/p>\n\n\n\n
Private endpoint from production VPC\/VNet\nCI\/CD static egress IP only if needed\nNo developer laptop IPs\n<\/code><\/pre>\n\n\n\n
\n\n\n\n
Step 5: Create Database Users<\/h2>\n\n\n\n
Use different database users for different purposes.<\/p>\n\n\n\n
Bad pattern:<\/p>\n\n\n\n
one_user_to_rule_them_all\nrole: atlasAdmin\nused by app, developers, BI tools, cron jobs\n<\/code><\/pre>\n\n\n\n
Good pattern:<\/p>\n\n\n\n
dev_app_user\nstaging_app_user\nprod_app_user\nprod_reporting_reader\nprod_migration_user\nprod_breakglass_admin\n<\/code><\/pre>\n\n\n\n
Example Users<\/h2>\n\n\n\n
User<\/th>Role<\/th>Scope<\/th>Purpose<\/th><\/tr><\/thead>
dev_app_user<\/code><\/td>readWrite@ecommerce<\/code><\/td>dev cluster<\/td>Dev app<\/td><\/tr>
staging_app_user<\/code><\/td>readWrite@ecommerce<\/code><\/td>staging cluster<\/td>Staging app<\/td><\/tr>
prod_app_user<\/code><\/td>readWrite@ecommerce<\/code><\/td>prod app cluster only<\/td>Production app<\/td><\/tr>
prod_reporting_reader<\/code><\/td>read@reporting<\/code><\/td>prod analytics cluster only<\/td>Reports<\/td><\/tr>
prod_migration_user<\/code><\/td>Custom migration role<\/td>prod cluster, temporary<\/td>Migrations<\/td><\/tr>
prod_breakglass_admin<\/code><\/td>Powerful admin role<\/td>prod, highly controlled<\/td>Emergency only<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
21. Atlas CLI Examples<\/h1>\n\n\n\n
Create a Database User with Built-In Role<\/h2>\n\n\n\n
Example:<\/p>\n\n\n\n
atlas dbusers create \\\n  --username prod_app_user \\\n  --password '<use-a-secret-manager-generated-password>' \\\n  --role readWrite@ecommerce \\\n  --scope prod-cluster \\\n  --projectId '<PROJECT_ID>'\n<\/code><\/pre>\n\n\n\n
The Atlas CLI supports atlas dbusers create<\/code>, accepts --username<\/code>, --password<\/code>, --role<\/code>, --scope<\/code>, and --projectId<\/code>, and uses --scope<\/code> to define the clusters the user can access. (MongoDB<\/a>)<\/p>\n\n\n\n
Create a Read-Only Reporting User<\/h2>\n\n\n\n
atlas dbusers create \\\n  --username prod_reporting_reader \\\n  --password '<use-a-secret-manager-generated-password>' \\\n  --role read@reporting \\\n  --scope prod-analytics-cluster \\\n  --projectId '<PROJECT_ID>'\n<\/code><\/pre>\n\n\n\n
Create a Temporary Migration User<\/h2>\n\n\n\n
atlas dbusers create \\\n  --username prod_migration_user \\\n  --password '<temporary-secret>' \\\n  --role readWrite@ecommerce \\\n  --scope prod-cluster \\\n  --deleteAfter '2026-06-16T00:00:00Z' \\\n  --projectId '<PROJECT_ID>'\n<\/code><\/pre>\n\n\n\n
Atlas CLI supports --deleteAfter<\/code> for a timestamp after which Atlas deletes the database user. (MongoDB<\/a>)<\/p>\n\n\n\n
\n\n\n\n
22. Custom Role Example<\/h1>\n\n\n\n
Suppose an analytics job should only read:<\/p>\n\n\n\n
reporting.daily_sales\n<\/code><\/pre>\n\n\n\n
It should not read:<\/p>\n\n\n\n
reporting.customer_pii\nreporting.payments_raw\n<\/code><\/pre>\n\n\n\n
Create a custom role conceptually like this:<\/p>\n\n\n\n
Role: dailySalesReader\nResource:\n  db: reporting\n  collection: daily_sales\nActions:\n  find\n<\/code><\/pre>\n\n\n\n
Then assign:<\/p>\n\n\n\n
User: analytics_job_user\nRole: dailySalesReader\n<\/code><\/pre>\n\n\n\n
Flow:<\/p>\n\n\n\n
flowchart LR\n    Job[Analytics Job] --> User[analytics_job_user]\n    User --> Role[dailySalesReader]\n    Role --> Resource[reporting.daily_sales]\n    Role --> Action[find only]\n\n    User -. denied .-> PII[reporting.customer_pii]\n    User -. denied .-> Payments[reporting.payments_raw]\n<\/code><\/pre>\n\n\n\n
Custom roles are ideal when built-in roles like read@reporting<\/code> are too broad, because read@reporting<\/code> would read the whole database, not just one collection.<\/p>\n\n\n\n
\n\n\n\n
23. Complete Access Design Example<\/h1>\n\n\n\n
Human Admin Access<\/h2>\n\n\n\n
Identity:\n  Alice, Platform Engineer\n\nAtlas access:\n  Team: platform-engineers\n  Project role: Project Cluster Manager\n  Project role: Project Network Access Manager\n\nDatabase access:\n  No default database user\n  Temporary admin database user only when needed\n<\/code><\/pre>\n\n\n\n
Why?<\/p>\n\n\n\n
Alice can manage infrastructure.\nAlice cannot casually browse production data.\n<\/code><\/pre>\n\n\n\n
Developer Access<\/h2>\n\n\n\n
Identity:\n  Backend developer\n\nAtlas access:\n  dev: Project Data Access Read\/Write\n  staging: Project Data Access Read Only\n  prod: Project Read Only\n\nDatabase access:\n  dev database user only\n<\/code><\/pre>\n\n\n\n
Why?<\/p>\n\n\n\n
Developers can move fast in dev.\nProduction data remains protected.\n<\/code><\/pre>\n\n\n\n
Production App Access<\/h2>\n\n\n\n
Identity:\n  ecommerce-api\n\nAtlas access:\n  None\n\nDatabase access:\n  prod_app_user\n  role: readWrite@ecommerce\n  scope: prod-cluster\n  network: private endpoint only\n<\/code><\/pre>\n\n\n\n
Why?<\/p>\n\n\n\n
The app does not need Atlas UI or Atlas Admin API access.\nIt only needs database access.\n<\/code><\/pre>\n\n\n\n
CI\/CD Access<\/h2>\n\n\n\n
Identity:\n  ci-cd-service-account\n\nAtlas access:\n  Service account\n  Project Database Access Admin, if it manages DB users\n  Project Cluster Manager, if it updates clusters\n  Project Network Access Manager, if it updates access lists\n\nDatabase access:\n  Usually none\n<\/code><\/pre>\n\n\n\n
Why?<\/p>\n\n\n\n
CI\/CD manages Atlas configuration.\nIt should not read customer data unless specifically required.\n<\/code><\/pre>\n\n\n\n
Analyst Access<\/h2>\n\n\n\n
Identity:\n  Data analyst\n\nAtlas access:\n  Possibly Project Data Access Read Only\n\nDatabase access:\n  reporting_reader\n  role: read@reporting\n  or custom collection-level role\n<\/code><\/pre>\n\n\n\n
Why?<\/p>\n\n\n\n
Analysts read curated reporting data.\nThey should not read operational or sensitive collections by default.\n<\/code><\/pre>\n\n\n\n
\n\n\n\n
24. Authorization Decision Tree<\/h1>\n\n\n\n
Use this when someone asks: \u201cWhat access should I give?\u201d<\/p>\n\n\n\n
flowchart TD\n    START[User or app needs access] --> Q1{Need to manage Atlas resources?}\n\n    Q1 -->|Yes| ATLAS[Grant Atlas org\/project role]\n    Q1 -->|No| Q2{Need to read\/write database data?}\n\n    ATLAS --> Q1A{Human or machine?}\n    Q1A -->|Human| USER[Atlas user or team]\n    Q1A -->|Machine| SA[Service account preferred]\n\n    USER --> ROLE1[Assign least-privilege project\/org role]\n    SA --> ROLE2[Assign least-privilege service account role]\n\n    Q2 -->|Yes| DBUSER[Create database user]\n    Q2 -->|No| NOACCESS[No access needed]\n\n    DBUSER --> Q3{What data scope?}\n    Q3 -->|Whole database read| READ[read@db]\n    Q3 -->|Whole database read\/write| RW[readWrite@db]\n    Q3 -->|One collection\/actions only| CUSTOM[Custom DB role]\n    Q3 -->|Admin tasks| ADMIN[Specific admin role, avoid broad admin]\n\n    READ --> NET[Configure network access]\n    RW --> NET\n    CUSTOM --> NET\n    ADMIN --> NET\n\n    NET --> TEST[Test with actual operation]\n<\/code><\/pre>\n\n\n\n
\n\n\n\n
25. Common Mistakes<\/h1>\n\n\n\n
Mistake 1: Confusing Atlas User with Database User<\/h2>\n\n\n\n
Wrong assumption:<\/p>\n\n\n\n
\u201cI can log in to Atlas, so I can connect with mongosh.\u201d\n<\/code><\/pre>\n\n\n\n
Reality:<\/p>\n\n\n\n
Atlas login is for Atlas UI.\nDatabase connection needs database credentials.\n<\/code><\/pre>\n\n\n\n
Mistake 2: Giving Apps Atlas Admin API Access<\/h2>\n\n\n\n
Most apps do not need this:<\/p>\n\n\n\n
Atlas service account\nProject Owner\n<\/code><\/pre>\n\n\n\n
Most apps need this:<\/p>\n\n\n\n
Database user\nreadWrite@app_db\nNetwork access from app environment\n<\/code><\/pre>\n\n\n\n
Mistake 3: Using One Database User Everywhere<\/h2>\n\n\n\n
Bad:<\/p>\n\n\n\n
same username\/password in dev, staging, prod\n<\/code><\/pre>\n\n\n\n
Good:<\/p>\n\n\n\n
dev_app_user\nstaging_app_user\nprod_app_user\n<\/code><\/pre>\n\n\n\n
Mistake 4: Leaving Database User Unscoped<\/h2>\n\n\n\n
Bad:<\/p>\n\n\n\n
User exists across all clusters in the project\n<\/code><\/pre>\n\n\n\n
Good:<\/p>\n\n\n\n
Restrict Access to Specific Clusters\n<\/code><\/pre>\n\n\n\n
Mistake 5: Using atlasAdmin<\/code> for Applications<\/h2>\n\n\n\n
Bad:<\/p>\n\n\n\n
Application role: atlasAdmin\n<\/code><\/pre>\n\n\n\n
Good:<\/p>\n\n\n\n
Application role: readWrite@app_db\n<\/code><\/pre>\n\n\n\n
Best:<\/p>\n\n\n\n
Custom role with only required actions\n<\/code><\/pre>\n\n\n\n
Mistake 6: Allowing Public Internet Too Broadly<\/h2>\n\n\n\n
Bad:<\/p>\n\n\n\n
0.0.0.0\/0\n<\/code><\/pre>\n\n\n\n
Good:<\/p>\n\n\n\n
Private endpoint\nStatic egress IP\nVPN CIDR\nTemporary IP access entry for short-lived work\n<\/code><\/pre>\n\n\n\n
Mistake 7: Assuming Project Read Only Means Data Read Only<\/h2>\n\n\n\n
Project Read Only<\/code> is mostly Atlas control-plane visibility. It does not grant Data Explorer access. MongoDB\u2019s docs say Project Read Only grants view-only access to project control plane metadata but not Data Explorer access. (MongoDB<\/a>)<\/p>\n\n\n\n
\n\n\n\n
26. Troubleshooting Guide<\/h1>\n\n\n\n
Error: \u201cAuthentication failed\u201d<\/h2>\n\n\n\n
Likely causes:<\/p>\n\n\n\n
Wrong username\nWrong password\nWrong authSource\nUser deleted or expired\nWrong authentication mechanism\nSCRAM vs AWS IAM vs X.509 mismatch\nPassword contains special characters not URL-encoded\n<\/code><\/pre>\n\n\n\n
Check:<\/p>\n\n\n\n
Is the database user present in Atlas?\nIs the password correct?\nIs the connection string correct?\nIs authSource correct?\nFor AWS IAM, is authMechanism=MONGODB-AWS?\nFor X.509, does certificate subject match expected user?\n<\/code><\/pre>\n\n\n\n
Error: \u201cnot authorized on db to execute command\u201d<\/h2>\n\n\n\n
Likely causes:<\/p>\n\n\n\n
User authenticated successfully\nBut role does not allow the attempted operation\n<\/code><\/pre>\n\n\n\n
Example:<\/p>\n\n\n\n
User has read@app_db\nOperation is insert into app_db.orders\nResult: unauthorized\n<\/code><\/pre>\n\n\n\n
Fix:<\/p>\n\n\n\n
Grant readWrite@app_db\nor create a custom role with insert on app_db.orders\n<\/code><\/pre>\n\n\n\n
Error: \u201cconnection timed out\u201d<\/h2>\n\n\n\n
Likely causes:<\/p>\n\n\n\n
IP not allowed\nPrivate endpoint not configured correctly\nFirewall issue\nDNS issue\nWrong connection string\nCluster paused\n<\/code><\/pre>\n\n\n\n
Check:<\/p>\n\n\n\n
Project IP access list\nPrivate endpoint status\nVPC\/VNet routing\nSecurity groups \/ firewall rules\nCluster status\nDNS resolution\n<\/code><\/pre>\n\n\n\n
Error: \u201cuser works in dev but not prod\u201d<\/h2>\n\n\n\n
Likely causes:<\/p>\n\n\n\n
Different project\nDifferent database user\nDifferent network access\nDifferent cluster scope\nDifferent password\nDifferent role\n<\/code><\/pre>\n\n\n\n
Fix:<\/p>\n\n\n\n
Compare dev and prod:\n  project role\n  database user role\n  cluster scope\n  network access\n  connection string\n<\/code><\/pre>\n\n\n\n
\n\n\n\n
27. Recommended Production Security Model<\/h1>\n\n\n\n
Use this as your production baseline.<\/p>\n\n\n\n
Atlas Organization<\/h2>\n\n\n\n
Very few Organization Owners\nSSO \/ federated authentication enabled\nMFA enforced\nSeparate teams for admins, developers, auditors\nNo shared human accounts\n<\/code><\/pre>\n\n\n\n
Atlas Projects<\/h2>\n\n\n\n
Separate dev, staging, prod projects\nSeparate database users per environment\nSeparate network rules per environment\nSeparate service accounts per automation pipeline\n<\/code><\/pre>\n\n\n\n
Atlas API<\/h2>\n\n\n\n
Use service accounts instead of legacy API keys\nGrant least-privilege project roles\nRestrict API access to trusted CI\/CD IPs\nRotate secrets\nStore client secrets in a secret manager\nDo not use API access for app data queries\n<\/code><\/pre>\n\n\n\n
Database Users<\/h2>\n\n\n\n
One database user per app\/service\/job\nNo shared superuser\nNo atlasAdmin for app runtime\nUse readWrite only on required database\nUse custom roles for sensitive collections\nUse temporary users for short-lived migration\/admin work\nRestrict users to specific clusters\n<\/code><\/pre>\n\n\n\n
Network<\/h2>\n\n\n\n
Use private endpoints for staging\/prod\nAvoid 0.0.0.0\/0\nUse temporary IP entries for emergency work\nKeep app egress IPs stable\nSeparate control-plane API IP lists from data-plane cluster access lists\n<\/code><\/pre>\n\n\n\n
Operations<\/h2>\n\n\n\n
Review users and roles regularly\nRemove unused database users\nRotate app secrets\nMonitor Activity Feed\nAudit database access where required\nUse break-glass access with approval and expiry\n<\/code><\/pre>\n\n\n\n
\n\n\n\n
28. The Best Mental Model<\/h1>\n\n\n\n
Remember this:<\/p>\n\n\n\n
Atlas user\/team\/service account\/API key\n  -> controls Atlas management actions\n\nDatabase user\n  -> controls MongoDB data actions\n\nNetwork access\n  -> controls who can reach the cluster\n\nDatabase roles\n  -> control what authenticated clients can do inside MongoDB\n<\/code><\/pre>\n\n\n\n
One more diagram to tattoo on the inside of your eyelids:<\/p>\n\n\n\n
flowchart TD\n    A[Need Access] --> B{Atlas Management or Database Data?}\n\n    B -->|Atlas Management| C[Atlas Identity]\n    C --> C1[Human: Atlas User \/ Team]\n    C --> C2[Machine: Service Account]\n    C1 --> C3[Org Role \/ Project Role]\n    C2 --> C3\n    C3 --> C4[Manage Atlas Resources]\n\n    B -->|Database Data| D[Database Identity]\n    D --> D1[Database User]\n    D1 --> D2[Authentication Method]\n    D2 --> D3[SCRAM \/ AWS IAM \/ X.509 \/ LDAP \/ OIDC]\n    D3 --> D4[Database Roles]\n    D4 --> D5[read \/ readWrite \/ custom privileges]\n    D5 --> D6[Read or Write Documents]\n\n    D --> E[Network Access]\n    E --> E1[IP Access List \/ Private Endpoint \/ Peering]\n<\/code><\/pre>\n\n\n\n
\n\n\n\n
29. Final Cheat Sheet<\/h1>\n\n\n\n
Need<\/th>Use this identity<\/th>Use this permission<\/th><\/tr><\/thead>
Log in to Atlas UI<\/td>Atlas user<\/td>Org\/project role<\/td><\/tr>
Assign users to projects<\/td>Atlas user or team<\/td>Project Access Manager \/ Project Owner<\/td><\/tr>
Automate cluster creation<\/td>Service account<\/td>Project Cluster Creator \/ Project Owner as needed<\/td><\/tr>
Automate DB user creation<\/td>Service account<\/td>Project Database Access Admin<\/td><\/tr>
Connect app to MongoDB<\/td>Database user<\/td>readWrite@app_db<\/code> or custom role<\/td><\/tr>
Read reports only<\/td>Database user<\/td>read@reporting<\/code> or custom role<\/td><\/tr>
View documents in Atlas UI<\/td>Atlas user\/team<\/td>Project Data Access Read Only<\/td><\/tr>
Modify documents in Atlas UI<\/td>Atlas user\/team<\/td>Project Data Access Read\/Write<\/td><\/tr>
Query documents from app\/API\/driver<\/td>Database user<\/td>MongoDB database role<\/td><\/tr>
Restrict source network<\/td>Network access<\/td>IP list\/private endpoint\/VPC peering<\/td><\/tr>
Emergency admin<\/td>Temporary database user<\/td>Short-lived admin role, audited<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
30. One-Sentence Summary<\/h1>\n\n\n\n
MongoDB Atlas authentication and authorization is best understood as three gates<\/strong>:<\/p>\n\n\n\n
Atlas RBAC controls who manages Atlas.\nNetwork access controls who can reach the cluster.\nDatabase RBAC controls who can read\/write MongoDB data.\n<\/code><\/pre>\n\n\n\n
Keep those gates separate, grant the smallest useful permission at each gate, and your Atlas security model becomes clean, scalable, and production-grade.<\/p>\n","protected":false},"excerpt":{"rendered":"
MongoDB Atlas security becomes simple once you stop treating \u201cAtlas access\u201d and \u201cdatabase access\u201d as one thing. They are two different systems: MongoDB\u2019s own docs make this… <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1025","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1025","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=1025"}],"version-history":[{"count":1,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1025\/revisions"}],"predecessor-version":[{"id":1026,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1025\/revisions\/1026"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=1025"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=1025"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=1025"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}