Shulou(Shulou.com)06/01 Report--

For a perfect database system, authority control is necessary, and mongodb is no exception. An unauthenticated database has proved to be a breakthrough for *, so whatever the reason, database authentication is very important for a production system.

After MongoDB 3.0, the password authentication mechanism for user login is: SCRAM-SHA-1 (default, salt-based response authentication) MONGODB-CR (general response authentication, 3.6obsolete, 4.0delete), x.509 Certificate (certificate-based SSL/TLS encryption authentication), LDAP Proxy (authentication based on LDAP system, only supported by enterprise version), Kerberos (based on Kerberos authentication, only supported by enterprise version), generally speaking, the default is very good.

Then mongodb also has an internal authentication policy, mainly to prevent data from being intercepted, including: keyfile (SCRAM-based responsive authentication), x.509 Certificate (certificate-based SSL/TLS encryption), for internal, if not special cases, the use of keyfile is sufficient.

Add mongodb authentication information to a single database (basic authentication knowledge)

First of all, mongodb itself does not require authentication login, that is, authentication-free direct login is allowed, but for security reasons, we should be more rigorous and add authentication login to use, but mongodb is different from mysql and oracle authorization, which is more strange. Let's take a look at it.

First of all, you also need to turn on the parameters.

# Open the configuration file vim / usr/local/mongodb/mongod_data_40001.conf. . . # whether to enable the authentication mode, now turn it on to use auth = true# to close the authentication mode. In conflict with the above, it was previously enabled. Now, the cluster authentication file specified by # noauth = true# is closed. If you do not open the authentication, you do not need to specify the authentication mode. You need to use openssl to generate the authentication mode. Do not study the specified access address of # keyFile = / data/mongodb/data/keyfile# for the time being. After that, the default is 127.0.0.1, but this parameter must be set after 3.6 to start. Configuration 0.0.0.0 represents a network-wide match # bind_ip=0.0.0.0

Parameter is turned on, and login needs to be restarted.

# Log in to operate mongo-port=40001MongoDB shell version v3.4.16-rc0connecting to: mongodb://127.0.0.1:40001/MongoDB server version: 3.4.16-rc0# > show dbs2018-07-17 × × × 5mongodb://127.0.0.1:40001/MongoDB server version 043.4.16-rc0# 34.0090.0800 E QUERY [thread1] Error: listDatabases failed: {"ok": 0, "errmsg": "not authorized on admin to execute command {listDatabases: 1.0}", "code": 13 "codeName": "Unauthorized"}: _ getErrorWithCode@src/mongo/shell/utils.js:25:13Mongo.prototype.getDBs@src/mongo/shell/mongo.js:62:1shellHelper.show@src/mongo/shell/utils.js:788:19shellHelper@src/mongo/shell/utils.js:678:15@ (shellhelp2): 1:1 >

There seems to be an error, but please calm down, this is a normal phenomenon, because before the default is authentication-free, now you have turned on authentication, and you have not created a user, it must be an error, but don't worry, because you originally don't have a user password, so it can be built.

Note, however, that in the initial password-free state, you can only create users and passwords by logging in to the address 127.0.0.1, so you need to pay attention to the value of the parameter bind_ip.

# enter the admin database, which is also the current user authentication library > use adminswitched to db admin# authorization > db.createUser ({user: "adminuser", pwd: "admin123", roles: [{role: "userAdminAnyDatabase", db: "admin"}]}) Successfully added user: {"user": "adminuser", "roles": [{"role": "userAdminAnyDatabase" "db": "admin"}]} # create one more try > db.createUser ({user: "root", pwd: "root123", roles: [{role: "root", db: "admin"}]}) 2018-07-17 × × 5db.createUser 00.167mm 0800 E QUERY [thread1] Error: couldn't add user: not authorized on admin to execute command {createUser: "root", pwd: "xxx", roles: [{role: "root" Db: "admin"}], digestPassword: false, writeConcern: {w: "majority", wtimeout: 600000.0}}: _ getErrorWithCode@src/mongo/shell/utils.js:25:13DB.prototype.createUser@src/mongo/shell/db.js:1292:15@ (shell): 1:1 >

Wrong again? Yes, you already have a user at this time, so you refuse your operation. You need to authenticate the user you just built.

# authenticate the user you just created > db.auth ("adminuser", "admin123") 1 > use adminswitched to db admin# create user again > db.createUser ({user: "root", pwd: "root123", roles: [{role: "root", db: "admin"}]}) Successfully added user: {"user": "root", "roles": [{"role": "root" "db": "admin"}]} > db.auth ("root", "root123") 1 > show dbsadmin 0.000GBlocal 0.000GB >

No problem this time, solved the problem, to create more users, or even refined to individual databases to create users, you can do this:

Use foo;db.createUser ({user: 'foo', pwd:' bar', roles: [{role: 'readWrite', db:' foo'}]}) db.auth ('foo',' bar')

This involves a special knowledge point of mongodb-the concept of authentication library.

Mongodb is different from other databases in that authentication information is refined into a database, rather than centralized management like mysql,oracle,sql server, which is stored in a user table.

Users of different databases can be stored in different databases. For example, foo, the user of the Foo library, is only stored in the foo library, he cannot log in to the admin library, and there is no foo user information in the admin library. Similarly, root, the user of the admin library, does not exist in the foo library, but root users can log in to foo because the root user has more privileges (nonsense). However, if you delete the foo library, the foo user will be deleted "by the way", that is, the user and the library will be completely removed.

So we have two different ideas, based on the concept of convenient management, we should focus on management, for the concept of authentication library, we should build them all on the admin library, and then subdivide the permissions, delete the library can sometimes just delete the login user. For security reasons, we can not let some abandoned users exist, because the feature of mongodb is that there is no create action, as long as you have permission, you can create libraries and tables automatically.

Then there is the second knowledge point of mongodb-role rights management.

Mongodb creates users who distinguish permissions by role role, similar to the familiar oracle and sql server (role management is not supported until after mysql8.0), which is not special. As for what role options are available, you can take a look at show roles. Our main commonly used are global super administrator userAdminAnyDatabase (which is also the first user right we need to create), readWriteAnyDatabase,readWrite,readAnyDatabase,read,root and so on.

Each role represents a different set of permissions, which can be refined to the scope of each user's permissions. For example, read can only be queried by find, readWrite is a typical addition, deletion, query and change, and the familiar root is full control of permissions.

Mongos > show roles {"role": "_ system", "db": "admin", "isBuiltin": true, "roles": [], "inheritedRoles": []} {"role": "backup", "db": "admin", "isBuiltin": true, "roles": [], "inheritedRoles": []} {. . .} {"role": "read", "db": "admin", "isBuiltin": true, "roles": [], "inheritedRoles": [] {"role": "readAnyDatabase", "db": "admin", "isBuiltin": true, "roles": [], "inheritedRoles": []} {"role": "readWrite" "db": "admin", "isBuiltin": true, "roles": [], "inheritedRoles": []} {"role": "readWriteAnyDatabase", "db": "admin", "isBuiltin": true, "roles": [], "inheritedRoles": []} {"role": "restore", "db": "admin" "isBuiltin": true, "roles": [], "inheritedRoles": []} {"role": "root", "db": "admin", "isBuiltin": true, "roles": [], "inheritedRoles": []} {"role": "userAdmin", "db": "admin", "isBuiltin": true "roles": [], "inheritedRoles": []} {"role": "userAdminAnyDatabase", "db": "admin", "isBuiltin": true, "roles": [], "inheritedRoles": []}

There is no detailed analysis here, most of them are similar to the literal meaning, very good.

Now that the creation is complete, let's try the following login method with user name:

[root@localhost] # mongo 10.21.14.16:40001/admin-u root-p "root123" MongoDB shell version v3.4.16-rc0connecting to: mongodb://10.21.14.16:40001/adminMongoDB server version: 3.4.16-rc0 > show dbsadmin 0.000GBlocal 0.000GB >

It can be used normally.

Of course, the user must be able to modify and delete the information. I won't go into details here, but attach the command reference.

# suppose we created a new user ttt, then we will not parse > use admin > db.createUser ({user: "ttt", pwd: "123", roles: [{role:" root ", db:" admin "}]}) > db.auth (" ttt "," 123") # to view all the user information now, there will be a ttt. > db.system.users.find () {"_ id": "admin.adminuser", "user": "adminuser" "db": "admin", "credentials": {"SCRAM-SHA-1": {"iterationCount": 10000, "salt": "jLubKc6ODHMxCnjFeeJuog==", "storedKey": "l1cL39bnvkw2fecw1DHdKM0TM7s =", "serverKey": "ZD+EZymr8OhlwMZ/0h35Qn8QHE4="}}, "roles": [{"role": "userAdminAnyDatabase", "db": "admin"}]} {"_ id": "admin.root" "user": "root", "db": "admin", "credentials": {"SCRAM-SHA-1": {"iterationCount": 10000, "salt": "Fx2BRB2ZIJeD2X+bvM0ZIg==", "storedKey": "Yyo+vcxhv40vNXZwUNfnBTz × × × 30 =", "serverKey": "th4UbT+/aJcgOXvKx4TFDhX242k="}}, "roles": [{"role": "root" "db": "admin"}} {"_ id": "admin.ttt", "user": "ttt", "db": "admin", "credentials": {"SCRAM-SHA-1": {"iterationCount": 10000, "salt": "X58qg8jiiM3ju8v8Cywu8A =", "storedKey": "MO4lwHhFUn50Ja0/QCHeN4hObRQ=", "serverKey": "N9iUXgshDP9beTD8pNKfrmtl0V0 ="}} "roles": [{"role": "root", "db": "admin"}]} # another command can also see > db.getUsers () [{"_ id": "admin.adminuser", "user": "adminuser", "db": "admin" "roles": [{"role": "userAdminAnyDatabase", "db": "admin"}]}, {"_ id": "admin.root", "user": "root", "db": "admin" "roles": [{"role": "root", "db": "admin"}]}, {"_ id": "admin.ttt", "user": "ttt", "db": "admin" "roles": [{"role": "root", "db": "admin"}] # look at the new user > db.getUser ("ttt") {"_ id": "admin.ttt", "user": "ttt", "db": "admin" "roles": [{"role": "root", "db": "admin"}]} # We can modify all the information of the user by using the following command, # db.updateUser ("UESR", {modify information}) # now we need to change the password > db.updateUser ("ttt") {pwd: "789"}) # after modification, the old password login will report an error > db.auth ("ttt", "123") Error: Authentication failed.0# the new password will be fine > db.auth ("ttt", "789") "however, there is not only one way to change the password, the following is also fine > db.changeUserPassword (" ttt "," 456 ") # similarly, the old password login will report an error > db.auth (" ttt ") Error: Authentication failed.0# new password is fine > db.auth ("ttt", "456") it's easy to delete users > db.dropUser ("ttt") true# now you still want to log in Of course not > db.getUser ("ttt") 2018-07-18T09:38:38.504+0800 E QUERY [thread1] Error: not authorized on admin to execute command {usersInfo: "ttt"}: _ getErrorWithCode@src/mongo/shell/utils.js:25:13DB.prototype.getUser@src/mongo/shell/db.js:1518:1@ (shell): 1 just log in to another user > db.auth ("root") "root123") 1 > db.dropUser ("ttt") false > db.getUser ("ttt") null > db.getUsers () [{"_ id": "admin.adminuser", "user": "adminuser", "db": "admin", "roles": [{"role": "userAdminAnyDatabase" "db": "admin"}}, {"_ id": "admin.root", "user": "root", "db": "admin", "roles": [{"role": "root" "db": "admin"}]}] >

So much for the authentication of a single server.

Add mongodb authentication information to cluster database

As I said before, with mongodb, most people don't just use a single server, because this is the source distributed database. Using cluster authentication requires an additional keyfile compared to a single server. Of course, you can also use another one, which is not discussed here.

Let me explain here that the cluster has been set up at this time, but the users in the cluster have not been created yet, because you cannot walk without creating a keyfile.

First of all, open keyfile in all node configurations, configure the path, and make sure that mongodb has the permission of this file, whether you are a sharding cluster or a simple replica set, and enable it together on mongose, config. share, otherwise, if it is not configured, a permission error will be reported, and if it is a replica set and authorized, you need to do it again.

# Open the configuration file vim / usr/local/mongodb/mongod_data_40001.conf. . . # whether to enable the authentication mode, now turn it on to use auth = true# to close the authentication mode. In conflict with the above, it was previously enabled. Now, the cluster authentication file specified by # noauth = true# is closed. If you do not open the authentication, you do not need to specify the authentication mode. You need to use openssl to generate the authentication mode. Do not study the specified access address of keyFile = / data/mongodb/data/keyfile# for the time being. After that, the default is 127.0.0.1, but this parameter must be set after 3.6 to start. Configuration 0.0.0.0 represents a network-wide match # bind_ip=0.0.0.0

After the change, do not start in a hurry before starting, and do not restart in a hurry if you have already started, wait a moment and then restart.

Then, we need to generate this keyfile file

# generate a 64-bit key file openssl rand-base64 64 > keyfile# with openssl command and set its permission to 6000.Otherwise, it will report the error of too high privilege chmod 600keyfile#. Move it to the destination directory mv keyfile / data/mongodb/data/#. Remember to manipulate the permission to chown mongodb:mongodb / data/mongodb/data/keyfile.

Some people wonder why it is a 64-bit key file. Yes, it can really be more or less, for example:

Openssl rand-base64 741 > keyfileopenssl rand-base64 16 > keyfile

All of these can be used, however, system performance and data security issues should be considered. The more complex the secret key file is, the more resource-consuming the encryption and decryption of your internal system will be, especially in a highly concurrent environment. But if it's too simple, your data is more likely to be cracked and less secure. I am only a compromise here, so it is 64, if you are interested, you can set it according to the actual situation.

Then, restart each node, or if you don't start it, start it now, restart all services in the following order

Config copy set: first master library, and then slave library, let him slowly switch.

Router service: restart at will.

Shard copy set: first master library, and then slave library, let him slowly switch.

Finally, you start to create a user authorization, just do the same as above.

# if we don't have a good replica set or cluster, we still need to do it first, and I won't do the detailed analysis. > config = {_ id: "sljd_shard1", members: [{_ id:0, host: "172.25.40.80 id:0 40001"}, {_ id:1, host: "172.25.40.81R 40001"}, {_ id:2 Host: "172.25.40.82 config 40001"}} > rs.initiate (config) > rs.status () # then enter the admin database, which is also the current user authentication library shard1:PRIMARY > use adminswitched to db admin# authorization shard1:PRIMARY > db.createUser ({user: "root", pwd: "admin123", roles: [{role: "userAdminAnyDatabase", db: "admin"}]}) Successfully added user: {"user": "adminuser" "roles": [{"role": "userAdminAnyDatabase", "db": "admin"}]} # and then log in to shard1: PRIMARY > db.auth ("root", "admin123") # or mongo 172.25.40.80:40001/admin-u root-p "admin123"

And then we saw the user.

# Log in to the main library and pay attention to the authentication library mongo 172.25.40.80:40001/admin-u root-p "admin123" # check the user situation on the main library shard1:PRIMARY > db.getUsers () [{"_ id": "admin.root", "user": "root", "db": "admin" "roles": [{"role": "root", "db": "admin"}]}] # log in to the slave library. Note that the authentication library mongo 172.25.40.81:40001/admin-u root-p "admin123" # needs to do one more step to allow the query to be executed in the slave library, otherwise an error will be reported, because the slave library defaults to read-only shard1:SECONDARY > rs.slaveOk () # and then execute shard1:SECONDARY > db.getUsers () [{"_ id": "admin.root", "user": "root", "db": "admin" in the slave library. "roles": [{"role": "root", "db": "admin"}]]

Well, that's no problem.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.