auth alternative: service account impersonation

[calbach]

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

The current options available for GCP Terraform authentication from a workstation appear to be either application default credentials (ADC) or service account key files.

• ADC is problematic because some GCP APIs do not support gcloud-based authentication, e.g. for VPC-SC: Error 403: Your application has authenticated using end user credentials from the Google Cloud SDK or Google Cloud Shell which are not supported by the accesscontextmanager.googleapis.com
• Managing a secret SA keyfile introduces security risks

A new alternative provided by gcloud is the --impersonate-service-account flag. This uses a short-term key exchange rather than a keyfile download. If the google Terraform provider had a way of accepting a similar credential (e.g. transforming ADC into impersonated SA creds), that would allow easy/secure terraform usage from local workstations.

New or Affected Resource(s)

• provider google

Potential Terraform Configuration

provider "google" {
  impersonate_service_account: "[email protected]"
}

[rileykarson]

There are two tools in the provider that may help here:

• user_project_override associates requests using gcloud credentials with the provider/resource's project, causing user creds to work with some APIs where they otherwise wouldn't.

• data.google_service_account_access_token allows you to retrieve the access token for a service account, and impersonate it by feeding the token into a second provider block (see the example on the resource)

If neither of these work for you, please let me know! I'll leave this issue open until you've had a chance to try those.

[calbach]

Thanks @rileykarson ! I couldn't get approach (1) to work for my case, presumably since the Access Context Manager APIs are acting at an organization level (no default project). However, approach (2) does what I was asking for with a couple extra lines - which is fine.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!