MongoDB configures user access control
1. Experimental principles
Understanding the admin database: When installing MongoDB, the admin database will be automatically created. This is a special database that provides functions that ordinary databases do not have. For example, some account roles give users permission to operate multiple databases, and these roles can only be used in the admin database. Created in . When checking credentials, MongoDB will check the user account in the specified database and the admin database.
Create user account
An important part of database administration is creating user accounts that can manage users and databases, as well as read and write to the database. To add a user, use methods in the MongoDB shell createUser()。createUser()
that take a document object as a parameter, allowing you to specify a username, role, and password. The fields that can be specified in the document object are listed below.
MongoDB provides a variety of roles that can be assigned to user accounts. These roles allow you to grant complex permissions and restrictions to user accounts. Listed below are some common roles that can be assigned to users.
Tip: Roles readAnyDatabase、readWriteAnyDatabase、dbAdminAnyDatabase和userAdminAnyDatabase
can only be assigned to user accounts in the admin database because they specify permissions on all databases
2. Experimental steps
- Start the MongoDB database
- Create a super account now
The creation is successful, where user is the user name, pwd is the password, and roles are the roles of the specified user. You can use an empty array to set empty roles for the new user; in the roles field, you can specify built-in roles and user-defined roles. The roles in role can be selected.
- Next we close the MongoDB data service and verify the root account
- Before logging in, authentication should be enabled, open the mongodb.config file, and remove the # in front of "#auth =true".
- Start the mongod service
- Next we use the root super user and specify the admin library to log in.
- Query the database currently in use and query all database names
- Under the test database, create read-only users and read-write users
- View all users under the current library
2 accounts were created above, now verify their permissions
- Enter the exit command to exit the current user and enter the read-only user 'zhangyur'.
- Insert data into the collection mycollection
The insertion failed because we only gave it read-only permissions when we created the user, so data could not be inserted. We switched to the 'zhangyu' user with read-write permissions and inserted data again.
- Create a cross-database user, switch to the admin database, log in as the root user, and create a user for the test library under the admin library.
- Query all users
- You can see that the account kuaku of the 'test' library exists under the admin library. Switch to the test library to verify the kuaku user.
Authentication failed! We then switch to the 'admin' library to verify the kuaku user.
Certification successful! The results show that users created under admin cannot be directly authenticated in other libraries, but can only be authenticated under the user's creation library. The database account follows the database, and is authenticated wherever it is created.
- So many users have been created, let’s query all users
- Delete 'kuaku' user
At this point, the experiment is over!