Assigning existing Organization API key to new/updated projects

[jmccarty3]

It looks like with the release of provider version 1.12.0 the ability to associate existing Organization keys with a project has been lost in the provider.

Looking at issues such as:

• fix: How do I create Organization API Key with Organization Billing Admin permission and Project Read Only for projects #1369
• How do I create Organization API Key with Organization Billing Admin permission and Project Read Only for projects #1278

It looks like the assumption now is that some project has to own an API key and then multiple projects in an organization can be assigned roles. That breaks top-down control flows where some organization keys are created centrally and shared down to independent projects for usage. An example would be keys for HashiCorp Vault or other in-house automation workflows.

It looks like this feature is still supported via the direct API with https://www.mongodb.com/docs/atlas/reference/api-resources-spec/v2/#tag/Programmatic-API-Keys/operation/addProjectApiKey

Is there a missing resource that could be added along the lines of mongodbatlas_project_api_key_assignment that takes an existing key ID and makes a non-exclusive assignment to the project?

[github-actions]

Thanks for opening this issue! Please make sure you've followed our guidelines when opening the issue. In short, to help us reproduce the issue we need:

• Terraform configuration file used to reproduce the issue
• Terraform log files from the run where the issue occurred
• Terraform Atlas provider version used to reproduce the issue
• Terraform version used to reproduce the issue
• Confirmation if Terraform OSS, Terraform Cloud, or Terraform Enterprise deployment

The ticket CLOUDP-237759 was created for internal tracking.

[AgustinBettati]

Hello @jmccarty3.

The most significant changes related to the handling of PAKs came in version 1.10.0, where docs/guides/Programmatic-API-Key-upgrade-guide-1.10.0 has details of the changes that where made and its motivations.

With that said mongodbatlas_project_api_key is the resource that handles the assignments of projects with specific project-level roles. This resource does in fact handle the creation of the api key as well.

To confirm my understanding, you would like to leverage existing org level api keys (potentially defined with mongodbatlas_api_key) with the possibility of managing assignments of projects for that key.

One alternative is to import this key into the mongodbatlas_project_api_key resource and then define or remove project assignments accordingly. This does have the limitation that the key needs at least one project assignment in order to be able to import the resource.

[jmccarty3]

@AgustinBettati Yes I have read through the documentation around the change to using PAKs with projects from the upgrade. For many scenarios I also agree with the motivations for creating/working with the keys in this new manner.

However, your understanding of my ask is correct. I would like to assign existing Organization keys to projects and manage project assignment outside of the new PAK model. Using a "shadow" project to own an organization key that is used across multiple projects does not really help for two main reasons.

1. It creates "cruft" projects for the sole purpose of "owning" a key and not actually being useful. If there is no other need for the project, why create it to only own keys?

2. It still creates an issue where a central object must know about all projects that require using the key which introduces both management overhead and requires more coordination between groups in a distributed organization.

Since the API still explicitly supports adding a key to a project, does a new resource type possibly make sense? Or is that API feature possibly slated to be removed?

[github-actions]

This issue has gone 7 days without any activity and meets the project’s definition of "stale". This will be auto-closed if there is no new activity over the next 7 days. If the issue is still relevant and active, you can simply comment with a "bump" to keep it open, or add the label "not_stale". Thanks for keeping our repository healthy!