Kontrola dostępu oparta na rolach: role wbudowane i niestandardowe

Role-Based Access Control (RBAC) is MongoDB's authorization model. Instead of granting individual permissions directly to users, you assign roles — named collections of privileges — to users. This makes permission management scalable: update a role and every user holding that role inherits the change automatically. MongoDB ships with a rich set of built-in roles covering the most common access patterns.

MongoDB provides several database-level roles that apply to a specific database. The most commonly used are: read (read all collections), readWrite (read + insert/update/delete), dbAdmin (schema management, index creation), and userAdmin (create/modify users in that database). These roles are database-scoped — a user with readWrite on myApp cannot access otherApp.

Some built-in roles span all databases on a MongoDB instance. readAnyDatabase and readWriteAnyDatabase grant their respective permissions across every database. dbAdminAnyDatabase allows schema management everywhere. The most powerful is root, which has full access to everything — use it only for initial setup and emergency recovery, never for application accounts.

Every MongoDB user should have exactly the permissions they need — no more. An API that only reads products should have read, not readWrite. A background job that archives documents should only be able to query and delete from the archive collection — not from all collections. Applying least privilege limits the blast radius of a compromised credential.

When built-in roles are too broad, create a custom role using db.createRole(). A role definition lists specific privileges — each privilege is an action (e.g., find, insert, createIndex) on a resource (a specific database, collection, or cluster). Custom roles can also inherit from existing roles using the roles array.

Assign a custom role the same way you assign built-in roles — include it in the roles array when creating a user or grant it later with db.grantRolesToUser(). A user can hold multiple roles simultaneously, combining their permissions. MongoDB computes the union of all privileges from all assigned roles when authorizing each operation.

When an employee changes roles or a service is decommissioned, revoke unnecessary permissions promptly. db.revokeRolesFromUser() removes specific roles from a user without deleting the account. db.updateUser() lets you replace the entire roles array. Regularly audit users and their assigned roles with db.getUsers() to catch privilege creep.

Custom roles can be scoped to a specific collection rather than an entire database. This allows fine-grained access control where, for example, a service can only read the products collection but has no access to users or orders in the same database. Collection-level scoping is achieved by specifying a collection name in the resource document.

Several built-in roles govern cluster-level operations rather than data access. clusterMonitor grants read access to monitoring commands (useful for metrics exporters). clusterAdmin allows managing shards, replica sets, and global operations — very powerful, restrict carefully. backup and restore roles grant the specific permissions needed for mongodump and mongorestore without full admin rights.

Use db.getRole(roleName, { showPrivileges: true }) to see exactly which actions and resources a role grants, including inherited privileges from parent roles. This is essential for auditing — you can confirm that a custom role provides exactly the right permissions without accidentally granting broader access through inherited roles.

MongoDB Atlas implements RBAC through its Database Access panel. You can create database users with built-in or custom roles via the Atlas UI, Atlas CLI, or Atlas API. Atlas also supports temporary users that expire automatically after a set time — ideal for short-lived developer access or incident response. Additionally, Atlas can integrate with AWS IAM and LDAP for enterprise identity management.

In this lesson you learned: built-in roles like read, readWrite, and dbAdmin cover common access patterns at database scope, custom roles let you define collection-level privileges with only the exact actions required, and principle of least privilege — each user and service account should hold only the permissions it genuinely needs. Next up we cover encryption at rest and TLS in transit.