MongoDB Security Certification

MongoDB Security authentication is not the same in the case of single instance and replica set, the single instance is relatively simple, as long as the--auth parameter is added at startup, but the replica set needs to be keyfile.

One, single instance

1. Start the service (do not add auth parameters first)

2. Switch to Admin library and add admin account after login

2.1 Creating a system administrator user

By default, the Super administrator can only be used for account management, not other database operations, you can authorize themselves to implement. Administrators in a production environment, if an account contains roles useradminanydatabase or useradmin, should be used only for account and role management, and no other roles should be granted.

(1) We must first create a super administrator, and then use the Super Administrator to create another account:

Use admin

Db.adduser ({User: "Superman", pwd: "Talent", Roles: ["Useradminanydatabase"]})

(2) Enable Admin database authentication for account, so that he can operate the admin database.
Db.auth ("root", "123456")//For Account authorization
Db.system.users.find (); View currently existing user information

(3) Use the Super account you just signed in the database (Admin) Mongo localhost:27017admin-u superman-p Superman

Now we can add users to other databases:

Like the test library.

Use test

Db.adduser ("text", "text")

Permissions granted to this user: (required, otherwise cannot read and write operations)

Db.auth ("text", "text")

(4) You can now log in with a new user and manipulate the test database.

3. Turn off the local exception logon method

Once you have a super administrator, you can consider shutting down local exceptions to log in

Here's how:

Restart the database, start with--setparameter enablelocalhostauthbypass=0 can, so login must use account authentication

4. Delete a user

Delete User to delete for a database

> Use test

Switched to DB test

> Db.removeuser ("superman11111")

5. Modify User Password

Ordinary users can only modify their own password, useradmin role account can modify the other user password

For example:

MONGO 192.168.69.54:40000/admin-u superman-p Superman

Use test

Db.changeuserpassword ("Test", "111")

Second, replica set authentication

The general idea of a replica set is the user name, password, and keyfile file, KeyFile requires that each replica set service be loaded at startup and if the same file is required, then the user name, password

The KeyFile file must meet the criteria:

(1) A minimum of 6 characters, less than 1024 bytes

(2) When the certificate does not consider the blank characters in the file

(3) The contents of the KeyFile file connected to the replica set and MONGOs must be the same

(4) must be Base64 encoded, but cannot have an equal sign

(5) file permissions must be x00, that is, you cannot assign any permissions to group members and other members

Note: Win under can be through Notepad file, enter any content, delete suffix after use, whether it is feasible still in the experiment

Take replica set Sh0 as an example: (The following is the Linux system operation, the win system out of the Create KeyFile file is not the same as other)

1. Generate the KeyFile file:

Performed on 54:

[[email protected] ~]# OpenSSL rand-base64 >/mongodb/scheme2/keyfile0 -- file content base64 encoded, altogether 100 characters

2. Modify file Permissions:

[Email protected] ~]# chmod 600/MONGODB/SCHEME2/KEYFILE0

Copy the generated files to the remaining machines on the replica set, and the directories can be different, with the attention to permissions.

3. Specify the--keyfile option at three machine start-up

Numactl --interleave=all mongod--replset sh0--port 10000 \

--dbpath=/mongodb/scheme2/sh0/data--logpath=/mongodb/scheme2/sh0/logs/sh0.log \

--logappend--fork--directoryperdb--bind_ip=127.0.0.1,192.168.69.54--nohttpinterface \

--keyfile=/mongodb/scheme2/keyfile0

This way, a machine without this file cannot join the replica set, and the SH1 and SH2 replica sets operate similarly.

Open the KeyFile, implicitly opened the Auth, this time the connection replica set will need to be authenticated, otherwise you can only operate the database by local exceptions.

Add users in the replica set need to start the service without the--keyfile parameter in addition to the single-instance method (access to any one of the replicator operation, the other replica assembly automatically synchronized), account addition, authorization after the successful re-join the KeyFile startup service, can be completed and used.

Authentication under three-copy set + Shard environment

Combining the authentication methods of the above two environments, we can realize the security authentication in the replica set + Shard environment, and need to pay attention to the following points

1. In a fragmented cluster environment, keyfile authentication is required between members of the replica set, MONGOs and the configuration server, and keyfile authentication between the replica sets, and all Mongod and MONGOs instances of the cluster use the same KeyFile file as the content.

2. Initialize and modify the replica set to operate from a local exception login

3. Because authentication is enabled, you need to establish an administrator account to log on remotely. To establish an administrator account, the administrator account from the remote login, you need to establish a user can operate a database, the client to use this user access to the database.

4. The Administrator account in the Shard cluster needs to have read and write access to the Admin and config databases in the configuration server for Shard-related operations

5. Each shard in the cluster has its own admin database, which stores the cluster's respective certificates and access rights. If you need to telnet to the Shard separately, you can set up the user in 3.2 ways

The following actions are relevant:

1. Start the configuration server in the cluster, route the process and replica set, each process must specify the KeyFile file, and the KeyFile content of each process is the same, detailed operation see 3.2.

2. Initialize the replica set.

3. Connect MONGOs, set up administrator account and normal account for the cluster, the steps are as follows;

(1) Create an Administrator account

Administrators need to have read and write access to the configuration servers in the cluster, including:

Create a new general administrator for the client to connect to the database in the cluster;

Shard-related permissions, such as viewing the Shard State, enabling sharding, setting the slice key, and so on.

First log in with local exceptions to create an administrator account:

[Email protected] ~]# MONGO --port 30000

mongos> Use admin

Db.adduser ({User: "Superman",

PWD: "Superman",

roles: ["Clusteradmin", "Useradminanydatabase", "Dbadminanydatabase", "Readwriteanydatabase"]})

Mongos> Db.auth ("Superman", "Superman")

mongos> use Config

Switched to DB Config

Mongos> Db.adduser ({User: "Superman",

PWD: "Superman",

roles: ["Clusteradmin", "Useradminanydatabase", "Dbadminanydatabase", "Readwriteanydatabase"]})

Mongos> Db.auth ("Superman", "Superman")

(2) Log in to the MONGOs process with the administrator account established above, enable sharding on the database (such as test), set the collection key.

(3) Log in with the Administrator account to create a new account that allows him to read and write the database test

[Email protected] ~]# MONGO localhost:30000/admin-u superman-p Superman

mongos> Use test

Switched to DB test

Mongos> db.adduser ("Test", "test")

{

"User": "Test",

"ReadOnly": false,

"pwd": "A6de521abefc2fed4f5876855a3484f5",

"_id": ObjectId ("51fb5d4ecaa5917203f37f63")

}

Mongos> Db.auth ("Test", "test")

1

(4) Log in with the new account test and manipulate the database test

[Email protected] ~]# MONGO localhost:30000/test-u test-p test

MongoDB Shell version:2.4.4

Connecting To:localhost:30000/test

> for (var i = 1; i < 100000; i++) Db.test.insert ({x:i, c_id:i});

Description: After enabling authentication for a shard cluster, the local exception login is unable to perform the Shard operation because it only has the admin database read and write permission. For this example, adding shards, viewing the Shard state, and so on, needs to be logged in with a Superman account. Execute the database test operation with the test account number, which is provided to the client account.

User authentication login In four Java operations

For authentication-initiated services, operations in Java Add a DB validation to the original base

DB db = Mongo.getdb ("dbname");

Boolean auth = db.authenticate ("name", "Password". ToCharArray ());

Verify success Returns True otherwise false

Note: DB authentication can only be done once, and if it succeeds, it cannot continue validation, otherwise it will report a duplicate validation exception

Then you can do it on demand

Section Reference http://www.91linux.com/html/article/database/MongoDB/2013/0923/22679.html

Related References http://www.linuxidc.com/Linux/2012-06/63588.htm

Http://www.dotblogs.com.tw/newmonkey48/archive/2012/12/05/85431.aspx

Http://www.cnblogs.com/-clq/archive/2012/03/02/2376972.html

http://blog.csdn.net/lzy_1515/article/details/7027474

Http://www.blogjava.net/anchor110/articles/385978.html

http://www.oschina.net/code/snippet_35115_2888

Http://blog.sina.com.cn/s/blog_8413c1e201019l4e.html

Http://www.linuxidc.com/Linux/2013-07/86926.htm

Http://www.cnblogs.com/zcy_soft/archive/2011/04/09/2010578.html

MongoDB Security Certification