Preset roles
DDS provides some preset roles with specific permissions and functions, which can be used to manage DDS instance or cluster. The following are the preset roles in DDS:
Role | Permission Description | Operation commands included |
read | This role has permissions to read all non-system collection data and subscribe to some of the system collections (system.indexes, system.js, system.namespaces). | changeStream, collStats, dbHash, dbStats, find, killCursors, listIndexes, listCollections |
readWrite | This role is based on the permissions of read role, with additional permissions to modify non-system collection data. However, this role only has modify permission for system.js in the system collection. | collStats, convertToCapped, createCollection, dbHash, dbStats, dropCollection, createIndex, dropIndex, find, insert, killCursors, listIndexes, listCollections, remove, renameCollectionSameDB, update |
dbAdmin | This role has permissions to perform specific administrative tasks, including schema-related operations, index management, and statistics collection. However, this role does not include permissions to manage users and roles. | For system collections (system.indexes, system.namespaces, system.profile), include command operations: collStats, dbHash, dbStats, find, killCursors, listIndexes, listCollections, dropCollection and createCollection (system.profile only) For non-system collections, include command operations: bypassDocumentValidation, collMod, collStats, compact, convertToCapped, createCollection, createIndex, dbStats, dropCollection, dropDatabase, dropIndex, enableProfiler, reIndex, renameCollectionSameDB, repairDatabase, storageDetails, validate |
userAdmin | This role has permissions to create and modify roles and users in the current database. This role allows arbitrary permissions to be granted to any user (including itself), thus indirectly providing access to the super user (root). If it is limited to the admin database, this role also includes cluster management permissions. | changeCustomData, changePassword, createRole, createUser, dropRole, dropUser, grantRole, revokeRole, setAuthenticationRestriction, viewRole, viewUser |
dbOwner | This role is a database management role in MongoDB that grants full permissions to the specified database. This role has the ability to manage the specified database and can perform various operations, such as creating, modifying, and deleting collections, indexes, and users. The dbOwner role has all permissions on a specified database, including creating, modifying, and deleting any collections, indexes, and users in the database. | createCollection, dropCollection, createIndex, dropIndex, createUser, updateUser, removeUser, dropAllUsersFromDatabase, grantRolesToUser, revokeRolesFromUser, dropAllRolesFromDatabase, viewRole, viewUser, convertToCapped, collMod, dbStats |
Custom roles
• This section, Manage Roles, returns exceptions, but not necessarily a dead link
DDS supports user-defined roles, which can be created and configured as needed, and assigned specific permissions and functions to users based on these roles. Custom roles can help administrators better manage DDS instances or clusters and improve security.
To create a custom role, you need to use the createRole command or the db.createRole() method, and specify the name, permissions, and other properties of the role. For details, see Manage Roles.
Manage roles
Create
To create a custom role, you need to use the createRole command or the db.createRole() method, and specify the name, permissions, and other properties of the role. Here's a template for creating a role: db.createRole(role, writeConcern)。
The parameter role is mandatory and the type is document; the parameter writeConcern: is used to specify the level of write concern for the command.
db.createRole(
{
role: "<name>",
privileges: [
{ resource: { <resource> }, actions: [ "<action>", ... ] },
...
],
roles: [
{ role: "<role>", db: "<database>" } | "<role>",
...
],
authenticationRestrictions: [
{
clientSource: ["<IP>" | "<CIDR range>", ...],
serverAddress: ["<IP>" | "<CIDR range>", ...]
},
...
]
}
)Parameter description:
Field | Type | Description |
role | string | Role name. |
privileges | Array | Mandatory parameter, the array element represents the permissions that a role has. If this parameter is set to an empty collection, it means that the role does not have any permissions. |
resource | Documentation | This parameter is used to specify the database name or collection name. |
actions | Array | This parameter corresponds to the list of operations available for the resource, among which the common operations include find, count, getMore, listDatabases, listCollections, listIndexes, insert, update, remove. |
roles | Array | Mandatory parameter, the array element is used to specify the role name that the role inherits. This can be a system preset role, such as read or readWrite, or a user-defined role. |
authenticationRestrictions | Array | This parameter is used to specify the IP addresses or IP address ranges that the role can accept. |
Update
In DDS, you can use the updateRole command or the db.updateRole() method to update the contents of a custom role. Updating a custom role typically involves the following two steps:
1.Get the current configuration information of a custom role to be updated.
You can use the db. getRole() command or the db. runCommand ({ getRole: "", rolesInfo: 1 }) method to obtain the current configuration information of a custom role to be updated. For example, the following command gets the current configuration information of a custom role named myrole:
db.runCommand({ getRole: "myrole", rolesInfo: 1 })2.Update the configuration information of a custom role.
You can use the updateRole command or the db.updateRole() method to update the configuration information of a custom role. For example, the following command updates the permissions of a custom role named myrole to read permissions:
db.updateRole("myrole", { privileges: [{ actions: ["read"], resource: { db: "", collection: "" } }] })It should be noted that updating the configuration information of a custom role requires to operate with caution, as incorrect operations may cause database security issues. Therefore, before updating a custom role, it is recommended to backup the database and test the effect of the update operation in a test environment.