Security and Authentication

Mongo Security

You authenticatea username and password (加密方式) in the context ofa particular database. 

• Once authenticated, a normal user has full read and write access to the database. 
• You can also create read-only users that only have read access.

The admin database is special.  Several administrative commands can only run on the admin database.Also, authentication on admin gives a user read and write access to all databases on the server.//直接就有權限

Logging in using an admin account Although admin user accounts can access any database, you must log into the admin database. For example, if someAdminUser has an admin account, this login will fail: > use test > db.auth("someAdminUser", password) This one will succeed: > use admin > db.auth("someAdminUser", password)

1. To enable security, run the database (mongod process) with the --auth option (or --keyFile for replica sets and sharding). Youmust either have added a user to the admin db before starting the server with authentication, 
2. or add the first user from the localhost interface.//遠程不可以

Configuring Authentication and Security

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

We now have a user created for database admin.Note that if we have not previously authenticated, we now must if we wish to perform further operations, as there is now an admin user.

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

Now, let's configure a "regular" user for another database.

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

Finally, let's add a readonly user. (only supported in 1.3.2+)

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

Viewing Users

User information is stored in each database's system.users collection. For example, on a database projectx,projectx.system.users will contain user information.

We can view existing users for the current database with the query:

> db.system.users.find()

Changing Passwords

The shell addUser command may also be used to update a password: if the user already exists, the password simply updates.

Deleting Users

To delete a user:

db.removeUser( username )

or

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

Replica Set and Sharding Authentication

The only difference is that the servers use a key file to authenticate internal communication. A key file is basically a plaintext file which is hashed and used as an internal password.(用於Server之間的交流，而不是用戶連接服務器)

To set up replica sets and/or sharding with authentication:

1. Create a key file that can be copied to each server in the set. A key file is composed of characters in the Base64 set, plus whitespace and newlines (see About the Key File for details).
2. Modify this file's permissions to be only readable by the current user.
3. Start each server in the cluster (including all replica set members, all config servers, and all mongos processes) with the --keyFile /path/to/file option.
4. Each client connection to the database must be authenticated before it can be used, as with single-server authentication.

You do not need to use the --auth option, too (although there's no harm in doing so), --keyFile implies --auth. --auth does not imply --keyFile.

About the Key File

A key file must contain at least 6 Base64 characters and be no larger than 1KB (whitespace included). Whitespace characters are stripped (mostly for cross-platform convenience), so the following keys are identical to the database:

$ echo -e "my secret key" > key1
$ echo -e "my secret key\n" > key2
$ echo -e "my    secret    key" > key3
$ echo -e "my\r\nsecret\r\nkey\r\n" > key4 -e     //enable interpretation of backslash escapes

If you run mongod with -v, the key will be printed in the log.

example

Example If we had a two-member replica set with members a and b, we could start them up with authentication enabled by running: a$ echo "this is my super secret key" > mykey a$ chmod 600 mykey a$ mongod --keyFile mykey # other options... b$ echo "this is my super secret key" > mykey b$ chmod 600 mykey b$ mongod --keyFile mykey # other options... Then run rs.initiate() and so on. Using the Database with Replica Set Authentication On From the client's perspective, authentication works the same way with replica sets as it does with single servers. For example, suppose you create a new replica set and start the members with --keyFile. Connect to the master locally to add users: master$ mongo MongoDB shell version: x.y.z connecting to: test > db.addUser("foo", "bar") Clients should authenticate as usual when they make connections. any-member$ mongo -u foo -p MongoDB shell version: x.y.z Enter password: <bar>

MongoDB Masters  Introduction  Quickstart  Downloads  Drivers  Developer Zone  Admin Zone  Components  Journaling  MongoDB Monitoring Service  The Database and Caching  Production Notes  Replication  About the local database  Verifying Propagation of Writes with getLastError  Replica Sets  Replica Sets - Basics  Replica Sets slaveDelay  Replica Sets - Oplog  Replica Sets - Priority  Replica Sets - Rollbacks  Replica Sets - Voting  Why Replica Sets  Moving or Replacing a Member  Replica Set Versions and Compatibility  Replica Set Design Concepts

Key file permissions

On *NIX, group and everyone must have 0 permissions (up to 700 is allowed). If the permissions are too open on the key file, MongoDB will exit with an error to that effect. ????

Ports

Default TCP port numbers for MongoDB processes are as follows:

• Standalone mongod : 27017
• mongos : 27017
• shard server (mongod --shardsvr) : 27018  
• config server (mongod --configsvr) : 27019
• web stats page for mongod : add 1000 to port number (28017, by default).  Most stats pages in the HTTP UI are unavailable unless the --rest option is specified.  To disable the "home" stats page use --nohttpinterface.  (This port should be secured, if used, however, the information on the stats home page is read only regardless.)???

IP Address Binding

By default, a mongod server will listen on all available IP addresses on a machine. You can restrict this to a single IP address with the'bind_ip' configuration option for mongod.

Typically, this would be set to 127.0.0.1, the loopback interface, to require that mongod only listen to requests from the same machine (localhost).

To enable listening on all interfaces, remove the bind_ip option from your server configuration file.