Skip to content

doc: Adds mongodbatlas_api_key_project_assignment documentation, examples and migration guide #3465

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 23 commits into
base: CLOUDP-215112
Choose a base branch
from

Conversation

oarbusi
Copy link
Collaborator

@oarbusi oarbusi commented Jul 3, 2025

Description

Adds mongodbatlas_api_key_project_assignment documentation, examples and migration guide.
Also removed the examples that were using the old patterns for API key assignment to projects to avoid customers from referencing those.
This corresponds to the documentation necessary for #3461

Link to any related issue(s): CLOUDP-215112

Type of change:

  • Bug fix (non-breaking change which fixes an issue). Please, add the "bug" label to the PR.
  • New feature (non-breaking change which adds functionality). Please, add the "enhancement" label to the PR. A migration guide must be created or updated if the new feature will go in a major version.
  • Breaking change (fix or feature that would cause existing functionality to not work as expected). Please, add the "breaking change" label to the PR. A migration guide must be created or updated.
  • This change requires a documentation update
  • Documentation fix/enhancement

Required Checklist:

  • I have signed the MongoDB CLA
  • I have read the contributing guides
  • I have checked that this change does not generate any credentials and that they are NOT accidentally logged anywhere.
  • I have added tests that prove my fix is effective or that my feature works per HashiCorp requirements
  • I have added any necessary documentation (if appropriate)
  • I have run make fmt and formatted my code
  • If changes include deprecations or removals I have added appropriate changelog entries.
  • If changes include removal or addition of 3rd party GitHub actions, I updated our internal document. Reach out to the APIx Integration slack channel to get access to the internal document.

Further comments

@oarbusi oarbusi marked this pull request as ready for review July 3, 2025 14:25
@oarbusi oarbusi requested review from a team as code owners July 3, 2025 14:25
Copy link
Contributor

github-actions bot commented Jul 3, 2025

APIx bot: a message has been sent to Docs Slack channel

### Best Practices Before Importing
- **Backup your Terraform state file** before making any changes.
- **Review your current usage** of `mongodbatlas_project_api_key` and plan the migration for all affected resources.
- **Test the migration in a non-production environment** if possible.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[nit] I would remove this

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think this can be a common section that can be referred in every migration doc, instead of "Review your current usage** of mongodbatlas_project_api_key" we can rephrase this to be more generic like "Review your current usage** of deprecate resource or something"

```
2. **Import the existing API key into the API key resource:**
```shell
terraform import mongodbatlas_api_key.example <ORG_ID>-<API_KEY_ID>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we also support / instead of - to be more consistent?

```shell
terraform import mongodbatlas_api_key_project_assignment.example <PROJECT_ID>/<API_KEY_ID>
```
4. **Remove the old resource from the Terraform state:**
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a use-case for import and removed block?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking the same

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, I have clarified that removed block can be used

A: Existing keys will continue to work, but we recommend following the migration guide to move to the new pattern.

**Q: What if I have many project assignments?**
A: You can use `for_each` or `count` with `mongodbatlas_api_key_project_assignment` to manage multiple assignments efficiently.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have any examples of this?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good point

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there's no need, for_each count are terraform features. I added links to the official documentation for this features


Lastly, in MongoDB Atlas, all PAKs are Organization API keys. Once created, a PAK is linked at the organization level with an 'Organization Member' role. However, these Organization API keys can also be assigned to one or more projects within the organization. When a PAK is assigned to a specific project, it essentially takes on the 'Project Owner' role for that particular project. This enables the key to perform operations at the project level, in addition to the organization level. The flexibility of PAKs provides a powerful mechanism for fine-grained access and control, once their functioning is clearly understood.
```hcl
resource "mongodbatlas_api_key" "test" {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure if we want duplicate main.tf content here

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it doesn't hurt to have it here IMO

}
```

## Migration using import
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remember the "Does this work for modules"? And I think this doesn't, right?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in any case we need an example specific for modules

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because the old resource corresponds to 2 resources, moved block is not possible and this wouldn't work for modules because import is needed. Will add a "Does this work for modules" section

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have added migration path for modules and example for modules in 0a856bd and b40d686
let me know what you think

@@ -1,16 +0,0 @@

# Create Programmatic API Key + Assign Programmatic API Key to Project
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question: shouldn't we still have these examples but just migrated to the new approach?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think having the old pattern examples will be confusing and can lead to customers referencing those even if we now recommend the new pattern. Removing them and only having a single (new example) is better

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

got it, but aren't we removing the examples on how to use mongodbatlas_access_list_api_key ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good point, I have added that back to the api_key example in 669bb50


While this is not our recommended approach, you can still continue to use the `mongodbatlas_project_api_key` resource. If you are creating a new configuration, use the `mongodbatlas_api_key_project_assignment` resource.

## Does this work for modules?
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the section, but I would remove it from here and put this text into "## Migration using Modules"

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense, done in dc0790b

oarbusi and others added 2 commits July 4, 2025 15:45
Co-authored-by: Leo Antoli <430982+lantoli@users.noreply.github.com>

## Main Changes Between Patterns

| Old Pattern (`mongodbatlas_project_api_key`) | New Pattern (`mongodbatlas_api_key` + `mongodbatlas_api_key_project_assignment`) |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: This table is hard to read when using https://registry.terraform.io/tools/doc-preview, might be worthing just putting as sub titles

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

changed in e0ba552

5. **Remove the old resource block from your configuration**
6. **Run `terraform plan` to review the changes.**
- Ensure that Terraform does not plan to delete or recreate your API keys or assignments.
- **Note:** After import, Terraform may show an in-place update for attributes like `org_id` on the `mongodbatlas_api_key` resource. This is expected and only updates the Terraform state to match your configuration; it does not change the actual resource in Atlas. You can safely apply this change.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just curious is this something we can fix in api_key import?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we could but not sure if it would be considered as a breaking change or not. To fix it we would need to change the behavior of the Read. If you see the import of the api_key resource, the encoded Id attribute is set, and then on the Read, more attributes are set but not org_id, so when the terraform apply after the import is done, a change is detected. e.g.

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols: ~ update in-place Terraform will perform the following actions: # module.api_key_assignment.mongodbatlas_api_key.this will be updated in-place ~ resource "mongodbatlas_api_key" "this" { ~ description = "Legacy module-managed API Key" -> "Module-managed API Key" id = "YXBpX2tleV9pZA==:Njg2N2E1ODg2YTdlOGQ0M2Q2ZTdlODFl-b3JnX2lk:NjBkZGY1NWMyN2E1YTIwOTU1YTcwN2Q3" + org_id = "60ddf55c27a5a20955a707d7" # (3 unchanged attributes hidden) } Plan: 0 to add, 1 to change, 0 to destroy. 

open to discuss if this change is worth doing now

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if org_id will be set every time in Read() then this would be a breaking change as it would result in non-empty plans right?

Comment on lines +124 to +125
terraform import 'module.<module_name>.mongodbatlas_api_key.<name>' <ORG_ID>-<API_KEY_ID>
terraform import 'module.<module_name>.mongodbatlas_api_key_project_assignment.<name>' <PROJECT_ID>/<API_KEY_ID>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some customers who have platform and app teams have very distinct responsibilities. App teams, who would be the ones having to run this comment, don't have access to import capabilities. I think this should be converted into adding the import block in the configuration rather than as a command. I believe that should work

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am also very worried that this is the only suggestion we can make. Imagine a very big customer with hundreds of app teams, each team is expected to do that if they want to migrate to our recommended approach. That's never going to happen.

is the project_assignment an idempotent type of resource? What I mean is: if mongodbatlas_api_key_project_assignment is being created in TF but that assignment already exists, will it fail? or simply succeed? if that's the case we could recommend a moved from project_api_key to api_key and then the mongodbatlas_api_key_project_assignment would be defined as "new" resources

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added explicit mention of import block throughout the doc in ec95e5f.

Copy link
Contributor

@davidhou17 davidhou17 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM % nits

@@ -0,0 +1,229 @@
---
page_title: "Migration Guide: Project API Key to API Key + Assignment"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
page_title: "Migration Guide: Project API Key to API Key + Assignment"
page_title: "Migration Guide: Project API Key to API Key + Project Assignment"
### Best Practices Before Importing
- **Backup your Terraform state file** before making any changes.
- **Review your current usage** of `mongodbatlas_project_api_key` and plan the migration for all affected resources.
- **Test the migration in a non-production environment** if possible.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think this can be a common section that can be referred in every migration doc, instead of "Review your current usage** of mongodbatlas_project_api_key" we can rephrase this to be more generic like "Review your current usage** of deprecate resource or something"

5. **Remove the old resource block from your configuration**
6. **Run `terraform plan` to review the changes.**
- Ensure that Terraform does not plan to delete or recreate your API keys or assignments.
- **Note:** After import, Terraform may show an in-place update for attributes like `org_id` on the `mongodbatlas_api_key` resource. This is expected and only updates the Terraform state to match your configuration; it does not change the actual resource in Atlas. You can safely apply this change.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if org_id will be set every time in Read() then this would be a breaking change as it would result in non-empty plans right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
7 participants