Docs Menu

Docs HomeDevelop ApplicationsMongoDB Manual

auditConfig

On this page

  • Definition
  • Syntax
  • Parameter Fields
  • Behavior
  • Retrieving Audit Configurations
  • Setting Audit Configurations
  • Example
  • Learn More
auditConfig

New in version 7.1.

Available for both mongod and mongos.

Object that contains information on audit configurations from mongod and mongos server instances.

To set auditConfig for your deployment, run the following command on the admin database:

db.adminCommand( { setClusterParameter: { auditConfig: <value> } } )

To view current values for the auditConfig cluster parameter, run the following command on the admin database:

db.adminCommand( { getClusterParameter: "auditConfig" } )
auditConfig.auditAuthorizationSuccess

Type: boolean

Default: false

Enables the auditing of authorization successes for the authCheck action.

To audit read and write operations, auditConfig.auditAuthorizationSuccess must be set to true.

When auditConfig.auditAuthorizationSuccess is false, the audit system only logs the authorization failures for authCheck. When auditAuthorizationSuccess is false, auditing has less performance impact because the audit system only logs authorization failures.

auditConfig.filter

Type: document

Default: none

Filter expression that controls which types of operations that the audit system records.

The document fields can be any field in the audit message, including fields returned in the param document. The field values are query condition expressions.

To view a sample filter document, see the Examples section.

Auditing must be enabled to use auditConfig.

If runtime audit configuration is enabled, the auditAuthorizationSuccess parameter doesn't appear in the mongod or mongos configuration file. The server will fail to start if the parameter is present.

If you run getClusterParameter on auditConfig, nodes that do not participate in a runtime audit configuration return their current configuration file settings for auditLog.filter and setParameter.auditAuthorizationSuccess.

When you set audit configurations with setClusterParameter, changes immediately take effect on all config servers and shards in a sharded cluster.

Setting too wide of an audit filter or enabling auditConfig.auditAuthorizationSuccess can degrade performance.

The following example uses the setClusterParameter command to enable auditing when a collection is created or deleted. The audit messages have been reformatted. They appear on a single line in the log file.

db.adminCommand(
{
setClusterParameter: {
auditConfig: {
filter: {
atype: {
$in: [ "createCollection", "dropCollection" ]
}
},
auditAuthorizationSuccess: false
}
}
}
)

After setting the auditConfig parameter, if you create an inventory collection in the sales database, the audit system logs a message that resembles the following:

{
"atype" : "createCollection",
"ts" : { "$date" : "2021-08-09T13:45:05.372+00:00" },
"uuid" : { "$binary" : "RKU/YLizS6K9se2GUU7ZVQ==", "$type" : "04" },
"local" : { "ip" : "127.0.0.1", "port" : 27502 },
"remote" : { "ip" : "127.0.0.1", "port" : 51918 },
"users" : [],
"roles" : [],
"param" : { "ns" : "sales.inventory" },
"result" : 0
}

If the inventory collection is dropped from the sales database, the audit system logs a message similar to the following:

{
"atype" : "dropCollection",
"ts" : { "$date" : "2021-08-09T13:45:00.661+00:00" },
"uuid" : { "$binary" : "0gle4/pSQli+LUcz43ykag==", "$type" : "04" },
"local" : { "ip" : "127.0.0.1", "port" : 27502 },
"remote" : { "ip" : "127.0.0.1", "port" : 51928 },
"users" : [],
"roles" : [],
"param" : { "ns" : "sales.inventory" },
"result" : 0
}
← Cluster Parameters