MongoDB Atlas

Overview
How to connect
Automated checks
Useful links

DSALTA connects to MongoDB Atlas using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts and Inventory pages.

Read-only access. DSALTA never modifies, creates, or deletes resources in your MongoDB Atlas environment.

DSALTA collects this integration’s data when you connect it — you can refresh it at any time with Sync from integrations on the Integrations page. The compliance checks below re-run once a day at 02:00 America/New_York.

What DSALTA reads

DSALTA reads the MongoDB Atlas user roster — names, emails and organization roles, which appears on your Access page; and your Atlas cluster deployments, which appear on your Inventory page. DSALTA calls the organization-users endpoint pinned to Atlas Admin API version 2023-11-15. Every member is listed as Active, and the Created date on each row is the time of the DSALTA sync.It calls these MongoDB Atlas endpoints:

/api/oauth/token
/orgs
/orgs/{orgId}/users
/groups
/groups/{groupId}/clusters

Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your MongoDB Atlas environment.

Troubleshooting

Integration shows Disconnected

There is no Reconnect button. Open Integrations → Connected, click Manage on the MongoDB Atlas card, and check the Status tab — it shows either Connected and working properly or Connection issues detected. To restore a broken connection you must Disconnect and connect again, which permanently deletes the data and tests collected from MongoDB Atlas. This usually happens when API tokens expire.

Data is not syncing

Verify the connected account still holds the permissions listed under Before you begin. Then open Integrations in the DSALTA sidebar, stay on the Connected tab, and click Sync from integrations at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.

Create a MongoDB Atlas Service Account and paste its Client ID and Secret to connect.Before you begin

Atlas Organization access to create a Service Account
Organization Owner in the Atlas organization — MongoDB requires that role to create or manage an organization service account, so an Organization Read Only or Project Owner user cannot complete this flow.

You will need:

Field	Where to find it	Example
Service Account Client ID	Atlas → sidebar Identity & Access → Applications → Service Accounts → Add new → Service Account, with the Organization Read Only role. You must be an Organization Owner to create one. · Open	`mdb_sa_id_…`
Service Account Client Secret	Shown only once when you create the Service Account — copy it immediately.	`mdb_sa_sk_…`

Start in DSALTA

Open Integrations in the DSALTA sidebar, find MongoDB, and click Connect to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.

Integrating MongoDB with DSALTA means

DSALTA will only be able to read your MongoDB Atlas organization users (access reviews) and your Atlas clusters (inventory) for security compliance.DSALTA uses read-only access and never modifies your Atlas data, clusters, or settings.Scope of the Inventory half: Atlas cluster deployments only, one row per cluster with the MongoDB version, state, backup on/off and encrypted / not encrypted, and the project name in the Account column. Flex clusters and serverless instances do not appear — MongoDB serves those from separate endpoints (List Flex Clusters / List Serverless Instances) that DSALTA does not call, and its own note on the clusters endpoint says to “use the List Flex Clusters endpoint for Flex clusters instead”.

Create a Service Account

In MongoDB Atlas, follow these steps:

In the Atlas sidebar, under Identity & Access, open Applications → Service Accounts.
Click Create Service Account and give it a name (for example DSALTA).
Set the role to Organization Read Only — enough to read users and clusters.
Choose a secret expiration, then click Create.
Copy the Client ID and Client Secret — the secret is shown only once.

Current console route: pick the organization from the Organizations menu, then in the sidebar under Identity & Access open Applications → Service Accounts and click Add new → Service Account. Pick the client-secret duration from the menu — Atlas allows anywhere from 8 hours to 365 days — and on the confirmation screen “Click Copy and save the client secret to a secure location. This is the only time you can view the full client secret.”

Choose the longest duration your policy allows and diary the expiry date. An expired secret surfaces the next time you click Sync from integrations, since connecting and that button are when DSALTA calls Atlas; until then your Access and Inventory pages keep showing the last synced roster and clusters. Restoring the connection starts with Disconnect — which permanently deletes the data and tests DSALTA collected from Atlas — then connect again with a new secret. Rotating early inside Atlas does not help on its own: generating a new secret shortens the old one’s life to 7 days, and DSALTA keeps presenting the old value until you reconnect with the new one.

If your organization restricts the Administration API by IP, the credentials will validate as “valid” and still fail in use — MongoDB: “You can generate a token from any IP address, but you can only use it to call the API if your IP address is on the access list.” Either leave this service account without an access-list entry or ask DSALTA for the egress addresses to allow before you connect.

Enter your credentials

Paste the Client ID and Client Secret you copied and click Connect.

DSALTA validates the credential when you click Connect. On success the integration moves to the Connected tab, and Manage → Status reads Connected and working properly. Checks begin reporting after the first sync.

If the connection is rejected. Invalid Client ID/Secret or insufficient permissions. Use a Service Account with the Organization Read Only role.The on-screen message is generic — see Connection error messages.

Each check below re-runs once a day, at 02:00 America/New_York, while this integration is connected. Click any check for step-by-step remediation guidance.

Check	Severity	What it verifies
User access to Critical System should be valid	Info	Checks that everyone with MongoDB Atlas access is an active employee on the People page.
Offboarded users should not have active access	High	Checks that offboarded employees no longer have active MongoDB Atlas access.

Topic	Link
Setup	MongoDB Atlas Service Accounts
Setup	Manage programmatic access to an Atlas organization
Setup	Rotate Atlas service account secrets
General	MongoDB website
DSALTA	Connection error messages

Getting Connected

Identity Providers

Cloud Infrastructure

Code Repositories

Security & Monitoring

Databases

SaaS & Productivity

What DSALTA reads

Troubleshooting

​What DSALTA reads

​Troubleshooting

What DSALTA reads

Troubleshooting