Skip to content
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

Importing API Keys does not work using Crossplane #375

Open
andrewjc03 opened this issue Apr 3, 2024 · 6 comments
Open

Importing API Keys does not work using Crossplane #375

andrewjc03 opened this issue Apr 3, 2024 · 6 comments

Comments

@andrewjc03
Copy link

Hi,

I am running into issues when importing API Keys via a Crossplane composition (which uses this provider). From what I understand this is the way to import API Keys:

$ export CONFLUENT_CLOUD_API_KEY="<cloud_api_key>"
$ export CONFLUENT_CLOUD_API_SECRET="<cloud_api_secret>"
$ export API_KEY_SECRET="<api_key_secret>"

# Option #1: Cluster API Key
$ terraform import confluent_api_key.example_kafka_api_key "env-abc123/UTT6WDRXX7FHD2GV"

However, when I try to import API Keys in Crossplane it does not work because the API_KEY_SECRET needs to be set as an environment variable. The issue is that this variable get only be set once in the DeploymentRuntimeConfig of the confluent provider (https://github.com/crossplane-contrib/provider-confluent), which means that if there are multiple keys there is no way to have a separate variable for each one.

Do you know if there is a workaround for this, so that I will be able to import multiple API Key resources successfully? Or if possible can the capability for multiple API_KEY_SECRET environment variables be added, one for each API Key?

Any help would be appreciated on this!

Thank you,
Andrew

@linouk23
Copy link
Collaborator

linouk23 commented Apr 3, 2024

Thanks for creating this issue @andrewjc03!

Do you know if there is a workaround for this, so that I will be able to import multiple API Key resources successfully? Or if possible can the capability for multiple API_KEY_SECRET environment variables be added, one for each API Key?

We don't know about such a workaround yet, but we'll think about it.

As a short term workaround, we'd probably recommend to create new API Keys instead.

@andrewjc03
Copy link
Author

Got it, thank you @linouk23! Please let me know if there is anything I can do to help if you proceed with adding this feature!

Thanks,
Andrew

@andrewjc03
Copy link
Author

Hey @linouk23,

I just realized that I won't be able to create new API Keys since I am doing a migration from previous Terraform infrastructure and I am required to use the existing API Keys. 😔

To help with the development process, would you be open to accepting an outside contribution / discussion for this or is this discussion private to existing confluent contributors? I was thinking that with an open discussion with the open source community, we can all come together and think of a way to solve this issue.

Please let me know your thoughts on this!

With gratitude,
Andrew

@linouk23
Copy link
Collaborator

linouk23 commented Apr 3, 2024

To help with the development process, would you be open to accepting an outside contribution / discussion for this. <> I was thinking that with an open discussion with the open source community, we can all come together and think of a way to solve this issue.

Sure thing!

@tarciosaraiva
Copy link

I'm interested in this from a different point of view: terraform has been supporting import blocks since v1.5 and although marked as experimental it is a nice add to their configuration language as it reduces the amount of cli commands required.

Having a dependency on an environment variable kinda limits that because we could be using a data block to read the secret from a secret store and populate the key appropriately in the imported resouce.

Any chance this could be looked into?

@linouk23
Copy link
Collaborator

@tarciosaraiva, could you open a separate issue for your request? I'm not 100% sure, but I suspect yours might be a bit easier to implement? Thank you!

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

No branches or pull requests

3 participants