Built-in roles (read, readWrite, dbAdmin) in MongoDB - Deep Dive

Overview - Built-in roles (read, readWrite, dbAdmin)

What is it?

Built-in roles in MongoDB are predefined sets of permissions that control what actions users can perform on the database. The roles read, readWrite, and dbAdmin each grant different levels of access to data and database management. These roles help manage security by limiting user capabilities to only what they need. They make it easier to assign permissions without creating custom rules from scratch.

Why it matters

Without built-in roles, database administrators would have to manually assign every permission to each user, which is time-consuming and error-prone. This could lead to security risks like unauthorized data changes or accidental deletions. Built-in roles provide a simple, reliable way to protect data and ensure users only do what they are allowed to do, keeping the database safe and organized.

Where it fits

Before learning about built-in roles, you should understand basic MongoDB concepts like databases, collections, and users. After this, you can learn about custom roles and advanced security features like authentication mechanisms and role-based access control (RBAC) policies.

Mental Model

Core Idea

Built-in roles are predefined permission sets that control what users can read, write, or manage in a MongoDB database.

Think of it like...

Think of built-in roles like job titles in a company: a 'Reader' can only read documents, a 'Writer' can both read and write, and a 'Manager' can also organize and maintain the workspace.

┌─────────────┐       ┌───────────────┐       ┌───────────────┐
│   read      │──────▶│  readWrite    │──────▶│    dbAdmin    │
│ (view only) │       │ (read + write)│       │ (manage db)   │
└─────────────┘       └───────────────┘       └───────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding MongoDB Users

Concept: Users are accounts that connect to MongoDB and perform actions based on permissions.

In MongoDB, a user is created with a username and password. This user can be assigned roles that define what they can do. Without roles, users have no permissions and cannot access data or perform operations.

Result

Users exist but cannot read or write data until roles are assigned.

Knowing that users need roles to do anything helps understand why roles are essential for security.

2

Foundation

What Are Roles in MongoDB?

Concept: Roles are collections of privileges that grant permissions to users.

A role bundles together specific actions like reading data, writing data, or managing the database. Assigning a role to a user gives them all the permissions in that role. MongoDB provides built-in roles to simplify this process.

Result

Users with roles can perform actions allowed by those roles.

Understanding roles as permission bundles clarifies how MongoDB controls user access efficiently.

3

Intermediate

The read Role: View-Only Access

🤔Before reading on: do you think a user with the read role can modify data? Commit to yes or no.

Concept: The read role allows users to view data but not change it.

Users with the read role can query and find documents in all collections of a database. They cannot insert, update, or delete any data. This role is useful for users who only need to analyze or report data.

Result

Users can see all data but cannot change anything.

Knowing that read role strictly limits users to viewing prevents accidental data changes by unauthorized users.

4

Intermediate

The readWrite Role: Modify Data Allowed

🤔Before reading on: does the readWrite role include database management permissions? Commit to yes or no.

Concept: The readWrite role allows users to read and modify data but not manage the database itself.

Users with readWrite can perform all read actions plus insert new documents, update existing ones, and delete documents in all collections of the database. However, they cannot create or drop collections or manage indexes.

Result

Users can fully work with data but cannot change database structure or settings.

Understanding the scope of readWrite helps assign appropriate permissions without risking structural changes.

5

Intermediate

The dbAdmin Role: Manage Database Structure

🤔Before reading on: can dbAdmin users read or write data by default? Commit to yes or no.

Concept: The dbAdmin role allows users to manage database structure but does not grant data read or write permissions by default.

Users with dbAdmin can create and drop collections, manage indexes, and view database statistics. They cannot read or modify the documents inside collections unless combined with read or readWrite roles.

Result

Users can organize and maintain the database but cannot access the data itself.

Knowing dbAdmin separates data access from database management helps design secure role combinations.

6

Advanced

Combining Roles for Flexible Permissions

🤔Before reading on: do you think assigning multiple roles to a user combines all their permissions? Commit to yes or no.

Concept: Users can have multiple roles, and their permissions add up to allow combined capabilities.

For example, assigning both readWrite and dbAdmin roles to a user lets them read, write data, and manage the database. MongoDB merges privileges from all assigned roles to determine what a user can do.

Result

Users gain all permissions from all their roles combined.

Understanding role combination allows precise control over user capabilities without creating custom roles.

7

Expert

Role Privileges and Inheritance Details

🤔Before reading on: do built-in roles inherit permissions from other roles internally? Commit to yes or no.

Concept: Built-in roles are defined with specific privileges and do not inherit from each other, but their privileges may overlap.

Each built-in role explicitly lists the actions it allows. For example, readWrite includes all read privileges plus write privileges but does not inherit from read. This explicit definition avoids confusion and makes permission checks efficient.

Result

Role privileges are clear and precise, avoiding hidden permissions.

Knowing roles do not inherit but overlap clarifies how MongoDB evaluates permissions and prevents unexpected access.

Under the Hood

MongoDB stores roles as documents defining allowed actions on resources like collections or databases. When a user attempts an operation, MongoDB checks the user's assigned roles and their privileges to decide if the action is permitted. This check happens at runtime for every operation, ensuring security is enforced consistently.

Why designed this way?

Explicit role definitions without inheritance simplify permission evaluation and reduce errors. Built-in roles cover common use cases, so administrators don't need to create custom roles for typical scenarios, speeding up setup and reducing mistakes.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│   User Login  │──────▶│ Role Privileges│──────▶│ Permission    │
│ (username +   │       │ (read, write,  │       │ Check Engine  │
│  roles)       │       │  manage)       │       │ (allow/deny)  │
└───────────────┘       └───────────────┘       └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does the readWrite role automatically include dbAdmin privileges? Commit to yes or no.

Common Belief: readWrite role lets users manage the database structure like dbAdmin.

Reality: readWrite only allows reading and writing data, not managing collections or indexes.

Why it matters: Assuming readWrite includes dbAdmin can lead to security gaps where users cannot perform needed management tasks or mistakenly think they have those rights.

Quick: Can a user with only dbAdmin role read or modify documents? Commit to yes or no.

Common Belief: dbAdmin role includes full access to data since it manages the database.

Reality: dbAdmin only manages database structure; it does not grant read or write access to documents.

Why it matters: Misunderstanding this can cause confusion when users cannot access data despite having dbAdmin role.

Quick: If a user has both read and readWrite roles, do they have fewer permissions than just readWrite? Commit to yes or no.

Common Belief: Assigning multiple roles can restrict permissions to the lowest common set.

Reality: Permissions from all roles are combined, so the user has the union of all privileges.

Why it matters: Believing roles restrict each other can cause admins to under-assign permissions, blocking legitimate user actions.

Quick: Are built-in roles customizable by default? Commit to yes or no.

Common Belief: You can change what built-in roles do by editing them directly.

Reality: Built-in roles are fixed; to customize, you must create new roles based on them.

Why it matters: Trying to modify built-in roles directly wastes time and can cause confusion about permissions.

Expert Zone

1

Built-in roles are designed to be minimal and composable, encouraging combining roles rather than creating large monolithic roles.

2

The dbAdmin role includes privileges to run diagnostic commands, which can expose sensitive information if misused.

3

Role privileges are checked at the operation level, meaning some commands may require multiple privileges depending on their complexity.

When NOT to use

Built-in roles are not suitable when you need very fine-grained control over permissions, such as limiting access to specific collections or fields. In such cases, custom roles with tailored privileges should be used.

Production Patterns

In production, administrators often assign readWrite for application users who modify data, read for reporting users, and dbAdmin for maintenance staff. Roles are combined carefully to follow the principle of least privilege, minimizing security risks.

Connections

Role-Based Access Control (RBAC)

Built-in roles are a specific implementation of RBAC in MongoDB.

Understanding MongoDB roles helps grasp the broader security model of RBAC used in many systems to manage permissions efficiently.

Unix File Permissions

Both use predefined permission sets to control access to resources.

Knowing Unix permissions clarifies how roles group permissions to simplify user access management.

Organizational Job Roles

Built-in roles mirror job roles assigning responsibilities and limits.

Seeing roles as job titles helps understand why separating read, write, and admin tasks improves security and clarity.

Common Pitfalls

#1 Assigning dbAdmin role expecting data read/write access.

Wrong approach:

db.createUser({user: 'adminUser', pwd: 'pass', roles: [{role: 'dbAdmin', db: 'mydb'}]})
// Then trying to read data without read or readWrite role

Correct approach:

db.createUser({user: 'adminUser', pwd: 'pass', roles: [{role: 'dbAdmin', db: 'mydb'}, {role: 'read', db: 'mydb'}]})

Root cause:

Misunderstanding that dbAdmin does not include data access permissions.

#2 Expecting readWrite role to allow creating indexes.

Wrong approach:

db.createUser({user: 'writer', pwd: 'pass', roles: [{role: 'readWrite', db: 'mydb'}]})
// Then trying db.collection.createIndex({field: 1}) and failing

Correct approach:

db.createUser({user: 'writer', pwd: 'pass', roles: [{role: 'readWrite', db: 'mydb'}, {role: 'dbAdmin', db: 'mydb'}]})

Root cause:

Not knowing that index management requires dbAdmin privileges.

#3 Trying to modify built-in roles directly.

Wrong approach:

db.updateRole('read', {privileges: [...]}) // Attempt to change built-in role

Correct approach:

db.createRole({role: 'customRead', privileges: [...], roles: ['read']})

Root cause:

Believing built-in roles are editable instead of creating custom roles.

Key Takeaways

Built-in roles in MongoDB simplify permission management by grouping common privileges into read, readWrite, and dbAdmin roles.

The read role allows viewing data only, readWrite adds data modification, and dbAdmin manages database structure without data access.

Users can have multiple roles, and their permissions combine to grant all allowed actions.

Built-in roles are fixed and cannot be changed; for custom needs, create new roles based on them.

Understanding these roles helps secure MongoDB databases by assigning the least privilege necessary for each user.