MongoDB Audit LogThis blog post is another in the series on the Percona Server for MongoDB 3.4 bundle release. In this blog post, we’ll talk about the MongoDB audit log.

Percona’s development team has always invested in the open-source community a priority – especially for MongoDB. As part of this commitment, Percona continues to build MongoDB Enterprise Server features into our free, alternative, open-source Percona Server for MongoDB. One of the key features that we have added to Percona Server for MongoDB is audit logging. Auditing your MongoDB environment strengthens your security and helps you keep track of who did what in your database.

In this blog post, we will show how to enable this functionality, what general actions can be logged, and how you can filter only the information that is important for your use-case.

Enable Audit Log

Audit messages can be logged into syslog, console or file (JSON or BSON format). In most cases, it’s preferable to log to the file in BSON format (the performance impact is smaller than JSON). In the last section, you can find some simple examples of how to further query this type of file.

Enable the audit log in the command line or the config file with:

Just note that until this bug is fixed and released, if you’re using Percona Server for MongoDB and the --fork option while starting the mongod instance you’ll have to provide an absolute path for audit log file instead of relative path.

Actions logged

Generally speaking, the following actions can be logged:

  • Authentication and authorization
  • Cluster operations
  • Read and write operations (logged under authCheck event and require auditAuthorizationSuccess parameter to be enabled)
  • Schema operations
  • Custom application messages (logged under applicationMessage event if the client/app issues a logApplicationMessage command,  the user needs to have clusterAdmin role or the one that inherits from it to issue this command)

You can see the whole list of actions logged here.

By default, MongoDB doesn’t log all the read and write operations. So if you want to track those, you’ll have to enable the auditAuthorizationSuccess parameter. They then will be logged under the authCheck event. Note that this can have a serious performance impact.

Also, this parameter can be enabled dynamically on an already running instance with the audit log setup, while some other things can’t be changed once setup.

Enable logging of CRUD operations in the command line or config file:

Or to enable it on the running instance, issue this command in the client:

Filtering

If you don’t want to track all the events MongoDB is logging by default, you can specify filters in the command line or the config file. Filters need to be valid JSON queries on the audit log message (format available here). In the filters, you can use standard query selectors ($eq, $in, $gt, $lt, $ne, …) as well as regex. Note that you can’t change the filters dynamically after the start.

Also, Percona Server for MongoDB 3.2 and 3.4 have slightly different message formats. 3.2 uses a “params” field, and 3.4 uses “param” just like MongoDB. When filtering on those fields, you might want to check for the difference.

Filter only events from one user:

Filter events from several users based on username prefix (using regex):

Filtering multiple event types by using standard query selectors:

Filter read and write operations on all the collections in the test database (notice the double escape of dot in regex):

Example messages

Here are two example messages from an audit log file. The first one is from a failed client authentication, and the second one is where the user tried to insert a document into a collection for which he has no write authorization.

Querying audit log for specific event

The audit log feature is now working, and we have some data in the BSON binary file. How do I query it to find some specific event that interests me? Obviously there are many simple or more complex ways to do that using different tools (Apache Drill or Elasticsearch come to mind), but for the purpose of this blog post, we’ll show two simple ways to do that.

The first way without exporting data anywhere is using the bsondump tool to convert BSON to JSON and pipe it into the jq tool (command-line JSON processor) to query JSON data. Install the jq tool in Ubuntu/Debian with:

Or in Centos with:

Then, if we want to know who created a database with the name “prod” for example, we can use something like this (I’m sure you’ll find better ways to use the jq tool for querying this kind of data):

In the second example, we’ll use the mongorestore tool to import data into another instance of mongod, and then just query it like a normal collection:

The import is done, and now we can query the collection for the same data from the MongoDB client:

It looks like the audit log in MongoDB/Percona Server for MongoDB is a solid feature. Setting up tracking for information that is valuable to you only depends on your use case.

10 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Nils

How would one specify the syslog server, facility etc.?

0
Tomislav

Hi Nils,
you can specify “auditLog.destination” option to “syslog” and then “systemLog.syslogFacility” to the facility you wish to use for these messages.

0
Gauravkumar Mishra

how would one filter the drop collection and create collections, as well as include auditing for insert, delete on collections. its like a combination of audit.

0
hasan

can you please give an example in which i can apply filter for more than one user for audit logs. I want to give exact names of two different users in filter.
Thanks

0
hasan

I have tried and found that it can be achieved in following way

auditLog:
destination: file
format: BSON
path: /var/log/mongodb/audit.bson
filter: ‘{ “users.user”: { $in: [ “alice”, “bob”, “john” ]} }’

0
orefad

Is there a plan/way of rotating+compressing the log as they are written to one file and this can grow out of hand?

0
hasan

logrotate can be used to rotate logs

/var/log/mongodb/auditLog.bson
{
rotate 7
daily
missingok
notifempty
delaycompress
compress
dateext
sharedscripts
postrotate
/bin/kill -SIGUSR1 cat /var/lib/mongodb/mongod.lock 2> /dev/null 2> /dev/null || true
endscript
}

0
orefad

Thanks Hasan. I’ve implemented as above. Looking forward to when Mongo grows to the point where it’s an added line in the config file :).

0
Oded

do you need to restart Mongo to change the Auditing configuration?

0
kailash Kanojia

Hi Hasan, do we have any mechanism to include the client hostname in auditing log file, at present we only get remote IP which if dynamic may change and its difficult to trace from which machine an event triggered.

0