In this blog post we’ll look at how to go about securing MongoDB instances.
Authentication is one of the most important features of a database, and MongoDB supports it in different ways. Although it allows you to work without any authentication, the best practice is to enable authentication and give users only the permissions they need.
Instances without authentication allow all users to perform all the operations they feel like, and that is not safe at all.
Native Authentication
The MongoDB community version features more than one authentication method: SCRAM-SHA-1, MONGODB-CR, and x.509 Certificate Authentication. The current default method is SCRAM-SHA-1. The version prior to 3.0 used to have MONGODB-CR as its default method.
Percona Server for MongoDB also offers LDAP authentication free of charge where this feature is only available in the MongoDB enterprise version.
SCRAM-SHA-1 and MONGODB-CR check whether the user/password exists against a specific database and use challenge response authentication to verify user’s authenticity.
The x.509 authentication is based on certificates. It does not run challenge response algorithms. This method instead validates a certificate to prove client’s authenticity. It depends on a certificate authority and each client must have a valid certificate.
LDAP Authentication
The LDAP authentication uses an external LDAP server to authenticate the user by using authsasld in Linux. LDAP is commonly used to manage users in a network. There are advantages and disadvantages when using LDAP. One advantage is that it centralizes users. However, it depends on network connectivity to check user credentials and sasld tries to help with caching but it does have limitations. Please see further details here.
There are two different internal authentication methods for replica-set and shadings, where instances need to prove that they are expected members of the deployment. The first method is using a shared keyfile for all instances, and the second one is using a different x.509 certificate for each instance. It is important to know x.509 forces proper SSL coverage or replication while a key will not, but we will cover this topic in a different blog post.
Authorization and Roles
Once authenticated, users must be allowed to perform commands against the instance/replica-set/sharding. There are a few built-in roles that are able to cover almost all the user cases, and creating a user defined role is possible.
The current built-in roles are:
read
readWrite
dbAdmin
dbOwner
userAdmin
clusterAdmin
clusterManager
clusterMonitor
hostManager
backup/restore
readAnyDatabase
readWriteAnyDatabase
userAdminAnyDatabase
dbAdminAnyDatabase
root
and many more…
There is also the __system role, which is solely used for internal purposes.
Customer user and role by example
This shows how to both enable MongoDB authentication and create a user-defined role, where the user will only be able to read a specific collection. We are using tarballs for testing only. To perform a production installation please follow our docs.
Download Percona Server MongoDB:
Start the service with authentication:
Create root/admin user:
We are able to create the first user without authentication. The next users must be created by an authenticated user.
Login with the just created credentials:
Create database and collection:
create a user that can read all the collections in the percona database:
Now we see that this user can read not only the
but also the
. We don’t want users to read the
, so we are going to create a user-defined role.
Assign created role to the user:
Test access:
Please feel free to ping us on Twitter @percona with any questions and suggestions for securing MongoDB instances.