Allow imports of service account keys

[juicemia]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment. If the issue is assigned to the "modular-magician" user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If the issue is assigned to a user, that user is claiming responsibility for the issue. If the issue is assigned to "hashibot", a community member has claimed the issue already.

Description

I'm currently working on a refactor of an older Terraform codebase that creates a service account along with a service account key. I'm basically porting the old Terraform to new Terraform, with an up-to-date version of the provider, etc. As I go I'm importing resources into the new state, and when everything is imported I'm just going to delete the old state.

I'm now on the resource for the service account key and I see the docs say it can't be imported. Just in case the docs were somehow wrong, I tried importing it and got this message from Terraform: Error: resource google_service_account_key doesn't support import.

Now I'm at a crossroads. Either I just keep the resource and create a new key with the new state, or I change it to a data source in the refactored code and leave the old key as something that was manually set up. I would just replace the key but I'm afraid of what might happen, so I'm leaning towards changing it to a data source.

What would really be ideal is if I could just import the key. I'm not opposed to opening a PR for this myself, I just wanted to know if there was any particular reason why this wasn't added in the first place before I tried.

New or Affected Resource(s)

• google_service_account_key

b/308247995

[rileykarson]

Note: I can't spot anything that makes this obviously impossible. Older resources don't support import 100% of the time, so it's likely just that nobody added support yet.

[slevenick]

This won't work because service account keys only return the private key information during create, not in later read requests

See: https://github.com/GoogleCloudPlatform/magic-modules/blob/main/mmv1/third_party/terraform/resources/resource_google_service_account_key.go#L130

[juicemia]

This won't work because service account keys only return the private key information during create, not in later read requests.

If the API doesn't return the key on subsequent reads, gibberish could be in the Terraform state and it shouldn't make a difference. Terraform can never tell if the actual key has changed.

EDIT: This would be a problem for anything that depends on the key contents. What if the contents of the key could be provided in the call to import?

[slevenick]

That could work, but I don't think that would be a good solution here. You can use a datasource instead if you don't want the content.

Providing sensitive information in an import call seems dangerous

[juicemia]

You can use a datasource instead if you don't want the content.

The point isn't that I don't want the content, the point is that I have Terraform that I'm refactoring and I'd prefer to keep that key managed by Terraform, instead of having bits of configuration floating around GCP that are manually managed.

Providing sensitive information in an import call seems dangerous

Seems dangerous how? And is it any more dangerous than keeping sensitive information in Terraform state, unencrypted?

@slevenick

[slevenick]

If you are refactoring can you just move the state? That's pretty dangerous and I wouldn't recommend it, but it is a possible way to handle this.

I don't think we want to support this feature though, importing with private key information in the CLI is not a great pattern

[rileykarson]

@slevenick: We'd be able to support import without making the private key info available, right? Effectively letting a user continue to manage the resource in the API w/o interpolations on the secret being possible. https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/storage_hmac_key is a precedent.

[juicemia]

If you are refactoring can you just move the state? That's pretty dangerous and I wouldn't recommend it, but it is a possible way to handle this.

I don't even know how I would do that, but I'm open to trying.

importing with private key information in the CLI is not a great pattern

I think this is a good general rule to follow. However, I think this would be a valid exception to the rule. If you're in the position to import the state, and you have the key data on hand, you're in a pretty powerful position to begin with.

EDIT: @slevenick thank you for reopening the issue. Also, @rileykarson this seems like a good idea, but for my specific use case it wouldn't work, because we're using the key data in an interpolation. However, I don't want to shoot it down just because of that, because I think if I could just get the resource imported, I could at least edit the state manually to put the key data in there. It would be a hack for sure but it would be something that only needed to be done once.

[juicemia]

Just as an update I was able to surgically import the secret into my Terraform state and everything is working correctly.

I'm not sure if your team wants to close this issue or leave it open because you think it's still something worth doing.

[ivanfavi]

@juicemia Could you describe how you achieved to import the secret to your terraform code, please? Just moving info from the terraform state file maybe?

I've failed in the same issue refactoring some terraform code and curious about your solution.

[nergdron]

just ran into this as well, would appreciate a guide as to how to inject the appropriate data into the state, or functionality to support importing without the secret data when refactoring.

[juicemia]

Sorry I just saw these messages.

In my case, I didn't import the secret using the Terraform CLI. After I had imported every other resource, when I would run the plan command the only thing in the diff was the creation of a new service account key. I allowed that key to be created because it didn't affect anything else in my new state. I then downloaded the new Terraform state from the backend, found the JSON for the newly created key, and updated all the values to match the ones for the key in the old state. I'm taking this from my notes because it's already been close to a year since I did this and I don't remember exactly.

If you do this, be careful that creating a new key doesn't break anything. If creating a new key then changes other things that depend on that new key, updating the new state with the details about the old key will break your state.

[benhxy]

Service account team here. I think import is a reasonable feature as it's supported by gcloud (https://cloud.google.com/sdk/gcloud/reference/iam/service-accounts/keys/upload). Uploading a public certificate that's in customer's possession isn't a security concern.