- Security >
- Security Reference >
- Built-In Roles
Built-In Roles¶
On this page
MongoDB grants access to data and commands through role-based authorization and provides built-in roles that provide the different levels of access commonly needed in a database system. You can additionally create user-defined roles.
A role grants privileges to perform sets of actions on defined resources. A given role applies to the database on which it is defined and can grant access down to a collection level of granularity.
Each of MongoDB’s built-in roles defines access at the database level for all non-system collections in the role’s database and at the collection level for all system collections.
MongoDB provides the built-in database user and
database administration roles on
every database. MongoDB provides all other built-in roles only on the
admin
database.
This section describes the privileges for each built-in role. You can also
view the privileges for a built-in role at any time by issuing the
rolesInfo
command with the showPrivileges
and
showBuiltinRoles
fields both set to true
.
Database User Roles¶
Every database includes the following client roles:
-
read
¶ Provides the ability to read data on all non-system collections and on the following system collections:
system.indexes
,system.js
, andsystem.namespaces
collections. The role provides read access by granting the following actions:
Database Administration Roles¶
Every database includes the following database administration roles:
-
dbAdmin
¶ Provides the following actions on the database’s
system.indexes
,system.namespaces
, andsystem.profile
collections:collStats
dbHash
dbStats
find
killCursors
dropCollection
andcreateCollection
onsystem.profile
only
Changed in version 2.6.4:
dbAdmin
added thecreateCollection
for thesystem.profile
collection. Previous versions only had thedropCollection
on thesystem.profile
collection.Provides the following actions on all non-system collections. This role does not include full read access on non-system collections:
-
dbOwner
¶ The database owner can perform any administrative action on the database. This role combines the privileges granted by the
readWrite
,dbAdmin
anduserAdmin
roles.
-
userAdmin
¶ Provides the ability to create and modify roles and users on the current database. This role also indirectly provides superuser access to either the database or, if scoped to the
admin
database, the cluster. TheuserAdmin
role allows users to grant any user any privilege, including themselves.The
userAdmin
role explicitly provides the following actions:
Cluster Administration Roles¶
The admin
database includes the following roles for administering the
whole system rather than just a single database. These roles include but are
not limited to replica set and sharded cluster administrative
functions.
-
clusterAdmin
¶ Provides the greatest cluster-management access. This role combines the privileges granted by the
clusterManager
,clusterMonitor
, andhostManager
roles. Additionally, the role provides thedropDatabase
action.
-
clusterManager
¶ Provides management and monitoring actions on the cluster. A user with this role can access the
config
andlocal
databases, which are used in sharding and replication, respectively.Provides the following actions on the cluster as a whole:
addShard
applicationMessage
cleanupOrphaned
flushRouterConfig
listShards
removeShard
replSetConfigure
replSetGetStatus
replSetStateChange
resync
Provides the following actions on all databases in the cluster:
On the
config
database, provides the following actions on thesettings
collection:On the
config
database, provides the following actions on all configuration collections and on thesystem.indexes
,system.js
, andsystem.namespaces
collections:On the
local
database, provides the following actions on thereplset
collection:
-
clusterMonitor
¶ Provides read-only access to monitoring tools, such as the MongoDB Cloud Manager monitoring agent.
Provides the following actions on the cluster as a whole:
connPoolStats
cursorInfo
getCmdLineOpts
getLog
getParameter
getShardMap
hostInfo
inprog
listDatabases
listShards
netstat
replSetGetStatus
serverStatus
shardingState
top
Provides the following actions on all databases in the cluster:
Provides the
find
action on allsystem.profile
collections in the cluster.Provides the following actions on the
config
database’s configuration collections andsystem.indexes
,system.js
, andsystem.namespaces
collections:
-
hostManager
¶ Provides the ability to monitor and manage servers.
Provides the following actions on the cluster as a whole:
applicationMessage
closeAllDatabases
connPoolSync
cpuProfiler
diagLogging
flushRouterConfig
fsync
invalidateUserCache
killop
logRotate
resync
setParameter
shutdown
touch
unlock
Provides the following actions on all databases in the cluster:
Backup and Restoration Roles¶
The admin
database includes the following roles for backing up and
restoring data:
-
backup
¶ Provides minimal privileges needed for backing up data. This role provides sufficient privileges to use the MongoDB Cloud Manager backup agent, or to use
mongodump
to back up an entiremongod
instance.Provides the following actions on the
mms.backup
collection in theadmin
database:Provides the
listDatabases
action on the cluster as a whole.Provides the
find
action on the following:- all non-system collections in the cluster
- all the following system collections in the cluster:
system.indexes
,system.namespaces
, andsystem.js
- the
admin.system.users
andadmin.system.roles
collections - legacy
system.users
collections from versions of MongoDB prior to 2.6
-
restore
¶ Provides privileges needed to restore data from backups. This role is sufficient when restoring data with
mongorestore
without the--oplogReplay
option. If runningmongorestore
with--oplogReplay
, however, therestore
role is insufficient to replay the oplog. To replay the oplog, create a user-defined role that hasanyAction
on anyResource and grant only to users who must runmongorestore
with--oplogReplay
.Provides the following actions on all non-system collections and
system.js
collections in the cluster; on theadmin.system.users
andadmin.system.roles
collections in theadmin
database; and on legacysystem.users
collections from versions of MongoDB prior to 2.6:Provides the following additional actions on
admin.system.users
and legacysystem.users
collections:Provides the
find
action on all thesystem.namespaces
collections in the cluster.Although,
restore
includes the ability to modify the documents in theadmin.system.users
collection using normal modification operations, only modify these data using the user management methods.
All-Database Roles¶
The admin
database provides the following roles that apply to all
databases in a mongod
instance and are roughly equivalent to their
single-database equivalents:
-
readAnyDatabase
¶ Provides the same read-only permissions as
read
, except it applies to all databases in the cluster. The role also provides thelistDatabases
action on the cluster as a whole.
-
readWriteAnyDatabase
¶ Provides the same read and write permissions as
readWrite
, except it applies to all databases in the cluster. The role also provides thelistDatabases
action on the cluster as a whole.
-
userAdminAnyDatabase
¶ Provides the same access to user administration operations as
userAdmin
, except it applies to all databases in the cluster. The role also provides the following actions on the cluster as a whole:The role also provides the following actions on the
admin.system.users
andadmin.system.roles
collections on theadmin
database, and on legacysystem.users
collections from versions of MongoDB prior to 2.6:Changed in version 2.6.4:
userAdminAnyDatabase
added the following permissions on theadmin.system.users
andadmin.system.roles
collections:The
userAdminAnyDatabase
role does not restrict the permissions that a user can grant. As a result,userAdminAnyDatabase
users can grant themselves privileges in excess of their current privileges and even can grant themselves all privileges, even though the role does not explicitly authorize privileges beyond user administration. This role is effectively a MongoDB system superuser.
-
dbAdminAnyDatabase
¶ Provides the same access to database administration operations as
dbAdmin
, except it applies to all databases in the cluster. The role also provides thelistDatabases
action on the cluster as a whole.
Superuser Roles¶
Several roles provide either indirect or direct system-wide superuser access.
The following roles provide the ability to assign any user any privilege on any database, which means that users with one of these roles can assign themselves any privilege on any database:
dbOwner
role, when scoped to theadmin
databaseuserAdmin
role, when scoped to theadmin
databaseuserAdminAnyDatabase
role
The following role provides full privileges on all resources:
-
root
¶ Provides access to the operations and all the resources of the
readWriteAnyDatabase
,dbAdminAnyDatabase
,userAdminAnyDatabase
andclusterAdmin
roles combined.root
does not include any access to collections that begin with thesystem.
prefix.For example, without the ability to insert data directly into the:data:system.users <admin.system.users> and
system.roles
collections in theadmin
database.root
is not suitable for writing or restoring data that have these collections (e.g. withmongorestore
.) To perform these kinds of restore operations, provision users with therestore
role.
Internal Role¶
-
__system
¶ MongoDB assigns this role to user objects that represent cluster members, such as replica set members and
mongos
instances. The role entitles its holder to take any action against any object in the database.Do not assign this role to user objects representing applications or human administrators, other than in exceptional circumstances.
If you need access to all actions on all resources, for example to run the
eval
orapplyOps
commands, do not assign this role. Instead, create a user-defined role that grantsanyAction
on anyResource and ensure that only the users who needs access to these operations has this access.