MongoDB Atlas API keys are the public and private key pair stored in a CI variable or an application secret so something can call the Atlas Administration API. Organization keys and project keys are both long-lived. The private key is shown once and then lives wherever someone pasted it. IP access lists on the key reduce where it can be replayed. They do not make it expire. Rutagon replaces those keys with Atlas workload identity federation bound to an AWS IAM role the workload already has.
The caller is the same class of principal you already moved off static AWS keys: a CI role from GitLab OIDC to AWS, an ECS task role, or an EKS service account via IRSA. Atlas is configured to trust that role ARN for a specific organization or project role. After a read-only Admin API call succeeds as that role, we revoke the org key and the project key. The revocation is the deliverable. A working role next to a still-valid private key has not removed the credential.
What the key pair actually is
An Atlas organization API key and a project API key are programmatic credentials for the Admin API. They are not the database user's SCRAM password, and they are not the connection string in the application. Confusing them leads teams to rotate the wrong secret and leave the Admin API key in the pipeline.
The public key is an identifier. The private key is the secret. Together they satisfy the digest authentication scheme the Admin API has accepted for a long time. Copies accumulate: the pipeline context, a laptop of the person who created the project, a Terraform provider block, a shared password manager entry named "atlas-prod". Secrets Manager rotation versus elimination applies here if someone "solves" this by rotating the private key into Secrets Manager. Rotation keeps a long-lived secret. Workload identity removes it.
Service accounts that use an OAuth client id and client secret are a newer Atlas option and they are still a secret you must store. We do not stop the migration on that pattern unless you have a hard product constraint. The destination in this engagement is workload identity: the AWS role is the credential Atlas already knows how to accept.
MongoDB Atlas API keys replaced by a mapped role
Atlas workload identity federation for the Administration API lets you register AWS as an identity provider on the organization and authorize specific IAM role ARNs. Each authorization maps a role ARN to an Atlas organization role or a project role. The map is the privilege boundary. A role trusted for Organization Owner is standing control of every project. We map CI plan roles to a read role and map a separate apply role to the narrow project role that can change clusters.
The workload already calls STS for its own AWS identity. It then calls the Atlas Admin API as that identity. Atlas checks the role ARN against the authorization you stored. There is no public/private pair in the environment. The concrete test we require before revocation:
- The IAM role can be assumed by the pipeline or task and nowhere else you did not intend.
- An Admin API read that lists the target project succeeds with that role.
- The same read fails when performed with the old key after revocation, which we confirm by attempting it once and recording the denial.
We revoke organization keys and project keys that the inventory shows were used for this automation. Human keys used by an operator console session are a different decision, flagged for the access review, not silently deleted. Database user passwords are out of scope for this cutover and stay on their own inventory so nobody declares "Atlas is keyless" while SCRAM passwords remain.
AWS documents the IAM role the workload presents in IAM roles. The role's trust policy is your cloud's business: OIDC from CI, or the service that runs the task. Atlas holds the allow-list of role ARNs. Both sides have to be narrow or the federation recreates a wide key.
Inventory before anyone clicks revoke
We list every organization API key and every project API key, the roles each key holds, the access list, and the last time you can determine it was used. Keys with Organization Owner or Project Owner privileges go first in the risk order, not last. A read-only key left behind is still a secret, and it is a smaller one. Owner keys are how a leaked private key becomes a cluster change.
Terraform and other infrastructure tools are usually the principal that forced the key into CI. The provider configuration moves to workload identity in the same change that revokes the key. A provider block that still contains public_key and private_key will fail after revocation, which is what we want, as long as the identity path is merged first. We do not revoke on Friday and plan the provider change for the next sprint.
Cross-cloud identity federation into AWS is a related pattern when the workload's first identity is not already an AWS role. For an AWS-native pipeline, the Atlas map points at the AWS role you have. We do not introduce a second long-lived cloud key to satisfy Atlas.
Local developer access to the Admin API does not use the CI role. Operators get a human path with MFA, or a separate role they assume interactively with a subject that CI cannot mint. Sharing the automation role with a laptop undoes the separation.
What we file, and the tradeoff
The packet filed in the GRC you already run includes the role ARN, the Atlas role it maps to, the key ids revoked, and the successful role-based read plus the failed call with the old key. Key ids are identifiers. Private key material is never copied into the GRC.
The tradeoff is a dependency on both AWS STS and Atlas federation being healthy at deploy time. A federation outage blocks Admin API automation. It does not hand an attacker a private key that works until someone remembers to rotate it. We accept that dependency. Application runtime traffic to the database is unaffected by Admin API federation. The app still uses its database user. We say that so a cutover plan does not include an unnecessary application restart.
If a key cannot be revoked because an unknown consumer still uses it, it stays on an exception list with an owner and an end date. An exception without an owner is not an exception. It is the old key.
Frequently Asked Questions
Are Atlas API keys the same secret as the database password?
Organization and project API keys call the Administration API, while database users authenticate to the cluster. Replacing API keys does not rotate SCRAM passwords, and rotating a database user does not revoke an Admin API key. We inventory the two secrets separately.
Why not store the private key in Secrets Manager and rotate it?
Rotation keeps a long-lived secret and a retrieval path. Workload identity maps an IAM role ARN to an Atlas role so the pipeline presents AWS credentials it already assumes. After that call works, the private key is revoked rather than rotated.
What do you map the IAM role to inside Atlas?
To an organization role or a project role, chosen to match the job. Plan automation gets a read role. Apply automation gets a narrow project role. Organization Owner is not the default mapping for a CI role.
When is the old key revoked?
After the role-based Admin API read succeeds against the intended project. We then revoke the org and project keys used by that automation and show the old key fails. Keys that humans still use remain only as named exceptions with an end date.
What gets stored for audit?
The role ARN, the Atlas role mapping, the revoked key ids, and the pass-then-fail test. Private key material stays out of the ticket. The packet is filed in the GRC you already run.
Talk to us about your credential elimination pilot. Reach Rutagon at rutagon.com/contact, 907-841-8407, or contact@rutagon.com.