[SERVER-20883] Consolidate mongoS and mongoD auditing efforts Created: 12/Oct/15  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Security, Sharding
Affects Version/s: 3.0.6
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Adam Schwartz Assignee: Backlog - Security Team
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Assigned Teams:
Server Security
Participants:

 Description   

The mongod's and mongos's are not auditing the same operations

Our docs at http://docs.mongodb.org/manual/core/auditing/ say the the auditing capability is for both mongod and mongos instances. Schema DDL are among the operations that are supposed to be logged by the auditing system. The documentation makes no distinction between a mongos and mongod server.

The issue I found is that even if you execute explicit operations like "createCollection" and "dropCollection" from a mongo shell connected to a mongos, the mongos audit log does not show the operations. The DDL operations are only logged in the mongod audit log.

I brought up a sharded cluster using the same audit parameters for all components of the cluster, namely the mongos's, the mongod's and the config servers.

--setParameter auditAuthorizationSuccess=true     --auditDestination file --auditFormat JSON --auditPath /tmp/audit_file_hostname_serverType.log --auditFilter { $or : [ { "atype" : "authCheck", "param.command": { $in: [ "find", "insert", "delete", "update", "findandmodify"] } }, {"atype" : {$in : ["createCollection", "dropCollection"] } }] }

Only "atype" : "authCheck" records, meaning only inserts, updates and finds were in the mongos audit log.

I understand this is intended behavior, since the DDL is not really finalized until the mongod on the shard executes it. However, at the same time, the insert is also not finalized until the mongod on the correct shard executes that. So it seems a bit inconsistent.


Generated at Thu Feb 08 03:55:35 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.