Role-based access control in MongoDB - Deep Dive

Overview - Role-based access control

What is it?

Role-based access control (RBAC) is a way to manage who can do what in a database by assigning roles to users. Each role has specific permissions that allow certain actions like reading or writing data. Instead of giving permissions to each user individually, RBAC groups permissions into roles, making management easier. This helps keep data safe and organized.

Why it matters

Without RBAC, managing permissions for many users would be confusing and error-prone, risking data leaks or accidental changes. RBAC solves this by letting administrators control access through roles, reducing mistakes and improving security. This is especially important in businesses where many people need different levels of access to sensitive data.

Where it fits

Before learning RBAC, you should understand basic database concepts like users and permissions. After RBAC, you can explore advanced security topics like auditing, encryption, and multi-factor authentication to further protect data.

Mental Model

Core Idea

RBAC controls database access by assigning users to roles, and roles have the permissions to perform specific actions.

Think of it like...

Think of RBAC like a company where employees have job titles (roles), and each title comes with certain responsibilities and access rights. Instead of telling each employee what they can do, the company assigns a title that defines their permissions.

┌─────────────┐       ┌─────────────┐       ┌───────────────┐
│   Users     │──────▶│   Roles     │──────▶│ Permissions   │
└─────────────┘       └─────────────┘       └───────────────┘

Users are assigned Roles, and Roles have Permissions.

Build-Up - 7 Steps

1

Foundation

Understanding Users and Permissions

Concept: Learn what users and permissions mean in MongoDB.

In MongoDB, a user is an account that can connect to the database. Permissions are rules that say what actions a user can do, like reading data or changing it. For example, a user might have permission to read data but not delete it.

Result

You know that users are accounts and permissions control what they can do.

Understanding users and permissions is the base for controlling access securely.

2

Foundation

What Are Roles in MongoDB?

Concept: Roles group permissions together for easier management.

A role in MongoDB is a set of permissions bundled together. Instead of giving each user many permissions one by one, you assign a role that already has those permissions. MongoDB has built-in roles like 'read' or 'readWrite', and you can create custom roles too.

Result

You see how roles simplify permission management by grouping them.

Knowing roles lets you manage many users efficiently and consistently.

3

Intermediate

Assigning Roles to Users

🤔Before reading on: Do you think a user can have multiple roles at once or only one? Commit to your answer.

Concept: Users can have one or more roles, combining permissions from all assigned roles.

In MongoDB, you assign roles to users when you create or update them. A user can have multiple roles, and their permissions add up. For example, a user with 'read' and 'dbAdmin' roles can read data and manage the database.

Result

Users gain combined permissions from all their roles.

Understanding multiple roles per user helps design flexible access control.

4

Intermediate

Built-in vs Custom Roles

🤔Before reading on: Do you think built-in roles cover all needs or are custom roles often necessary? Commit to your answer.

Concept: MongoDB provides built-in roles for common tasks, but custom roles let you tailor permissions precisely.

Built-in roles like 'read', 'readWrite', and 'dbAdmin' cover many cases. However, sometimes you need specific permissions, like allowing only updates on certain collections. Custom roles let you pick exact actions and resources to fit your needs.

Result

You can use built-in roles for simplicity or custom roles for fine control.

Knowing when to use custom roles prevents over-permission or under-permission.

5

Intermediate

Role Hierarchies and Inheritance

Concept: Roles can include other roles, inheriting their permissions.

In MongoDB, a role can inherit permissions from other roles. For example, a custom role can include the 'read' role, so it automatically has all read permissions plus any extra you add. This avoids repeating permissions and keeps roles organized.

Result

Roles can build on each other, making permission management scalable.

Understanding inheritance helps create clean and maintainable access structures.

6

Advanced

Implementing RBAC in MongoDB

🤔Before reading on: Do you think RBAC is enforced only at login or also during each action? Commit to your answer.

Concept: MongoDB enforces RBAC continuously, checking permissions for every action a user tries.

When a user connects, MongoDB checks their roles and permissions. For every command or query, MongoDB verifies if the user has the right permission. If not, the action is denied. This ensures security at all times, not just at login.

Result

RBAC protects data dynamically, preventing unauthorized actions.

Knowing RBAC enforcement is continuous helps understand security reliability.

7

Expert

RBAC Limitations and Security Best Practices

🤔Before reading on: Do you think RBAC alone is enough for full database security? Commit to your answer.

Concept: RBAC is powerful but should be combined with other security measures for best protection.

RBAC controls who can do what, but it doesn't encrypt data or detect suspicious activity. Experts combine RBAC with encryption, auditing, network security, and monitoring. Also, overly broad roles can cause risks, so roles should follow the principle of least privilege.

Result

RBAC is a key part of security but not the whole solution.

Understanding RBAC's limits prevents overreliance and encourages layered security.

Under the Hood

MongoDB stores user accounts and their assigned roles in the admin database. When a user connects, MongoDB authenticates them and loads their roles. For each operation, MongoDB checks the requested action against the permissions granted by the user's roles. This check happens inside the database engine before executing commands, ensuring unauthorized actions are blocked immediately.

Why designed this way?

RBAC was designed to simplify permission management by grouping permissions into roles, reducing errors and administrative overhead. Early systems assigned permissions individually, which became unmanageable as users grew. MongoDB adopted RBAC to provide flexible, scalable, and secure access control that fits many use cases.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│   User Login  │──────▶│ Load User Roles│──────▶│ Permission Check│
└───────────────┘       └───────────────┘       └───────────────┘
                                   │
                                   ▼
                        ┌─────────────────────┐
                        │ Execute Allowed Ops  │
                        └─────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think assigning a user multiple roles can cause permission conflicts? Commit yes or no.

Common Belief: Assigning multiple roles to a user can cause conflicts or override permissions unpredictably.

Reality: MongoDB combines all permissions from assigned roles, granting the union of permissions without conflicts.

Why it matters: Believing in conflicts may cause admins to avoid assigning multiple roles, limiting flexibility and causing overly complex role designs.

Quick: Do you think built-in roles cover every possible permission need? Commit yes or no.

Common Belief: Built-in roles are enough for all database access control needs.

Reality: Built-in roles cover common cases but often custom roles are needed for precise control.

Why it matters: Relying only on built-in roles can lead to over-permission or under-permission, risking security or usability.

Quick: Do you think RBAC alone protects data from all security threats? Commit yes or no.

Common Belief: RBAC alone fully secures the database from all threats.

Reality: RBAC controls access but does not protect against data leaks from compromised accounts or network attacks; other security layers are needed.

Why it matters: Overestimating RBAC can lead to neglecting encryption, auditing, and monitoring, increasing risk.

Quick: Do you think permissions are checked only when a user logs in? Commit yes or no.

Common Belief: Permissions are verified only once at login, so after that, users can do anything.

Reality: MongoDB checks permissions for every action, not just at login.

Why it matters: Misunderstanding this can cause false confidence in security and unexpected access.

Expert Zone

1

Custom roles can include inherited roles, but explicit permissions in the custom role override inherited ones, allowing fine-tuned control.

2

Role assignments can be scoped to specific databases or collections, enabling very granular access control.

3

MongoDB's internal permission checks are optimized for performance, but complex role hierarchies can slightly impact query latency.

When NOT to use

RBAC is not suitable when you need attribute-based access control (ABAC) where permissions depend on data values or context. In such cases, use MongoDB's field-level encryption or external policy engines. Also, for very simple setups, basic user permissions without roles might suffice.

Production Patterns

In production, teams often create roles aligned with job functions like 'reporting', 'data entry', or 'DBA'. They combine RBAC with auditing to track access and use automation scripts to manage role assignments. Least privilege is enforced by regularly reviewing roles and permissions.

Connections

Least Privilege Principle

RBAC implements the least privilege principle by assigning only necessary permissions via roles.

Understanding least privilege helps design roles that minimize risk by limiting user access to only what they need.

Operating System User Groups

RBAC in databases is similar to OS user groups that control file and resource access.

Knowing OS groups helps grasp how roles group permissions for easier management.

Organizational Hierarchies

RBAC mirrors organizational structures where job titles define responsibilities and access.

Seeing RBAC as reflecting real-world roles clarifies why it is intuitive and scalable.

Common Pitfalls

#1 Assigning overly broad roles to users.

Wrong approach:

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

Correct approach:

db.createUser({user: 'alice', pwd: 'pass', roles: [{role: 'read', db: 'sales'}]})

Root cause:

Misunderstanding the principle of least privilege leads to giving users more permissions than needed.

#2 Not creating custom roles when needed.

Wrong approach:

Using only built-in roles like 'readWrite' for all users regardless of specific needs.

Correct approach:

db.createRole({role: 'updateOnly', privileges: [{resource: {db: 'sales', collection: 'orders'}, actions: ['update']}], roles: []})

Root cause:

Assuming built-in roles cover all cases causes security gaps or operational issues.

#3 Assuming permissions are checked only at login.

Wrong approach:

Believing once logged in, users can perform any action without further checks.

Correct approach:

Understanding MongoDB checks permissions on every operation dynamically.

Root cause:

Lack of knowledge about MongoDB's continuous permission enforcement.

Key Takeaways

Role-based access control (RBAC) manages database permissions by assigning users to roles that bundle specific permissions.

MongoDB supports built-in and custom roles, allowing flexible and precise access control tailored to real needs.

Users can have multiple roles, and MongoDB checks permissions for every action, ensuring continuous security enforcement.

RBAC simplifies permission management, reduces errors, and supports the principle of least privilege to protect data.

RBAC is a critical security layer but should be combined with encryption, auditing, and monitoring for full protection.

Practice

1. What is the main purpose of role-based access control (RBAC) in MongoDB?

easy

A. To optimize query performance automatically

B. To store data in a structured format

C. To manage user permissions by assigning roles with specific privileges

D. To backup the database regularly

Solution

1. Step 1: Understand RBAC concept

   RBAC is about controlling what users can do by giving them roles with permissions.

2. Step 2: Identify RBAC purpose in MongoDB

   MongoDB uses RBAC to assign roles that define user privileges, managing access securely.

3. Final Answer:

   To manage user permissions by assigning roles with specific privileges -> Option C

4. Quick Check:

   RBAC controls access by roles = A [OK]

Hint: RBAC controls user actions via roles, not data or backups [OK]

Common Mistakes:

• Confusing RBAC with data storage
• Thinking RBAC handles backups
• Assuming RBAC optimizes queries

2. Which of the following is the correct syntax to create a role named readOnlyUser with read access on the sales database?

easy

A. db.createRole({role: "readOnlyUser", privileges: [{resource: {db: "sales", collection: ""}, actions: ["find"]}], roles: []})

B. db.createRole({name: "readOnlyUser", privileges: [{resource: {db: "sales", collection: ""}, actions: ["find"]}], roles: []})

C. db.createRole({role: "readOnlyUser", privileges: [{resource: {db: "sales"}, actions: ["insert"]}], roles: []})

D. db.createRole({name: "readOnlyUser", privileges: [{resource: {db: "sales", collection: ""}, actions: ["update"]}], roles: []})

Solution

1. Step 1: Check correct field for role name

   The field to name the role is name, not role.

2. Step 2: Verify privileges for read access

   Read access uses the find action on the database with empty collection string for all collections.

3. Final Answer:

   db.createRole({name: "readOnlyUser", privileges: [{resource: {db: "sales", collection: ""}, actions: ["find"]}], roles: []}) -> Option B

4. Quick Check:

   Role name uses 'name' field = A [OK]

Hint: Use 'name' for role, 'find' for read, empty collection for all [OK]

Common Mistakes:

• Using 'role' instead of 'name' for role creation
• Assigning wrong actions like 'insert' for read role
• Missing empty string for collection to cover all

3. Given the following commands, what will be the result of db.runCommand({usersInfo: "alice"}) after assigning the role?

db.createRole({
  name: "reportViewer",
  privileges: [{resource: {db: "reports", collection: ""}, actions: ["find"]}],
  roles: []
})
db.createUser({
  user: "alice",
  pwd: "password123",
  roles: ["reportViewer"]
})

medium

A. Returns user info showing 'alice' has role 'reportViewer' with find privileges on 'reports'

B. Returns an error because 'reportViewer' role does not exist

C. Returns user info but shows no roles assigned to 'alice'

D. Returns user info showing 'alice' has admin role

Solution

1. Step 1: Confirm role creation and assignment

   The role 'reportViewer' is created with find privileges on 'reports' and assigned to user 'alice'.

2. Step 2: Understand usersInfo command output

   Running usersInfo for 'alice' shows user details including assigned roles and privileges.

3. Final Answer:

   Returns user info showing 'alice' has role 'reportViewer' with find privileges on 'reports' -> Option A

4. Quick Check:

   Role assigned correctly, usersInfo shows it = C [OK]

Hint: usersInfo shows assigned roles and privileges correctly [OK]

Common Mistakes:

• Assuming usersInfo errors if role was just created
• Expecting no roles shown after assignment
• Confusing assigned roles with admin role

4. You tried to create a role with this command:

db.createRole({
  role: "dataEditor",
  privileges: [{resource: {db: "inventory", collection: "products"}, actions: ["update"]}],
  roles: []
})

But it failed. What is the error?

medium

A. The field 'role' should be 'name' when creating a role

B. The 'actions' array cannot contain 'update'

C. The 'resource' field must include 'collection' as null, not a string

D. Roles cannot have empty 'roles' array

Solution

1. Step 1: Check role creation syntax

   The correct field to name a role is 'name', not 'role'. Using 'role' causes failure.

2. Step 2: Validate other fields

   Actions like 'update' are valid, collection as string is correct, and empty roles array is allowed.

3. Final Answer:

   The field 'role' should be 'name' when creating a role -> Option A

4. Quick Check:

   Use 'name' field for role creation = B [OK]

Hint: Use 'name' not 'role' to name roles in createRole [OK]

Common Mistakes:

• Using 'role' instead of 'name' for role name
• Thinking 'update' is invalid action
• Believing empty roles array is disallowed

5. You want to create a custom role manager that can read and update documents in the employees database and also inherit all privileges from the built-in read role on the same database. Which command correctly achieves this?

hard

A. db.createRole({name: "manager", privileges: [{resource: {db: "employees", collection: "employees"}, actions: ["find", "update"]}], roles: [{role: "read", db: "employees"}]})

B. db.createRole({name: "manager", privileges: [{resource: {db: "employees", collection: "employees"}, actions: ["find", "update"]}], roles: [{role: "read", db: "admin"}]})

C. db.createRole({name: "manager", privileges: [{resource: {db: "employees", collection: "employees"}, actions: ["insert", "update"]}], roles: [{role: "read", db: "employees"}]})

D. db.createRole({name: "manager", privileges: [{resource: {db: "employees", collection: ""}, actions: ["find", "update"]}], roles: [{role: "read", db: "employees"}]})

Solution

1. Step 1: Check privileges for read and update on employees

   Privileges should apply to all collections in 'employees' database, so collection is empty string "".

2. Step 2: Verify inherited role database

   The built-in 'read' role must be inherited from the same database 'employees', not 'admin'.

3. Step 3: Confirm actions and roles

   Actions 'find' and 'update' are correct; 'insert' is not required here.

4. Final Answer:

   db.createRole({name: "manager", privileges: [{resource: {db: "employees", collection: ""}, actions: ["find", "update"]}], roles: [{role: "read", db: "employees"}]}) -> Option D

5. Quick Check:

   Empty collection for all, inherit 'read' from same DB = D [OK]

Hint: Use empty collection for all, inherit roles from same DB [OK]

Common Mistakes:

• Setting collection name instead of empty string for all
• Inheriting 'read' role from wrong database
• Using wrong actions like 'insert' instead of 'find'