Security, Authentication, and Authorization
This domain tests identity and access separation in Atlas: who can manage the platform, who can read or write data, how each is authenticated, and how data is protected.
Core rules
- Atlas users are control-plane identities for the UI, CLI, and API. They can use password plus MFA, SAML SSO, or API keys. Organization roles and project roles are separate from database roles.
- Database users are data-plane identities scoped to a project. Atlas supports SCRAM-SHA-256 (preferred), SCRAM-SHA-1, X.509, AWS IAM, and LDAP.
- Assign built-in roles such as read, readWrite, clusterMonitor, or backup, or create custom roles with only the actions and resources required. Use the narrowest database scope.
- Encryption at rest is default; BYOK uses your cloud KMS key. Audit logging is available on dedicated clusters and should capture privileged actions.
- API keys come in organization and project scopes, have roles, and can be IP-restricted. Rotate them and never embed them in code.
Worked example
An orders service needs read/write on the orders database only. A BI team needs read-only on analytics. Operations needs monitoring but no data. Create three database users: ordersApp with readWrite on orders; biUser with read on analytics; opsMonitor with clusterMonitor. Authenticate with SCRAM-SHA-256, require TLS, and restrict source CIDRs. Do not reuse an Atlas user or grant atlasAdmin, because that broad role violates least privilege.
Traps
Confusing a project role with a database role; using an Organization Owner API key in CI; allowing 0.0.0.0/0; granting readWriteAnyDatabase for convenience; forgetting that deleting a KMS key blocks restores.