MongoDB — prerequisites and accounts

What to create on your MongoDB deployment so DBSheriff can monitor it. Covers both deployment shapes this engine supports — self-managed (Community or Enterprise, any host) and MongoDB Atlas — since the two diverge sharply on RBAC and on which controls are reachable from a plain database connection at all. Every fact below was verified live: on-prem against a real mongo:8 Community Edition container, and on Atlas against a real, Terraform-provisioned M10 replica set — not written from MongoDB's docs alone. Amazon DocumentDB is supported in part (§6: running operations, not completed ones), and Azure Cosmos DB for the MongoDB API is not supported (§6).

The three scripts

On an installed host there is no scripts/ folder, so read every scripts/<name>.py below as sudo /opt/dbsheriff/current/deploy/onprem/stack.sh tool <name> ..., for example sudo /opt/dbsheriff/current/deploy/onprem/stack.sh tool setup_dbsheriff mongodb mongo1.acme.internal. The scripts/ form is for a source checkout. The details are under "How to start the scripts" in Before you install: creating DBSheriff's database users.

Pass an Atlas SRV hostname (e.g. cluster0.xxxxx.mongodb.net) instead of a plain host to target Atlas — pick atlas at the platform prompt either way. install_prereqs.py and setup_dbsheriff.py ask which database you're registering for monitoring (profiling is per-database, identical question and identical command on both deployment shapes); create_reset_dbuser.py asks no such question and does not enable profiling — it grants read on every non-system database and leaves profiling as a manual follow-up. All three connect only as a database user — never a cloud credential, and never the Atlas Admin API Service Account below, which has no host/port/username/password shape at all. Add --dry-run to preview without changing anything, or --check for a read-only status report — see pre installation database users for the full flag reference shared by every engine.

On Atlas, account creation itself isn't automatable by any of these scripts — confirmed live, not a guess. createUser/updateUser return a clean Unauthorized over a direct database connection for every account type, even one holding Atlas's own atlasAdmin role — Atlas routes all user management through its own control plane, full stop. Running create_reset_dbuser.py/setup_dbsheriff.py against an Atlas cluster still does something useful: it reports this clearly per account instead of failing with a raw driver error, and it still handles the profiling prerequisite. Create the four accounts themselves via the Atlas UI (Database Access) or Terraform instead — §1 below has the exact roles each one needs either way.

Atlas now has functional parity with self-managed, except for the PS01, PS05, PS06, PS11 and PS13 posture checks (NOT_CHECKED on Atlas, §3), the A04 connection-quality check and role_table_grants (§5) — kill, lock, cluster-wide identity listing, and a real audit-logging posture check all work on both deployment shapes, live-verified end to end. Getting there needs one extra credential Atlas requires that self-managed doesn't: an Atlas Admin API Service Account (§1), since several MongoDB operations DBSheriff needs are structurally blocked from a database connection on Atlas, full stop, regardless of role — not a missing grant, a platform design choice. Read §5 for the handful of things that stay genuinely different between the two shapes even with that credential in place (mainly around encryption-at-rest and TLS posture checks, and the shape of the audit trail).

0. What must be enabled on the server

The floor. A clusterMonitor+read monitor account gives you live + completed statement monitoring and space/availability metrics on both deployment shapes, once profiling is on. Kill, lock, identities, and PS09 all work on both shapes too — self-managed through database roles, Atlas through a combination of Atlas-specific roles and the Admin API Service Account. See §5 for what's still genuinely different in the details.

1. The accounts

// self-managed — run against the admin database
db.createRole({
  role: "dbsheriff_view_users",
  privileges: [
    { resource: { cluster: true }, actions: ["viewUser"] },
    // viewRole (2026-09-20): needed for governance.role_table_grants'
    // rolesInfo call (custom-role discovery for DB Role auto-tagging) —
    // not yet granted on existing installs, see §2.
    { resource: { cluster: true }, actions: ["viewRole"] }
  ],
  roles: []
});

// LIVE-281: the one action the profiler health check needs, on the monitored database only (repeat the privilege per database you
// register; never the cluster, never admin, config or local)
db.createRole({
  role: "dbsheriff_profiler",
  privileges: [
    { resource: { db: "<your database>", collection: "" }, actions: ["enableProfiler"] }
  ],
  roles: []
});

db.createUser({
  user: "mongo_monitor", pwd: "<pick a strong password>",
  roles: [
    { role: "clusterMonitor", db: "admin" },
    { role: "read", db: "<your database>" },
    { role: "dbsheriff_view_users", db: "admin" },
    { role: "dbsheriff_profiler", db: "admin" }
  ]
});
db.createUser({
  user: "mongo_kill_user", pwd: "<pick a strong password>",
  roles: [{ role: "hostManager", db: "admin" }]
});
db.createUser({
  user: "mongo_lock_user", pwd: "<pick a strong password>",
  roles: [{ role: "userAdminAnyDatabase", db: "admin" }]
});
db.createUser({
  user: "mongo_classify", pwd: "<pick a strong password>",
  roles: [{ role: "read", db: "<your database>" }]
});

// enable profiling on every database you register (repeat per database)
use <your database>
db.setProfilingLevel(1, { slowms: 0 });

// recommended: make the profiler's ring large enough to survive a burst (64 to 256 MB; the default is 1 MB).
// It drops the existing profile documents, so do it once, before the first monitoring poll.
db.setProfilingLevel(0);
db.system.profile.drop();
db.createCollection("system.profile", { capped: true, size: 134217728 });   // 128 MB
db.setProfilingLevel(1, { slowms: 0 });

// Atlas database accounts — via the Atlas UI (Database Access) or
// Terraform (mongodbatlas_database_user, provider >= 2.0.0).
// monitor:  clusterMonitor@admin + read@<db> + the custom role dbsheriff_profiler (below)
// kill:     killOpSession@admin   (NOT hostManager — Atlas rejects it, §2)
// lock:     read@admin — a formality only, see the Service Account below
// classify: read@<db>

// LIVE-281: a custom role (Atlas UI: Database Access, Custom Roles; Terraform: mongodbatlas_custom_db_role; Admin API:
// POST /groups/{groupId}/customDBRoles/roles) with the one action the profiler health check needs, on the monitored database only,
// then give it to mongo_monitor next to its two built-in roles (Terraform: roles { role_name = "dbsheriff_profiler", database_name = "admin" }):
//   { "roleName": "dbsheriff_profiler",
//     "actions": [ { "action": "ENABLE_PROFILER", "resources": [ { "db": "<your database>", "collection": "" } ] } ] }

// profiling is still a plain database command on Atlas, not an Atlas UI setting:
use <your database>
db.setProfilingLevel(1, { slowms: 0 });

// recommended on Atlas too, and more so than on a self-managed server: the Atlas profiler ring is 1 MB, and DBSheriff's own
// polling writes into it, so the default ring holds about four minutes of operations (measured on an M10). A database user with the
// atlasAdmin role may recreate it (live-verified: profiling off, drop, create, profiling on all accepted); do it once, before the
// first monitoring poll, because it drops the existing profile documents. install_prereqs.py does this when run as such a user.
db.setProfilingLevel(0);
db.system.profile.drop();
db.createCollection("system.profile", { capped: true, size: 134217728 });   // 128 MB
db.setProfilingLevel(1, { slowms: 0 });

The Atlas Admin API Service Account is not a database user at all — it's an OAuth2 client-credentials principal, created in the Atlas UI under Organization → Access Manager → Applications → Service Accounts → Create. Grant it access to this specific project with these roles:

Also required: an API Access List entry on the Service Account itself (separate from the cluster's own network access list, and — unlike the cluster's list — Atlas rejects 0.0.0.0/0 here) for whichever IP address DBSheriff's own containers/scripts actually call the Admin API from.

Store the resulting Client ID + Client Secret, together with the project's group ID, as a JSON blob {"client_id", "client_secret", "group_id"} in the service_account_key field of that server's registration, sent through the Monitored Servers API (POST /api/monitored-servers). The Admin Console form has no field for it on a MongoDB server, and the value is kept encrypted in governance.monitored_servers.service_account_key_encrypted (the registry's monitor-tier credential slot — unused by MongoDB's own database connection, same "generic credential blob, engine decides the shape" convention BigQuery/Databricks/Snowflake already use for their own API credentials), so do not write the JSON into that column with SQL: DBSheriff cannot decrypt it, logs bad service_account_key and treats the key as absent.

2. Grant reference (why each one is needed — and what Atlas rejects)

• clusterMonitor + read@\<db> — the monitor account's whole job: currentOp (live queries), serverStatus (connections/availability), dbStats (space), and reading system.profile (completed queries, once profiling is on). Identical on both deployment shapes. The profiler health check adds the dbsheriff_profiler role below.
• dbsheriff_profiler (LIVE-281) — a minimal custom role that gives the monitor the enableProfiler action on the monitored database and nothing else. The producer's profiler health check runs profile -1 on the registered database (to see whether the profiler is off or its slowms has drifted) and, when it is, profile 1 with slowms: 0 again; MongoDB asks for enableProfiler on that database for both. No built-in role carries only that action (dbAdmin adds index and collection management), so it is a custom role, scoped as narrowly as MongoDB allows: one privilege per database, resource { db: <database>, collection: "" }, never the cluster and never admin, config or local. What it lets the account do: the monitor can change the profiling level of those databases (including switching the profiler off, which is how the statement record of that database would be silenced), so keep mongo_monitor's password as protected as the other DBSheriff accounts. DBSheriff itself raises the R96 capture-gap alert when it finds the profiler off. On self-managed servers create_reset_dbuser.py and setup_dbsheriff.py make the role as part of the monitor step (they update it when it exists, so a database made since is covered by running the step again). On Atlas the account is created by hand, so create the custom role there too: the Admin API action name is ENABLE_PROFILER on the resource { "db": "<your database>", "collection": "" }, then add the role to mongo_monitor. Amazon DocumentDB has no profiler (setProfilingLevel answers code 303, §6), so the role is not made there and the monitor is created without it. An account created before this role existed does not have the action: the health check then skips with one INFO line (it asks again after an hour) and a switched-off profiler is seen only as an empty system.profile. Run the accounts step again for the monitor (scripts/create_reset_dbuser.py mongodb <host>, choose reset, which also sets a new password for the account, or setup_dbsheriff.py; on Atlas add the role by hand), or, without a new password, create the role as in §1 and run db.grantRolesToUser("mongo_monitor", [{ role: "dbsheriff_profiler", db: "admin" }]). After an Atlas restart that has already switched the profiler off, run install_prereqs.py again.
• dbsheriff_view_users (self-managed only) — a minimal custom role, not a built-in one. usersInfo({forAllDBs: true}) needs the viewUser cluster action, which no built-in role grants on its own without also granting far more (userAdminAnyDatabase or broader). Also needs viewRole (2026-09-20) for the governance collector's rolesInfo({showPrivileges: true}) call, which discovers which CUSTOM roles grant access to a collection already approved as sensitive (for DB Role auto-discovery, governance.role_table_grants) — without it, that one collection step logs a warning and collects 0 roles rather than failing the hourly cycle. This custom role has no Atlas equivalent at all — confirmed live: Atlas custom database roles simply have no viewUser-equivalent action in their action list. There is no database-connection path to cluster-wide identity listing on Atlas — that's exactly what the Atlas Admin API Service Account's GET /groups/{groupId}/databaseUsers is for instead.
• Kill is a genuine two-role split, confirmed live, and the two roles are NOT interchangeable across deployment shapes. killOp needs hostManager on self-managed; Atlas rejects hostManager outright (ATLAS_INVALID_ROLE) and requires its own purpose-built killOpSession role instead, which bundles killOp together with currentOp's inprog action (self-managed's hostManager does not include inprog — this split is exactly what broke MongoDB kills entirely on self-managed for a while; DBSheriff now runs its currentOp verification through the monitor connection instead of the kill connection specifically because of this, see its MongoDB kill routine).
• Lock is where Atlas diverges most, and the reason isn't a missing role at all. Confirmed live: direct MongoDB connection commands for user management are structurally blocked on Atlas regardless of role — even a database account holding atlasAdmin (Atlas's real superuser-equivalent role) gets a clean Unauthorized attempting createUser/updateUser directly against the cluster. Atlas's own docs describe this as rolling back any user modification attempted outside its own control plane. So mongo_lock_user's database role is effectively a formality on Atlas — the actual lock/unlock mechanism goes entirely through the Atlas Admin API Service Account's PATCH /groups/{groupId}/databaseUsers/{db}/{username} (Project Database Access Admin role), independently live-verified: genuinely revokes real read access (confirmed via a blocked connection afterward, not just trusting the API's 200 response), then genuinely restores it the same way.
• Classification is a plain read@\<db> grant, same on both shapes — MongoDB has no schema/catalog layer to read column names from the way a relational engine does, so classification samples a bounded number of real documents per collection to infer field names. No broader grant is needed or helps.

3. What DBSheriff reads

Producer (producer-mongo-pool) — no setup beyond §1-2 for mongo_monitor

currentOp({active: true}) for live (currently-running) operations; system.profile (via the same monitor connection, read@\<db>) for completed ones, polled and watermarked the same way every other event-log-shaped engine (BigQuery/Snowflake/Databricks) works — not a cumulative-counter diff the way pg_stat_statements is. Completed queries of the same shape (queryHash) within one poll cycle are grouped into a single message with a real calls_delta count — this does feed R38 BURST_CALL_VOLUME (live-verified: a genuine burst triggered a real, server-side account lock via this exact path — see docs/engines-feature-matrix.md's MongoDB row).

Admin/DDL commands (create, drop, collMod, createIndexes, dropIndexes, renameCollection) are mapped to SQL-DDL-shaped strings (the producer's DDL command table) so the shared, keyword-based is_ddl classifier recognizes them without a MongoDB-specific branch — without this, PRIVILEGED-strict-DDL scoring never fires for MongoDB DDL at all.

Accounts that are never scored. The accounts DBSheriff itself logs in as are kept out of scoring, the statement audit and the coverage figures: they are read from the user of each connection URI you registered (monitor, kill, lock, posture, classification), plus the default names of this guide (mongo_monitor, mongo_kill_user, mongo_lock_user, mongo_classify), which are also exempt from the honeytoken rule (R64). On an Atlas cluster (a *.mongodb.net host in the monitor URI) the principals Atlas runs itself are kept out too: __system (replication, about 25 profile entries a minute), mms-monitoring-agent ($collStats on every collection every ten minutes) and mms-automation. Your own exclusion list (Admin Console) is added on top of both.

Collections named inside a command. A statement names every collection it touches, not only the one it ran against: the from of a $lookup or $graphLookup, the collection of a $unionWith, the target of $merge and $out, the output of mapReduce, and the collection of distinct, count and findAndModify. A read of a sensitive collection (or of the honeytoken) through one of them is scored as a read of that collection.

Governance collector (mongodb-governance-collector)

Every 30s: system.profile → governance.mongodb_statement_audit (this is MongoDB's statement-audit trail — self-managed Community has no native audit log at all, confirmed structurally absent, not just unconfigured: buildInfo().modules is an empty array and every audit-related getParameter call fails outright).

Every hour: identities, config snapshot, protection, access log, coverage, posture (the posture scan, §4 below). Identities use usersInfo on self-managed (needs dbsheriff_view_users) and the Atlas Admin API's GET /databaseUsers on Atlas (needs the Service Account, §1) — both confirmed live returning real, correctly-normalized account data. Each hourly step runs independently; one step failing no longer blocks the others, including the posture scan itself.

Posture scan — 8 codes (PS01, PS05, PS06, PS07, PS08, PS09, PS11, PS13)

On Atlas, PS06 and PS11 are NOT_CHECKED — both are platform-structural (the platform refuses non-TLS connections and encrypts every cluster at rest; no Admin API endpoint changes that), not a missing credential — and PS01 and PS05 are NOT_CHECKED too. PS07, PS08 and PS09 (with Project Owner) are as trustworthy on Atlas as on self-managed; PS13 is NOT_CHECKED as above.

Classification scan (mongo_classify, §1)

Samples up to MONGO_SCAN_SAMPLE_SIZE (default 100) documents per collection per database, extracting field names one level deep into nested documents (e.g. address.street) — never field values unless value-sampling is separately enabled. system.* collections (in practice, just system.profile once profiling is on) are excluded from scanning.

4. Verification

// run as mongo_monitor
db.adminCommand({ currentOp: true, active: true });   // should succeed, empty or real ops
db.<yourCollection>.find({}).limit(1);                // read access confirmed

Expected producer log line on first successful poll: [<server>][poll] nothing new (or a captured statement if one was running) — an Unauthorized error here means the monitor account's grants from §1 aren't in place yet, or profiling was never enabled (db.getProfilingStatus() should show {"was": 1, "slowms": 0}).

// run as mongo_monitor, on the monitored database: the profiler health check's own read (needs the enableProfiler action)
db.getSiblingDB("<your database>").runCommand({ profile: -1 });   // { was: 1, slowms: 0, ok: 1 }
// "not authorized ... profile" means the dbsheriff_profiler role (§1) is not on this account yet: run the accounts step again

// self-managed only — confirms dbsheriff_view_users actually works
// (run as mongo_monitor)
db.adminCommand({ usersInfo: { forAllDBs: true } });

# Atlas Admin API Service Account — confirms the credential and roles
# actually work before wiring it into the registry. Replace {client_id}/
# {client_secret}/{group_id} with the real values.
b64=$(echo -n "{client_id}:{client_secret}" | base64 -w0)
token=$(curl -s --request POST --url https://cloud.mongodb.com/api/oauth/token \
  --header "authorization: Basic $b64" \
  --header 'content-type: application/x-www-form-urlencoded' \
  --data 'grant_type=client_credentials' | python3 -c "import sys,json; print(json.load(sys.stdin)['access_token'])")
curl -s --request GET \
  --url "https://cloud.mongodb.com/api/atlas/v2/groups/{group_id}/databaseUsers" \
  --header "Authorization: Bearer $token" \
  --header 'Accept: application/vnd.atlas.2023-01-01+json'

A successful response lists every real database user on the project — if this fails with 403, check the Service Account's API Access List entry (§1) first; if it fails with 401, check its project roles.

# classification catalog access (run inside the admin container; `<env>` is the environment name you gave the installer, `prod` by default)
sudo docker exec -it dbsheriff-<env>-admin python scripts/classify_scan.py --engines mongodb --server <name>

Expect PENDING candidates for real field names matching DBSheriff's PII name rules, and — once profiling is on and some traffic has run — real statement rows in governance.mongodb_statement_audit within 30 seconds.

5. Known limitations

• The Atlas profiler ring is small, and the 10-minute query-performance scan reads it. The default ring is 1 MB; with DBSheriff polling it, it holds about four minutes of operations, so a scan that looks back twenty minutes sees only the newest part, and its findings cover that shorter span. Enlarge the ring as described in §0: it is the only fix. The continuous capture (the producer, every second) is not affected by the scan's cadence and reports a capture gap (R96) when the ring wraps between two of its polls.
• Atlas authentication review is empty. DBSheriff collects no database logins on any MongoDB target, so governance.mongodb_auth_events stays empty, a failed-login burst is not detected, and an identity's last login is not known. Atlas's activity feed (GET /groups/{groupId}/events) is project administration, not logins, and is not read. The only login trail Atlas offers is its database audit log (Atlas Database Auditing, posture code PS09); DBSheriff does not read it in this release.
• On Atlas, the connection-quality check (A04) is not evaluated: the connection count includes the connections Atlas's own monitoring, automation and replication hold, so the active and idle split says nothing about your applications (it read 84.6 percent idle, CRITICAL, on a healthy cluster). DBSheriff does not send the split for an Atlas server; the saturation check (A01) still counts the connections.

• role_table_grants is not collected on Atlas: the monitor account cannot read the privileges of custom roles there, and the dbsheriff_view_users role that would allow it on a self-managed server cannot be created on Atlas.

• PS06 and PS11 are reported as not checked on Atlas, with no fix needed and none possible via any credential. Both are platform-structural: PS06 would count Atlas's own internal infrastructure connections as if they were client traffic (live-proved no real client can bypass Atlas's enforced TLS at all); PS11 would check a self-managed encryption flag Atlas never sets, even though Atlas actually encrypts everything at rest by default. The reason is stored with each result and shown in the evidence pack.

• Atlas's activity/events feed (GET /groups/{groupId}/events) is administrative activity, not a per-connection auth trail — and DBSheriff does not collect it in this release. The administrative events DBSheriff records on MongoDB come from comparing the hourly user and role snapshots (a user created or dropped, a role granted or revoked), so a change such as network access is not recorded. Don't expect DBSheriff's admin-events data to answer "who connected and when" the way a true auth trail would.
• Self-managed Community Edition has no native audit log at all — structurally absent, not just unconfigured. governance. mongodb_statement_audit (sourced from system.profile) is the real substitute; it captures every operation when profiling is set to {slowms: 0}, not just slow ones.
• Atlas lock/unlock is not instantaneous the way self-managed's direct database command is. The Admin API's PATCH call returns success immediately, but the actual role change takes real time to reach the cluster nodes — Atlas's own rolling-update mechanism. Measured on a live M10 cluster: a new connection was refused about 35 seconds after the lock (up to about a minute and a half), and access was back about 85 seconds after the restore. Until then the locked account can still connect and run. The lock's audit row says so in its own detail (Atlas accepted the change and applies it afterwards), and Unlock tells the approver that access returns after about 85 seconds, so the audit trail no longer reads as "locked" at the moment the request was made. Use the kill for an operation that is still running.
• The delay-hold pattern for your own testing needs $limit: 1 first on a multi-document collection: db.<coll>.aggregate([{$limit:1},{$addFields:{slow:{$function:{...}}}}]) — without it, $addFields+$function runs once per document, not once total (live-verified: a nominal 6-second delay actually ran 155+ seconds against a 3000-document collection without the $limit: 1).
• R38 burst detection works even across varied query shapes, not just repeated identical ones — worth noting since MongoDB's own calls_delta (grouped by queryHash, per-poll-cycle) only counts same-shape repeats. the enrichment step's per-identity aggregate (user_calls_rate_1m/5s/poll) sums calls across every query template for that user in the same window, engine-agnostic, so a burst spread across rotating query texts still counts as one burst.

6. Amazon DocumentDB (supported in part) and Azure Cosmos DB for the MongoDB API (not supported)

Both speak the MongoDB protocol and are not MongoDB. Everything below was measured on a live Amazon DocumentDB 5.0 cluster (TLS on, one db.t3.medium instance) in October 2026.

Amazon DocumentDB: what DBSheriff does there

The accounts on DocumentDB. Create them as the cluster's master user, in the admin database. They are the self-managed accounts of §1 with one difference, the dbsheriff_view_users role: DocumentDB refuses the viewRole action (Cannot grant privileges for the viewRole action on the cluster resource.), so the guide's role cannot be created there, and without it mongo_monitor cannot be created either (No role named dbsheriff_view_users@admin). Give the role viewUser alone:

// Amazon DocumentDB — run against the admin database as the master user
db.createRole({
  role: "dbsheriff_view_users",
  privileges: [ { resource: { cluster: true }, actions: ["viewUser"] } ],   // no viewRole: DocumentDB refuses it
  roles: []
});
db.createUser({ user: "mongo_monitor", pwd: "<pick a strong password>",
  roles: [ { role: "clusterMonitor", db: "admin" }, { role: "read", db: "<your database>" },
           { role: "dbsheriff_view_users", db: "admin" } ] });   // no dbsheriff_profiler: DocumentDB has no profiler, nothing for enableProfiler to act on
db.createUser({ user: "mongo_kill_user", pwd: "<pick a strong password>", roles: [ { role: "hostManager", db: "admin" } ] });
db.createUser({ user: "mongo_lock_user", pwd: "<pick a strong password>", roles: [ { role: "userAdminAnyDatabase", db: "admin" } ] });
db.createUser({ user: "mongo_classify",  pwd: "<pick a strong password>", roles: [ { role: "read", db: "<your database>" } ] });
// do NOT run the profiling statements of §1 (setProfilingLevel, the capped system.profile): DocumentDB refuses them with code 303.
// install_prereqs.py / setup_dbsheriff.py report that error for the profiling prerequisite on a DocumentDB host: skip it.

scripts/create_reset_dbuser.py mongodb <cluster endpoint> with view_users selected creates the role with viewUser only when the host is a *.docdb.amazonaws.com cluster, and also when DocumentDB answers the guide's role with the viewRole refusal above.

The running-operations grant. $currentOp on its own is allowed to every account, but DocumentDB authorises a pipeline with a second stage after it (DBSheriff's running-time $match) against the admin database, so the monitor above gets Authorization failure (code 13) on that pipeline. DBSheriff handles it: on that answer it runs $currentOp alone, filters by running time itself, remembers the choice for the server (so the pool does not fail once a second) and writes one WARNING to the producer log naming the grant that makes the server do the filtering again. Nothing has to be granted for monitoring to work; if you prefer the server to filter, give mongo_monitor the read role on admin (or readAnyDatabase) in addition. With the fallback each poll reads every active operation of the node it is connected to.

The CA bundle. DocumentDB's certificate is signed by the Amazon RDS CA. Download the global bundle, https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem, and register the connection string with the bundle's path inside the DBSheriff containers:

mongodb://mongo_monitor:<url-encoded password>@<cluster endpoint>.docdb.amazonaws.com:27017/?authSource=admin&tls=true&tlsCAFile=/certs/mongodb-ca.pem&replicaSet=rs0&retryWrites=false

Every DBSheriff service that holds target credentials (the producer pool, the governance collector, the kill and lock paths, the classification and posture scans) opens the connection, so the file must be mounted into all of them. The compose files mount one bundle per engine at /certs/<engine>-ca.pem from the host file named by <ENGINE>_SSL_CA_HOST_PATH. For MongoDB set MONGODB_SSL_CA_HOST_PATH in the stack's .env to the bundle on the host (for Amazon DocumentDB the Amazon RDS global bundle, global-bundle.pem, or a self-managed server's own CA) and write tlsCAFile=/certs/mongodb-ca.pem in the connection string, as above; then docker compose up -d. MongoDB has the mount and no MONGODB_SSL_CA variable: the CA travels in the connection string, so there is nothing for a variable to name, and a server set to verify is not refused by DBSheriff for lack of one: the driver reports the certificate failure. (A deployment made before this release can name the path of another engine's mount that holds the same bundle, for example tlsCAFile=/certs/mysql-ca.pem.)

The mark in the Monitored Servers list. A server on DocumentDB shows completed capture: off beside its host, with the sentence above as the tooltip. DBSheriff knows the platform from the host name (a name ending .docdb.amazonaws.com): at once when the server was registered through the API with that host, and for a server registered by its connection string alone (the console form has no Host field for MongoDB) within about an hour, when the governance collector next reads the string and records the platform.

Azure Cosmos DB for the MongoDB API is not supported. Cosmos DB rejects the $currentOp aggregation DBSheriff reads running operations with (Expected type string but found int), and has no killOp, no profiler and no user commands, so a registered server could only fail every second. The Admin Console refuses a registration whose Host or connection string is a *.mongo.cosmos.azure.com (or its sovereign-cloud forms .us, .cn, .de) or *.documents.azure.com host (HTTP 422, with a one-sentence explanation); setup_dbsheriff.py, create_reset_dbuser.py and install_prereqs.py refuse such a host with the same sentence before they connect; and a producer pool leaves such a server out if it was registered before. The vCore service (*.mongocluster.cosmos.azure.com) was not part of the probe that found these commands refused, so it is not refused, and it is not a tested platform either. Use a self-managed MongoDB, MongoDB Atlas or Amazon DocumentDB server.

Connecting to the target securely

setup_dbsheriff.py, create_reset_dbuser.py and install_prereqs.py connect as your administrator (onboard_target.py does not handle MongoDB: it refuses the engine before it connects), and the administrator password and every new account's password cross that connection, so they verify the server's certificate by default (--ssl-mode verify-full; --ca-file <bundle> names the CA, for self-managed MongoDB tlsCAFile; Atlas is always mongodb+srv over verified TLS). A refused certificate stops the run and the message names the flag; --ssl-mode require encrypts without verifying (an explicit opt-down that prints a warning) and --ssl-mode disable --allow-plaintext sends everything in clear text (a trusted private link only). A generated password is never printed: it is stored in the registry (encrypted), or written to a new mode-600 file (--credentials-file) whose path is shown. Account names must match [A-Za-z][A-Za-z0-9_]*, and every database, schema or warehouse name the scripts discover is quoted as an identifier before it goes into a statement.