Learn about security features and authentication in MongoDB

TipsMake.com - In the following article, we will continue to introduce you about Security and Authentication features in the series of articles about MongoDB database management system . In essence, the basic account validation feature is available in MongoDB, but has been disabled in default mode, and in this mode the system requires at least 1 database to operate in a secure environment. protect (restrict network connection).

Concept of Environment Environment:

This is the default and recommended option, which is quite useful when running a database in the Trusted Environment without security functions from within the database as well as account validation (also known as memcached). ). Of course, during the configuration process, a minimum requirement is to ensure that only certain machines are allowed to access the database via TCP port.

Mongo Security:

The current version of Mongo only supports basic security mechanism. The user confirms the Username and Password information in a certain database. When this process is complete, a normal user account will have full access to read and write data to the database, besides, we can create accounts with read-only rights. (read only) depending on requirements.

However, admin database is a special case, some administrative commands can only operate on this admin database (and only be executed under an account with administrative rights). And on the other hand, the validation process on admin also allows users to read and write to all databases on the server.

Although admin accounts have access to all databases, we must log into the admin database. For example, if the account someAdminUser has admin rights, the login command below will fail:

> use test
> db.auth ("someAdminUser", password)

The following command will succeed:

> use admin
> db.auth ("someAdminUser", password)

To enable security, run the database (process desirable ) with the --auth option (or --keyFile to sharding and create a copy). The user is required to assign an account to the database admin before starting the server with the confirmation process, or assign the first user account from localhost (it is impossible to assign the first user from the non-database connection of mongo ).

You can refer to the corresponding concepts of Python, Ruby, Java and PHP.

Configuration Authentication and Security:

The first thing to do here is to create an administrator account to use for the entire server. And this account is stored in a special admin database. If there is no admin account, you can access the database from localhost interface without confirmation. Therefore, from the server running the database (or localhost) run the shell and configure the administrator account as follows:

$ ./mongo
> use admin
> db.addUser ("theadmin", "anadminpassword")

And we have the user account created in the admin database. Note that if you have not performed an account confirmation, you must do so immediately if you want to perform more operations.

> db.auth ("theadmin", "anadminpassword")

Next, create a normal user account for another database.

> use projectx
> db.addUser ("joe", "passwordForJoe")

And finally, read the readonly user account (only supported from version 1.3.2 and above):

> use projectx
> db.addUser ("guest", "passwordForGuest", true)

Check account information:

Basically, all user information is stored in each system.users collection of the database. For example, on projectx database, projectx.system.users is the component to store the information to be searched. We can see the accounts available in the current database with the query statement:

> db.system.users.find ()

Change Password:

The addUser shell command next to the basic function is also used to change the password in case if the user account is available, the password only needs to be updated. Some Mongo drivers also provide the same functionality in the database shell's addUser syntax.

Delete user account:

To do this, apply the command:

db.removeUser (username)

or:

db.system.users.remove ({user: username})

Replica Set and Sharding Authentication:

Replica set and sharding can use account validation mechanisms in version v1.9.1 or later (while in version v1.8, only replica set and no sharding are available). From the client side, this process is relatively homogeneous to use validation on a single server : make connections to the mongos system, create user accounts, and check and monitor that user when making a connection. .

The only difference is that the server will use the key file to confirm the internal communications. Basically, the key file is just a plain text file encrypted with the hash algorithm and used as an internal password.

To set up replica set or sharding with validation mechanisms, you need to follow the following process:

1. Creating a key file can be copied to different servers in the system, and this key file contains many characters based on the Base64 standard, whitespace and new blank lines.
2. Change the permissions of this file so that only current accounts can read and use.
3. Start each server in the cluster system (including all members of the replica set, configuration server and mongos process) with the option --keyFile / path / to / file
4. Each connection from the client to the database must be verified before use, similar to the validation process on a single server.

Security of Sharded:

When a user activates authentication on sharded clusters , the entire internal connection is secured through the entire mongos, not a single data source, like a single server or replica set . This is also an integral part of the system because security information and data are stored in the sharding configuration database and not directly on the shard. Another important thing is that shard clusters must always have clients connect through mongos, not directly to any data source such as a shard server or configuration server .

If you do not assign each user account on the shard source as well as each individual shard member, those accounts will be completely separate from the sharding user. These 2 accounts are different from sharded and shard clusters , users should be absolutely careful when distributing and applying them in practice.

Turn off or turn on the authentication mechanism on the available cluster:

To enable this mechanism on an existing cluster, please turn off the operation of all user members in the system, then reboot with the --keyFile option. And keep in mind that user accounts must be assigned before accessing remote data volumes. Conversely, if you want to turn off the identity mechanism, just restart the entire user system without the --keyFile parameter.

Some features about Key File:

A typical key file must contain at least 6 Base64 characters, capacity not exceeding 1KB (including spaces). These whitespace characters are quite simple (mostly compatible with many different platforms), so some of the following special keys are standardized and applied on many database systems:

$ echo -e "my secret key"> key1
$ echo -e "my secret keyn"> key2
$ echo -e "my secret key"> key3
$ echo -e "myrnsecretrnkeyrn"> key4

If you run the mongod command with the -v parameter, the keys will be saved to the log file.

Decentralization of Key File:

On * NIX, individual user groups and accounts must have 0 permissions (maximum of 700), if this permission level is not fully controlled, MongoDB will end with a display error. And at this time, permissions are not checked by mongod on Windows.

Port:

The default TCP port value for MongoDB is as follows:

1. Standalone mongod: 27017
2. mongos: 27017
3. shard server (mongod --shardsvr): 27018
4. config server (mongod --configsvr): 27019
5. Stat page for mongod: assign 1000 to port value (default is 28017 ). Most pages in the HTTP interface section are not displayed correctly until the --rest option is clearly defined. To turn off the home page, we use the –nohttpinterface option .

Besides, you can change the port with the port value right after starting mongod. Note that we should not rely on non standard ports as a Mongo server security method. Vulnerability checking tools will take advantage of this to look for weaknesses in users' systems.

IP Address Binding:

By default, the server mongod will "listen" to all IP addresses on the entire computer system. However, users can restrict or prohibit a certain IP address via bind_ip setup option for mongod . Typically, these values ​​will be converted to 127.0.0.1 , via the loopback interface to require that mongod only 'accept' signals from the same machines (similar to localhost ). To change it again, we just need to remove the bind_ip option from the configuration file on the server.