Managing Amazon DocumentDB Users
In Amazon DocumentDB, users authenticate to a cluster in conjunction with a password. Each cluster has a master user and password that is established during cluster creation.
Note
All new users created before March 26, 2020 have been granted the dbAdminAnyDatabase
, readWriteAnyDatabase
, and clusterAdmin
roles. It is recommended that you reevaluate all users and modify the roles as necessary to enforce least privilege for all users in your clusters.
For more information, see Restricting Database Access Using Role-Based Access Control (Built-In Roles).
Master and serviceadmin
User
A newly created Amazon DocumentDB cluster has two users: the master user and the serviceadmin
user.
The master user is a single, privileged user that can perform administrative tasks and create additional users with roles. When you connect to an Amazon DocumentDB cluster for the first time, you must authenticate using the master user name and password. The master user receives these administrative permissions for an Amazon DocumentDB cluster when that cluster is created, and is granted the role of root
.
The serviceadmin
user is created implicitly when the cluster is created. Every Amazon DocumentDB cluster has a serviceadmin
user that provides AWS the ability to manage your cluster. You cannot log in as, drop, rename, change the password, or change the permissions for serviceadmin
. Any attempt to do so results in an error.
Note
The master and serviceadmin
users for an Amazon DocumentDB cluster cannot be deleted and the role of root
for the master user cannot be revoked.
If you forget your master user password, you can reset it using the AWS Management Console or the AWS CLI.
Creating Additional Users
After you connect as the master user (or any user that has the role createUser
), you can create a new user, as shown below.
db.createUser(
{
user: "sample-user-1",
pwd: "password123",
roles:
[{"db":"admin", "role":"dbAdminAnyDatabase" }]
}
)
To view user details, you can use the show users
command as follows. You can additionally remove users with the dropUser
command. For more information, see Common Commands.
show users
{
"_id" : "serviceadmin",
"user" : "serviceadmin",
"db" : "admin",
"roles" : [
{
"role" : "root",
"db" : "admin"
}
]
},
{
"_id" : "myMasterUser",
"user" : "myMasterUser",
"db" : "admin",
"roles" : [
{
"role" : "root",
"db" : "admin"
}
]
},
{
"_id" : "sample-user-1",
"user" : "sample-user-1",
"db" : "admin",
"roles" : [
{
"role" : "dbAdminAnyDatabase",
"db" : "admin"
}
]
}
In the example above, the new user sample-user-1
is attributed to the admin
database. This is always the case for a new user. Amazon DocumentDB does not have the concept of an authenticationDatabase
and thus all authentication is performed in the context of the admin
database.
When creating users, if you omit the db
field when specifying the role, Amazon DocumentDB will implicitly attribute the role to the database in which the connection is being issued against. For example, if your connection is issued against the database sample-database
and you run the following command, the user sample-user-2
will be created in the admin
database and will have readWrite
permissions to the database sample-database
.
db.createUser(
{
user: "sample-user-2",
pwd: "password123",
roles:
[{role: "readWrite"}]
}
)
Creating users with roles that are scoped across all databases (for example, readInAnyDatabase
) require that you are either in the context of the admin
database when creating the user or you explicitly state the database for the role when creating the user.
To switch the context of your database, you can use the following command.
use admin
To learn more about Role Based Access Control and enforcing least privilege amongst the users in your cluster, see Restricting Database Access Using Role-Based Access Control (Built-In Roles).
Automatically Rotating Passwords for Amazon DocumentDB
With AWS Secrets Manager, you can replace hardcoded credentials in your code (including passwords) with an API call to Secrets Manager to retrieve the secret programmatically. This helps ensure that the secret can’t be compromised by someone examining your code, because the secret simply isn’t there. Also, you can configure Secrets Manager to automatically rotate the secret for you according to a schedule that you specify. This enables you to replace long-term secrets with short-term ones, which helps to significantly reduce the risk of compromise.
Using Secrets Manager, you can automatically rotate your Amazon DocumentDB passwords (that is, secrets) using an AWS Lambda function that Secrets Manager provides.
For more information about AWS Secrets Manager and native integration with Amazon DocumentDB, see the following: