Integrate with MongoDB Atlas

Follow this step-by-step guide to allow SlashID to monitor and protect your MongoDB Atlas organization. This integration tracks console users, teams, organization API keys, service accounts, projects, clusters, and database users — giving you unified visibility over who has access to your Atlas data infrastructure.

Before starting

Before starting, ensure you have:

• Organization Owner access in MongoDB Atlas (required to create a service account in Organization Settings).

Step 1: Create a service account

1. In the Atlas console, go to Organization Settings → Access Manager → Service Accounts.
2. Click Create Service Account.
3. Fill in:
   • Name: SlashID Identity Protection (or any name you prefer)
   • Description: optional
4. Assign the Organization Read Only role — all data SlashID reads is read-only, so no higher privilege is needed.
5. Click Create Service Account.

Step 2: Generate a client secret

1. On the service account detail page, scroll to Client Secrets and click Generate Secret.
2. Set an expiry (Atlas enforces a maximum of 365 days).
3. Copy the Client ID and the Client Secret — the secret is shown only once.

danger

Atlas client secrets have a limited lifetime (maximum 365 days). When the secret expires, syncs will fail with a 401 error. Rotate the secret in Atlas before expiry and update the Client Secret field in the SlashID Console.

Step 3: Find your Organization ID

1. Go to Organization Settings (the gear icon next to your organization name).
2. Copy the Organization ID listed under the organization name.

Step 4: Create your MongoDB Atlas ↔ SlashID integration

1. Go to the SlashID Console integrations page.
2. Click Add data source and select MongoDB Atlas.
3. Enter your connection details:

SlashID Console field	Description	Example
Name of the connection	Arbitrary name you give to this connection	Atlas Production
Organization ID	Your Atlas Organization ID, found in Organization Settings	5f4e1234abcd1234ef567890
Client ID	The Client ID of the service account you created in step 1–2	mdb_sa_id_...
Client Secret	The client secret generated in step 2	—
Authoritative status	Whether Atlas identities are the primary source of truth when reconciling identities across providers	Primary or Secondary

4. Click Connect to complete the integration.

Step 5: Enable database auditing for data-exfiltration detection (recommended)

The identity and access graph above syncs with only the Organization Read Only role. Threat detections that watch database activity — the data-exfiltration ("data read spike") and anomalous-access signals — additionally require MongoDB Atlas database auditing to be turned on. Without it, SlashID still shows your identities, access, and control-plane events, but produces no data-read detections.

Atlas database auditing is available on M10 and larger clusters (dedicated tiers). For each cluster you want covered:

1. In the Atlas UI, open your project and go to Security → Advanced → Database Auditing.

2. Toggle Audit Logs on.

3. Set an audit filter that captures authenticated read operations. A filter on the authCheck action for read commands is sufficient, for example:

   {
     "atype": "authCheck",
     "param.command": { "$in": ["find", "aggregate", "getMore", "count", "distinct", "listCollections"] }
   }

   A broader filter (e.g. auditing all authCheck events) also works — SlashID only consumes the read operations.

4. Grant the SlashID service account a project-level role that can download cluster logs — Project Data Access Read Only or Project Observability Viewer — for each project whose clusters you want monitored. (Organization Read Only alone cannot download cluster logs.)

tip

After connecting, the SlashID Console preflight includes a cluster audit log available check. If auditing is off or the log can't be downloaded, that check reports a warning telling you exactly what to enable — the connection still succeeds, but data-read detections stay dark until it passes.

danger

Enabling verbose auditing on very high-throughput clusters increases audit-log volume and can add I/O overhead. Scope the audit filter to read operations (as above) rather than auditing everything.

Verification

After the first sync completes, SlashID will show:

• Users — all console members of the Atlas organization, with their roles
• Teams — Atlas teams with their memberships and assigned project roles
• Organization API keys — including their roles and access-list entries (for hygiene visibility)
• Service accounts — the service accounts in your organization, with their roles and secret metadata (expiry dates; never the secret values)
• Projects — all Atlas projects in the organization
• Clusters — clusters within each accessible project
• Database users — users for each accessible project, across all authentication types (SCRAM, X.509, AWS IAM, OIDC, LDAP), with their database and collection role assignments

Once database auditing is enabled (Step 5) and the connection has polled at least once, SlashID also produces streaming detections:

• Data read spike / anomalous access — a database user reading an unusually large number of operations, or accessing namespaces it does not normally touch, within a short window (a data-exfiltration signal)
• Privilege escalation — control-plane events such as an organization owner role being granted, a database user created with atlasAdmin, an access-list entry opened to 0.0.0.0/0, or a new API key / service-account secret being created

note

Per-project data (clusters and database users) is fetched on a best-effort basis. Projects the service account cannot read are skipped without failing the overall sync — only the organization-level Organization Read Only role is required.

Troubleshooting

Error / symptom	Cause	Fix
401 Unauthorized during sync or preflight	The client secret has expired or is invalid	Generate a new client secret in Atlas (Organization Settings → Access Manager → Service Accounts) and update the SlashID Console
403 Forbidden	The service account is missing the Organization Read Only role	In Atlas, edit the service account and assign the Organization Read Only role
Database users or clusters missing for a project	The service account lacks access to that specific project	Expected — per-project data is soft-skipped; add the service account at the project level if coverage is needed
Service accounts not visible in Atlas UI	The service accounts feature may not be available on older Atlas organization tiers	Check your Atlas plan; service accounts are available on newer Atlas organizations
Preflight cluster audit log available check warns, or no data-read detections appear	Database auditing is off, the cluster is below M10, or the service account can't download cluster logs	Complete Step 5: enable auditing on M10+ clusters and grant the service account Project Data Access Read Only / Project Observability Viewer
Data-read detections appear for some clusters but not others	Auditing is enabled per-cluster; clusters without it are silently skipped	Enable Database Auditing on each cluster you want monitored