mongo Schema Audit Messages

On this page

Audit Event Actions, Details, and Results

In the mongo schema, recorded log messages have this syntax:

{
  atype: <string>,
  ts : { $date: <timestamp> },
  uuid : { $binary: <string>, $type: <string> },
  local: { ip: <string>, port: <int> || isSystemUser: <boolean> || unix: <string> },
  remote: { ip: <string>, port: <int> || isSystemUser: <boolean> || unix: <string> },
  users : [ { user: <string>, db: <string> }, ... ],
  roles: [ { role: <string>, db: <string> }, ... ],
  param: <document>,
  result: <int>
}

Field	Type	Description
`atype`	string	Action type. See Audit Event Actions, Details, and Results.
`ts`	document	Document that contains the date and UTC time of the event, in ISO 8601 format.
`uuid`	document	A document that contains a message identifier. The UUID identifies a client connection. Use the UUID to track audit events connected to that client. The value of the `$type` field is BSON type `04` which indicates that the `$binary` field contains a UUID. New in version 5.0.
`local`	document	A document that contains the `ip` address and the `port` number of the running instance. Starting in MongoDB 5.0, can alternatively be a document with one of these fields: `isSystemUser` that indicates whether the user who caused the event was a system user. Logged for self-referential jobs initiated by a background process that runs on the same server instance. `unix` that contains the MongoDB socket file path if the client connects through a Unix domain socket. Starting in MongoDB 5.0, the `local` field is deprecated. Use the `localEndpoint` field in the clientMetadata audit message instead. Changed in version 5.0.
`remote`	document	A document that contains the `ip` address and the `port` number of the incoming connection associated with the event. Starting in MongoDB 5.0, can alternatively be a document with one of these fields: `isSystemUser` that indicates whether the user who caused the event was a system user. Logged for self-referential jobs initiated by a background process that runs on the same server instance. `unix` that contains the MongoDB socket file path if the client connects through a Unix domain socket. Changed in version 5.0.
`users`	array	Array of user identification documents. Because MongoDB allows a session to log in with different user per database, this array can have more than one user. Each document contains a `user` field for the username and a `db` field for the authentication database for that user.
`roles`	array	Array of documents that specify the roles granted to the user. Each document contains a `role` field for the name of the role and a `db` field for the database associated with the role.
`param`	document	Specific details for the event. See Audit Event Actions, Details, and Results.
`result`	integer	Error code. See Audit Event Actions, Details, and Results.

Audit Event Actions, Details, and Results

The following table lists for each atype or action type, the associated param details and the result values, if any.

atype

param

result

authenticate

{
  user: <user name>,
  db: <database>,
  mechanism: <mechanism>
}

Starting in MongoDB 5.0, authenticate:

Is logged for incomplete authentication attempts.
Includes the principle name and identifier in mechanism for external authentication mechanisms such as x.509 and Amazon Web Services Identity and Access Management (AWS-IAM) (see authMechanism).

Changed in version 5.0.

- Success
- Authentication Failed
- Mechanism Unavailable
- Authentication Abandoned

authCheck

{
  command: <name>,
  ns: <database>.<collection>,
  args: <command object>
}

ns field is optional.

args field may be redacted.

By default, the auditing system logs only the authorization failures. To enable the system to log authorization successes, use the auditAuthorizationSuccess parameter.

Enabling auditAuthorizationSuccess degrades performance more than logging only the authorization failures.

Starting in MongoDB 5.0, authCheck is not logged for actions that are generated internally.

Changed in version 5.0.

0 - Success

13 - Unauthorized to perform the operation.

clientMetadata

{
   localEndpoint : {
      ip : <IP address of running instance>,
      port : <port of running instance>
   } || {
      unix : <MongoDB socket file path if connecting through
              a Unix domain socket>
   },
   clientMetadata : {
      driver : {
         name : <client driver name>,
         version : <client driver version>
      },
      os : {
         type : <client operating system type>,
         name : <client operating system name>,
         architecture : <client operating system architecture>,
         version : <client operating system version>
      },
      platform : <client platform name>,
      application : {
         name : <client application name>
      }
   }
}

Contains the client metadata. Logged when the client runs the hello command.

For more details, see Client Data.

New in version 5.0.

0 - Success

createCollection

{
   ns: <database>.<collection || view>,
   viewOn: <database>.<collection>,
   pipeline: [ <pipeline definition> ]
}

Logged when a:

Collection is created.
View is created, with the view name logged in the ns field.

Starting in MongoDB 5.0, this additional information is logged for a view:

viewOn field with the database and collection for the view.
pipeline field with the aggregation pipeline definition for the view.

Changed in version 5.0.

0 - Success

createDatabase

{ ns: <database> }

0 - Success

createIndex

{
  ns: <database>.<collection>,
  indexName: <index name>,
  indexSpec: <index specification>,
  indexBuildState: <index build state>
}

Possible values for indexBuildState are:

IndexBuildStarted
IndexBuildSucceeded
IndexBuildAborted

Starting in MongoDB 5.0, createIndex audit events are:

Logged at the start and end of index creation, and includes a message indicating if the index was successfully created or not.
Attributed to the originating user for the action that caused the createIndex audit event.
Logged for a createCollection event if the collection has an index.

Changed in version 5.0.

0 - Success

276 - Index build aborted.

The audit message contains result code 276 for createIndex audit events with IndexBuildState set to IndexBuildAborted. The audit message contains result code 0 for createIndex audit events with IndexBuildState set to IndexBuildStarted or IndexBuildSucceeded.

directAuthMutation

{
   document: {
      <collection modifications>
   },
   ns: <database>.<collection>,
   operation: <database operation>
}

Logged when a database operation directly modifies the contents of the admin.system.users or admin.system.roles collections.

New in version 5.0.

0 - Success

renameCollection

{
  old: <database>.<collection>,
  new: <database>.<collection>
}

0 - Success

dropCollection

{
   ns: <database>.<collection || view>,
   viewOn: <database>.<collection>,
   pipeline: [ <pipeline definition> ]
}

Logged when a:

Collection is dropped.
View is dropped, with the view name logged in the ns field.

Starting in MongoDB 5.0, this additional information is logged for a view:

viewOn field with the database and collection for the view.
pipeline field with the aggregation pipeline definition for the view.

In addition, starting in MongoDB 5.0, a dropCollection audit event is logged when a dropDatabase event occurs.

Changed in version 5.0.

0 - Success

26 - NamespaceNotFound

If the collection or view does not exist, the audit message shows the return code as result: 26.

dropDatabase

{ ns: <database> }

0 - Success

dropIndex

{
  ns: <database>.<collection>,
  indexName: <index name>
}

0 - Success

createUser

{
  user: <user name>,
  db: <database>,
  customData: <document>,
  roles: [
     {
       role: <role name>,
       db: <database>
     },
     ...
  ]
}

The customData field is optional.

0 - Success

dropUser

{
  user: <user name>,
  db: <database>
}

0 - Success

dropAllUsersFromDatabase

{ db: <database> }

0 - Success

getClusterParameter

{
    requestedClusterServerParameters: <parameters>
}

0 - Success

setClusterParameter

{
    originalClusterServerParameter: <original parameter value>,
    updatedClusterServerParameter": <new parameter value>
}

0 - Success

updateCachedClusterServerParameter

{
    originalClusterServerParameter: <original parameter value>,
    updatedClusterServerParameter": <new parameter value>
}

Logged when a parameter is changed because of:

Propagation of a setClusterParameter command
Replication event such as rollback
A refresh of new cluster parameter values from the config server on mongos

0 - Success

updateUser

{
  user: <user name>,
  db: <database>,
  passwordChanged: <boolean>,
  customData: <document>,
  roles: [
     {
       role: <role name>,
       db: <database>
     },
     ...
  ]
}

The customData field is optional.

0 - Success

grantRolesToUser

{
  user: <user name>,
  db: <database>,
  roles: [
     {
       role: <role name>,
       db: <database>
     },
     ...
  ]
}

0 - Success

revokeRolesFromUser

{
  user: <user name>,
  db: <database>,
  roles: [
     {
       role: <role name>,
       db: <database>
     },
     ...
  ]
}

0 - Success

createRole

{
  role: <role name>,
  db: <database>,
  roles: [
     {
       role: <role name>,
       db: <database>
     },
     ...
  ],
  privileges: [
    {
      resource: <resource document>,
      actions: [ <action>, ... ]
    },
    ...
  ]
}

The roles and the privileges fields are optional.

For details on the resource document, see Resource Document on Self-Managed Deployments. For a list of actions, see Privilege Actions for Self-Managed Deployments.

0 - Success

updateRole

{
  role: <role name>,
  db: <database>,
  roles: [
     {
       role: <role name>,
       db: <database>
     },
     ...
  ],
  privileges: [
    {
      resource: <resource document>,
      actions: [ <action>, ... ]
    },
    ...
  ]
}

The roles and the privileges fields are optional.

For details on the resource document, see Resource Document on Self-Managed Deployments. For a list of actions, see Privilege Actions for Self-Managed Deployments.

0 - Success

dropRole

{
  role: <role name>,
  db: <database>
}

0 - Success

dropAllRolesFromDatabase

{ db: <database> }

0 - Success

grantRolesToRole

{
  role: <role name>,
  db: <database>,
  roles: [
     {
       role: <role name>,
       db: <database>
     },
     ...
  ]
}

0 - Success

revokeRolesFromRole

{
  role: <role name>,
  db: <database>,
  roles: [
     {
       role: <role name>,
       db: <database>
     },
     ...
  ]
}

0 - Success

grantPrivilegesToRole

{
  role: <role name>,
  db: <database>,
  privileges: [
    {
      resource: <resource document>,
      actions: [ <action>, ... ]
    },
    ...
  ]
}

For details on the resource document, see Resource Document on Self-Managed Deployments. For a list of actions, see Privilege Actions for Self-Managed Deployments.

0 - Success

revokePrivilegesFromRole

{
  role: <role name>,
  db: <database name>,
  privileges: [
    {
      resource: <resource document>,
      actions: [ <action>, ... ]
    },
    ...
  ]
}

For details on the resource document, see Resource Document on Self-Managed Deployments. For a list of actions, see Privilege Actions for Self-Managed Deployments.

0 - Success

replSetReconfig

{
  old: {
   _id: <replicaSetName>,
   version: <number>,
   ...
   members: [ ... ],
   settings: { ... }
  },
  new: {
   _id: <replicaSetName>,
   version: <number>,
   ...
   members: [ ... ],
   settings: { ... }
  }
}

For details on the replica set configuration document, see Self-Managed Replica Set Configuration.

0 - Success

enableSharding

{ ns: <database> }

0 - Success

shardCollection

{
  ns: <database>.<collection>,
  key: <shard key pattern>,
  options: { unique: <boolean> }
}

0 - Success

addShard

{
  shard: <shard name>,
  connectionString: <hostname>:<port>,
}

When a shard is a replica set, the connectionString includes the replica set name and can include other members of the replica set.

0 - Success

refineCollectionShardKey

{
  ns: <database>.<collection>,
  key: <shard key pattern>
}

0 - Success

removeShard

{ shard: <shard name> }

0 - Success

shutdown

{ }

Indicates commencement of database shutdown.

0 - Success

applicationMessage

{ msg: <custom message string> }

See logApplicationMessage.

0 - Success

logout

{
  reason: <string>,
  initialUsers: [ <document>, ... ],
  updatedUsers: [ <document>, ... ],
}

reason will be either:

"Explicit logout from <database>"
"Implicit logout due to client connection closure"

initialUsers is an array of documents containing users authenticated on the current client prior to logout.

updatedUsers is an array of documents containing users expected to be authenticated on the current client after the logout event.

Each document in initialUsers and updatedUsers contains:

user: the username
db: the database user is authenticated to

New in version 5.0.

0 - Success

startup

{
    startupOptions: <document>,
    initialClusterServerParameter: <array of documents>
}

startupOptions contains all of the options that the node has after startup
initialClusterServerParameters contains the initial values of the cluster server parameters that the node has at the end of startup:
- after they have been loaded from storage (for mongod)
- after they have been refreshed from the config server (for mongos).

New in version 5.0.

Changed in version 6.1.

0 - Success

Back

Audit Messages

OSCF Schema