About MongoDB
MongoDB is becoming increasingly popular alternative to other database offerings. What's really refreshing about it is that unlike some other established database leaders (Ahem.... big O) they do provide several mechanisms for authentication. This means flexibility!As of this writing, MongoDB offers the following authentication mechanisms:
Reference: http://docs.mongodb.org/manual/tutorial/enable-authentication/
- X.509 certificates
- LDAP with AD or OpenLDAP leveraging SASL
- Kerberos
What's the business problem here?
Typically the folks dealing with apps and databases are not experts on authentication. This means cognitive, cooperation and coordination issues and obviously time-to-production challenges.In addition, if your Linux/UNIX infrastructure does not implement a robust set of access control technologies, each additional node adds to the problem.
This post covers
- SASL (plain) integration leveraging PAM
- Limiting Access using Centrify Access components
A second post covers Kerberos integration.
How Centrify can accelerate and secure MongoDB deployments?
- By providing THE most robust and thoroughly tested way of integrating non-Windows platforms (Unix/Linux/OS X) to Active Directory.
- No need to worry about setting up multiple LDAP servers (Centrify is sites and services aware)
- In the SASL use case, no need to worry about plaintext communications since ultimately Centrify uses Kerberos.
- In the GSSAPI/Kerberos, Centrify maintains the environment for you and provides tools for ease of management.
- Faster results - time to market these capabilities
- Enhancing security by implementing privileged user management.
Basics: What is SASL?
As per Wikipedia: "Simple Authentication and Security Layer (SASL) is a framework for authentication and data security in Internet protocols. It decouples authentication mechanisms from application protocols, in theory allowing any authentication mechanism supported by SASL to be used in any application protocol that uses SASL."
The key here is that MongoDB supports SASL and SASL can use PAM. Since Centrify makes PAM work with AD out of the Box, implementation is very simple:
Implementation (on CentOS)
Note: You will need the Enterprise Edition of MongoDB to get this going. For instructions of how to set up, go here: http://docs.mongodb.org/manual/tutorial/install-mongodb-enterprise-on-red-hat-or-centos (use CentOS to follow along) - I will be elevating with dzdo:Test and Configure SASLAUTHD
Step 1: Make SASL(saslauthd) is in your system and working and they cyrus-sasl-plain is installed
$ cat /etc/redhat-release
CentOS release 6.5 (Final)
$ adinfo -v
adinfo (CentrifyDC 5.2.0-218)
$ service saslauthd status
saslauthd is stopped$ rpm -qa | grep cyrus-sasl-plain
cyrus-sasl-plain-2.1.23-13.el6_3.1.x86_64
Notes:
If the cyrus-sasl-plain package is not present, use yum or other utilities to add it.
The saslauthd is stopped, this means that the service is not set to start automatically.
If the cyrus-sasl-plain package is not present, use yum or other utilities to add it.
The saslauthd is stopped, this means that the service is not set to start automatically.
Step 2: Make sure that SASL is configured to work with PAM and identify the path for the socket.
$ cat /etc/sysconfig/saslauthd | grep MECH
MECH=pam
# Options sent to the saslauthd. If the MECH is other than "pam" uncomment the next line.
$ cat /etc/sysconfig/saslauthd | grep SOCKETDIR
SOCKETDIR=/var/run/saslauthd
$ cat /etc/sysconfig/saslauthd | grep SOCKETDIR
SOCKETDIR=/var/run/saslauthd
Step 3: Test SASL by determining your valid AD users and testing interactively
# to determine who can log in to your computer from AD
$ adquery user
cosmo.kramer:x:1149240408:1149240408:Cosmo Kramer:/home/cosmo.kramer:/bin/bash
george:x:1149240406:1149240406:George Constanza:/home/george:/bin/bash
$ dzdo saslauthd -a pam -d
saslauthd[4022] :main : num_procs : 5
saslauthd[4022] :main : mech_option: NULL
saslauthd[4022] :main : run_path : /var/run/saslauthd
saslauthd[4022] :main : auth_mech : pam
saslauthd[4022] :ipc_init : using accept lock file: /var/run/saslauthd/mux.accept
<...>
$ testsaslauthd -u cosmo.kramer -p <kramer's password> -s login -f /var/run/saslauthd/mux
0: OK "Success."
This means that SASL with PAM is working as expected.
Step 6: Now you can make SASL start automatically if needed
$ dzdo chkconfig saslauthd on
$ chkconfig | grep saslauthd
saslauthd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
Create a PAM configuration file for mongod
Step 7: Because we've configured SASL to use PAM, now we need a
configuration file that has the system or centrify entries. In my
example, I'm piggybacking on the sshd config since I already know it
works with AD users. We also want to make sure that the "other" PAM config file is leveraging the Centrify PAM modules as well
$ cp /etc/pam.d/sshd /etc/pam.d/mongod
$ cp /etc/pam.d/sshd /etc/pam.d/otherUltimately, for both auth, account, password and session, these files include password-auth (in CentOS), which basically has the Centrify PAM directives - here's an excerpt of password-auth:
cat /etc/pam.d/password-auth
# lines inserted by Centrify Direct Control (CentrifyDC 5.2.0-218)
auth sufficient pam_centrifydc.so
auth requisite pam_centrifydc.so deny
account sufficient pam_centrifydc.so
account requisite pam_centrifydc.so deny
session required pam_centrifydc.so homedir
password sufficient pam_centrifydc.so try_first_pass
password requisite pam_centrifydc.so deny
This is what makes the magic happen. The video below covers steps 1 thru 7.
Configure MongoDB
Step 8: Configure MongoDB Security for SASL and restart it.
Set the following parameters in the /etc/mongodb.conf file:
auth=true
setParameter=saslauthdPath=/var/run/saslauthd/mux
setParameter=authenticationMechanisms=PLAIN,MONGODB-CR
Auth has to be set to true and the parameter saslauthdPath has to be set to the socket in /var/run/saslauthd/mux - Make sure the folder and file have the correct permissions. Finally, the authenticationMechanisms havs to include Plain (for SASL).
To restart MongoDB with service, use:
$ service mongod restart
Test SASL/PAM authentication with MongoDB
To test, you'll need an externally identified user. We will use the same user we used to test SASL
Step 9: Create an externally identified user in MongoDB
$ mongo
MongoDB shell version: 2.6.5
connecting to: test
> db.getSiblingDB("admin")
admin
> use $external
switched to db $external
> db.createUser({user:"cosmo.kramer",
roles:[{role:"read",db:"reporting"}]})
The output should be:
Successfully added user: {
"user" : "cosmo.kramer",
"roles" : [
{
"role" : "read",
"db" : "reporting"
}
]
}
Step 10: Test SASL authentication inside MongoDB
$ mongo
MongoDB shell version: 2.6.5
connecting to: test
> db.getSiblingDB("$external").auth({mechanism: "PLAIN",user:'cosmo.kramer',pwd:'<kramer's password>',digestPassword: false})
The output should be:
1
The video below covers steps 8-10
Limiting access to MongoDB using PAM granular access controls leveraging Centrify
You may want to add an additional layer of security, for example, in a shared system, you may want to grant a super-set of users access to the box, but limit who can log in to MongoDB via SASL with PAM. For this, you have the ability to create a role with the PAM mongod access right.
Step 10: Create the MongoDB PAM Access right
- In Access Manager, navigate to Zone > Authorization > UNIX Rights Definitions > PAM Access
- Right Click and Select Add PAM Right, and set it up like this:
Name: MongoDB
Application: mongodb
At this point, if you have any role with the MongoDB database profile, you can add this PAM access right to make sure that they have access to MongoDB; other users with just the ssh right, will be able to log into the box, but won't be able to log into MongoDB.
The video below showcases how to leverage PAM Access rights as an additional security layer for MongoDB with Centrify:
The video below showcases how to leverage PAM Access rights as an additional security layer for MongoDB with Centrify:
No comments:
Post a Comment