Service Account per Environment Pattern
Parent: MongoDB Atlas Infrastructure as Code · Published reference · snapshot 2026-10-23 · skill mongodb-cohort-63131ca29156
↓ Facts as markdownall context files
Source-anchored research for Service Account per Environment Pattern. 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.
How-to and procedures
- Avoid one shared account accumulating permissions for unrelated applications. Google's guidance identifies permission growth, ambiguous retirement, and weakened attribution as consequences of account sharing; MongoDB separately requires least-privilege access for a service account's purpose. (high confidence) [source]
Problems, failure modes and limitations
- Recommended design synthesis: create different Atlas administration service accounts for development, staging, and production, then limit each account to its intended environment and purpose. Atlas project isolation and Google single-purpose service-account guidance support this design; environment labels alone do not enforce it. (medium confidence) [source]
Comparisons and alternatives
- Treat one service account per environment as a starting point rather than a reason to share one identity among every workload in that environment. Single-purpose accounts avoid combining divergent permissions and allow account retirement to follow the associated application lifecycle. (medium confidence) [source]
- Use distinct automation identities for each application/environment pair rather than sharing production credentials with development. This is a design synthesis: MongoDB's Terraform guide recommends separate service accounts for environments or pipelines, Microsoft prohibits sharing service principals across environments in its landing-zone guidance, and Google recommends dedicated accounts per application. (high confidence) [source]
- The Terraform provider selects credential sources in this order: AWS Secrets Manager, provider attributes, then environment variables. It takes one complete source rather than merging sources. When wiring environment-specific accounts, check that a higher-priority shared secret does not override the intended environment credentials. (low confidence) (verified as of 2026-10-23) [source]
- For Administration API automation, MongoDB recommends OAuth 2.0 service accounts over legacy API keys. Environment separation can use the recommended service-account mechanism instead of preserving shared legacy keys merely for convenience. (high confidence) (verified as of 2026-10-14) [source]
Facts and statements
- An Atlas service account authenticates administration API requests, not Atlas UI sessions or direct reads and writes of cluster data. Database workloads need separate database authentication; an API identity able to manage database users must still be treated as sensitive. (high confidence) (verified as of 2026-10-14) [source]
- An Atlas service account belongs to exactly one organization but can access multiple projects. Consequently, creating separate identities does not isolate environments if their project memberships or effective permissions overlap; grant only the access needed for each purpose. (medium confidence) (verified as of 2026-10-14) [source]
- Pair identity separation with resource separation: MongoDB recommends separate projects for application/environment pairs, particularly production; Microsoft's guidance likewise pairs separate environment identities with separate security configurations and assignments. Distinct names alone do not establish isolation. (high confidence) [source]
- Atlas service accounts have a rotatable client secret used to create one-hour access tokens, and MongoDB's authentication guidance recommends rotating those secrets before expiry. The MongoDB Atlas Architecture Go SDK recommends storing production credentials in a secrets manager. For GCP Secret Manager, a runtime service account can receive `roles/secretmanager.secretAccessor` on each secret it needs; project-level grants provide access to every secret in that project. This is cross-cloud storage guidance, not an Atlas authorization feature. (medium confidence) [source]
- The Atlas CLI GitHub Action accepts MONGODB_ATLAS_CLIENT_ID and MONGODB_ATLAS_CLIENT_SECRET, and the Terraform provider exposes corresponding client_id and client_secret inputs. These tools can receive the credentials selected for each environment; configuration selection must match the intended identity. (medium confidence) (verified as of 2026-10-23) [source]
- The MongoDB Atlas Terraform provider documents separate service accounts for environments or CI/CD pipelines as a mitigation for token-endpoint rate limiting. It states that limits apply per IP-address/service-account-client combination and that each Terraform operation generates a token; this is operational guidance, not proof of stronger authorization. (low confidence) (verified as of 2026-10-23) [source]
- A user report dated April 28, 2026 in Elastic integrations issue 18676 describes MongoDB Atlas integration 1.2.0 with Agent 9.3.0 accepting API-key fields but lacking OAuth client-ID/client-secret inputs. This is evidence to check the deployed integration before switching credentials, not proof that every later release lacks support. (low confidence) (verified as of 2026-04-28) [source]
- In a first-person GCP engineering example, Nic Vannetti separates staging and production secret projects and gives each consuming runtime service account access to individual secrets. This illustrates how environment identity separation also requires secret-read permissions; it is cross-cloud design context, not an Atlas feature. (low confidence) [source]
- Separate environment accounts still require credential controls. MongoDB recommends rotating service-account secrets before expiry and applying IP access lists; Google recommends managing each service account with its associated application's lifecycle. Account separation does not replace these controls. (medium confidence) [source]
Children
- Environment-specific automation secret delivery (frontier)
- Per-pipeline service account token throttling (frontier)
- Service account credential rotation (frontier)
Frontier under this node: Environment-specific automation secret delivery, Per-pipeline service account token throttling, Service account credential rotation