Atlas Identity Federation and Resource Policy Boundaries

Parent: MongoDB Atlas IAM and RBAC · Published reference · snapshot 2026-10-01 · skill mongodb-atlas-expert/references/mongodb-atlas-identity-policy-frontier-20261001.md

Also known as: Atlas Service Accounts OAuth 2.0, Atlas Workforce Identity Federation, Atlas Workload Identity Federation

↓ Facts as markdown all context files

Source-anchored research for Atlas Identity Federation and Resource Policy Boundaries. Run status: COMPLETED.

These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.

Structure and components

OWASP recommends deny-by-default authorization and testing authorization checks. Atlas resource policies narrow existing RBAC permissions; their allow-by-default guardrail layer does not replace the underlying grant decision. Test allowed and denied configuration changes together. (low confidence) [source]

How it works

Atlas resource policies are written in Cedar and only the `forbid` effect is allowed (no `permit`); conditions use `when` / `unless`. With no policies, users can do everything their role allows. (high confidence) [source]
Atlas Resource Policies do not retroactively repair existing resources. Monitor /orgs/{ORG-ID}/nonCompliantResources. Existing auto-scaling limits may continue scaling beyond a newly added policy even when manual scaling beyond its limits is denied; policy compliance is not a continuous remediation guarantee. (low confidence) [source]
When a new secret is created, the old secret's expiry is capped at 7 days (shortened if it was longer, kept if already sooner), giving a bounded overlap window for rotation. (low confidence) [source]
The Terraform provider (PR #4735, opened 2026-09-16, closed 2026-09-18) made secret_expires_after_hours optional on service account creation; omitting it sends withoutInitialSecret=true, documented as the recommended flow so an org-owned bootstrap secret does not live in Terraform state. (low confidence) (verified as of 2026-09-18) [source]
Workload Identity Federation authentication is supported by MongoDB drivers. The Atlas page states that mongosh and MongoDB Compass do not support this authentication mechanism. (medium confidence) [source]
Atlas configuration of a Workload Identity Provider needs Issuer URI (resolved via /.well-known/openid-configuration), Audience, Authorization Type (User ID or Group Membership), User Claim (default sub, do not change) and a Groups Claim (default groups) when using group membership. Setup requires Organization Owner access, then linking the IdP to organizations and adding federated database users. (high confidence) [source]

Problems, failure modes and limitations

Cedar's native model has both permit and forbid effects plus entities, scope and optional schema; Atlas exposes only the forbid subset, which is why Atlas policies cannot express allow-lists directly and use `unless` for allow-list-style constraints. (medium confidence) [source]
Atlas service accounts authenticate via the OAuth 2.0 client-credentials flow: Basic-auth client ID:secret with grant_type=client_credentials sent to POST https://cloud.mongodb.com/api/oauth/token returns a Bearer JWT with expires_in 3600 (1 hour). Tokens are reusable within that hour and are replaced by requesting a new one before expiry (the access token cannot be refreshed). (high confidence) [source]
Service accounts (like API keys) grant access to the Atlas Administration API only: they cannot log into the Atlas UI and give no access to cluster data. Each belongs to a single organization and can be given org-level or project-level roles. (high confidence) [source]
IP access lists apply to using a token, not to creating one: tokens can be minted from any IP but API calls with them are only accepted from listed IPs (403 access_denied on failure). Token requests are subject to API rate limits (429 with Retry-After). (low confidence) [source]

Comparisons and alternatives

Best practice: reuse a token for its hour rather than minting one per request, mint a replacement before expiry, and revoke tokens no longer needed via the Revoke Service Account Token endpoint. (medium confidence) [source]
RFC 6749 section 4.4 describes client-credentials clients acting on their own behalf, requires client authentication, and says a refresh token SHOULD NOT be included. Separately, Atlas documents replacing its access token by requesting a new token rather than refreshing the existing access token. (medium confidence) [source]
Microsoft documents that more than 200 group memberships can produce an overage reference instead of group IDs in a JWT. Scope the groups claim to relevant groups and inspect the emitted claims. The retrieved Atlas documentation does not establish that Atlas calls Microsoft Graph to resolve overage or that failure is silent. (medium confidence) (verified as of 2026-01-15) [source]

Facts and statements

Authorization is two-stage: Atlas RBAC first checks the user may perform the action, then contextual attributes (cloud provider, region, TLS version, etc.) go to the Cedar evaluator, which returns a binary decision. Policies therefore only narrow RBAC; they never widen it. (high confidence) [source]
Policies are organization-level by default and apply to all projects and clusters; specific projects can be excluded from a policy. Viewing needs Organization Read Only or Member; create/update/delete needs Organization Owner. (medium confidence) [source]
Policy actions are ResourcePolicy::Action values such as cluster.modify, project.ipAccessList.modify, project.maintenanceWindow.modify, project.vpcPeering.modify, project.privateEndpoint.modify, search.index.modify, search.deployment.modify, project.rerank.modify and project.aiModelAPI.modify; context attributes include context.cluster.cloudProviders, regions, minTLSVersion, diskSizeGB and context.project.ipAccessList. (medium confidence) (verified as of 2026-10-01) [source]
The MongoDB announcement dates public preview to 2025-02-10 and general availability to 2025-04-14. The current documentation describes dedicated-config-server, customer-managed-key and auditing constraints; their addition dates were not verified. (medium confidence) (verified as of 2026-10-01) [source]
Gotchas: replica sets count as shard count 1, so a minimum shard count >1 can mark all replica sets non-compliant; converting replica set to sharded needs `&& !context.cluster.isConvertingToSharded`; private-endpoint policies need individual IPs (no wildcards); TLS/cipher-suite policies need Terraform provider 1.33.0+. (low confidence) (verified as of 2026-10-01) [source]
Policies can be managed through the Atlas Admin API, Terraform (mongodbatlas_resource_policy), CloudFormation and the Atlas UI, so Cedar files can be versioned in Git and code-reviewed. (high confidence) [source]
MongoDB recommends service accounts over API keys for the Atlas Administration API and calls API keys (HTTP Digest, public/private key pair) a legacy method. Service accounts became generally available on 2025-04-02. (high confidence) (verified as of 2026-10-01) [source]
Service account secrets must be given an expiry of 8 hours to 365 days, the full value is viewable only once at creation, and Atlas raises an alert 'Service Account Secrets are about to expire'. Rotation: generate new secret, update the app, revoke the old one. (medium confidence) [source]
Managing a project-level service account that also has access to the organization or other projects (rotate/revoke its secrets) requires the Organization Owner role. (low confidence) [source]
OWASP recommends least-privilege access to secrets and supported or automated rotation. Apply this independent security guidance to Atlas client secrets; OWASP does not specify Atlas secret lifetimes or rotation overlap. (low confidence) [source]
Workforce Identity Federation requires Atlas dedicated clusters (M10+) running MongoDB 7.0.11 or later. (high confidence) (verified as of 2026-10-01) [source]
An organization supports at most two Workforce IdPs: one OIDC IdP for database access and one SAML IdP for Atlas UI access; each org maps to one IdP per purpose, and Organization Owner is needed to configure. (high confidence) (verified as of 2026-10-01) [source]
Supported flows are Authorization Code with PKCE (recommended) and Device Authorization (for browserless machines, mongosh --oidcFlows=device-auth); clients are mongosh 2.1.4+ and Compass 1.38+. Only JWT access tokens are accepted, not opaque tokens. (low confidence) (verified as of 2026-10-01) [source]
Authorization is either by group membership (groups claim, default 'groups') or by user ID (user claim, default 'sub'); on Entra ID groups arrive as Object IDs, and user claim can be upn or oid. (low confidence) [source]
Using '.*' as the groups-claim filter is discouraged: it pulls every group into the token and can push it past preAuthMaximumMessageSizeBytes (16 KiB default), causing auth failures; use a dedicated Atlas group naming prefix filter instead. (low confidence) [source]
Entra ID setup needs scope <client-id>/.default, requestedAccessTokenVersion=2 in the app manifest, and 'Allow public client flows' for device auth; refresh tokens need the offline_access scope. (low confidence) (verified as of 2026-10-01) [source]
JWKS revocation in Atlas is for compromised signing keys only, not routine rotation; update IdP keys first, then revoke, and clients must restart. (low confidence) [source]
Workforce (human, mongosh/Compass) and Workload (application, driver-only) OIDC are separate IdP configurations; an Entra Workforce provider does not cover application data connections. (medium confidence) [source]
Org mapping can assign a default org role to IdP-authenticated users (applies only if no role is mapped from their IdP group), restrict by approved domains, and requires prior domain mapping; mapping auto-creates an IdP certificate-expiry alert. (low confidence) [source]
Federated database users and groups can receive database roles, be temporary, and be restricted to selected clusters. Keep project/database authorization separate from organization-level IdP linkage; do not interpret org linkage as database access to every project. (low confidence) (verified as of 2026-10-01) [source]
Atlas WIF requires dedicated M10+ clusters running MongoDB 7.0.11 or later. (high confidence) (verified as of 2026-03-23) [source]
WIF was announced 2024-05-02 and became generally available 2024-06-05, initially with Java, C#, Node and Python drivers; current docs list Java 5.1+, .NET 2.25+, Go 1.17+, PyMongo 4.7+, Node 6.7+, Kotlin 5.1+, Rust 3.0+, Scala 5.1+. (medium confidence) (verified as of 2026-10-01) [source]
Atlas documents Azure identities using the identity or group Object ID and GCP service accounts using their Unique ID. Configure the matching claim and database principal; do not substitute a display name. (low confidence) [source]
Two client flows exist: built-in (driver fetches the token automatically on GCP Compute Engine/App Engine/Functions/Cloud Run/GKE/Cloud Build, Azure VMs/AKS, AWS EKS, and self-managed Kubernetes service accounts) and callback (application supplies a token callback, e.g. MSAL or client-credentials, for any OAuth 2.0 provider). (medium confidence) (verified as of 2026-10-01) [source]
The Atlas Architecture Center lists Workload Identity Federation, AWS IAM and X.509 as workload authentication choices. It also lists X.509 or SCRAM as development/test choices. (medium confidence) [source]
For signing-key compromise, Atlas provides JWKS revocation. Follow the Atlas and IdP revocation procedure; ordinary key rotation and emergency revocation are different operations. (low confidence) [source]
Google Cloud metadata servers can issue an ID token for an attached service account and an explicitly chosen target audience. This documents Google token acquisition only; Atlas compatibility and driver setup must be checked against MongoDB documentation. (low confidence) [source]
Microsoft advises obtaining managed-identity tokens with its identity libraries and treating tokens as credentials: do not expose them in logs or send them to unrelated services. This is provider-side security guidance, not a statement that any arbitrary Microsoft token is valid for Atlas. (low confidence) [source]

Children

← the whole tree · 3D view· how to read this page