-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Proposal: Remove credentials and access_token fields from the terraform provider. #7332
Comments
Just a couple minor comments/thoughts from me right now. Nothing necessarily actionable- as Dana noted in GoogleCloudPlatform/magic-modules#3999 it's likely we make a decision when we're closer to
I would be interested if there is guidance on cloud.google.com or other sources that encourages / discourages various authentication methods. One useful precedent could be the @salrashid123 - you've also touched authentication/impersonation related stuff in the past, so if you've got a bit of time I'd be interested in your thoughts as well. |
yeah, i'm not quite sure about removing the parameters for the samereasons above (i.,e you can specify mutliple credentials at runtime). I'm not aware of a single preferred type in the ADC hierarchy but any most situations we don't encourage handling and distributing raw secrets, if possible (you have to in a number of cases...). The ambient credentials (eg metadata) is better than having access to a file.. just for ref, there is a proposal to support "process credentials" within google libraries. In that mode, some arbitrary binary is called "that just gives" a google token. What i mean by that is it could be any binary terraform has access to wherever it runs and that itself procures the access_token. So in that case its provider "google" {
access_token = file("/path/to/somebinary")
project = var.project
} its still a proposal but here is a type of it (to be clear, is unsupported/unofficial). |
Another great article: https://medium.com/google-cloud/a-hitchhikers-guide-to-gcp-service-account-impersonation-in-terraform-af98853ebd37 |
We typically run terraform on Jenkins (outside of GCP), which is not a user. Currently we do authenticate our Jenkins instance using a service principal with Google Cloud, but instead we would like to use access tokens from Vault so that Jenkins does not have any long-lived credentials to GCP. Instead it is provisioned a temporary credential on-demand. We can instead use Vault to generate a service_account_keys and use that, but Google imposes a limit of max 10 keys per service account, so when using that you are bound to run into this limit eventually. So it would be very useful if the access_token functionality was retained and extended so it can read an access token from a file or a subprocess, to deal with renewal. |
Signed-off-by: Modular Magician <magic-modules@google.com>
Unlikely to move forward with this in order to maintain support for OIDC. |
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. |
Affected Resource(s)
Community Note
@danawillow @rileykarson
Objective,
Removing
credentials
andaccess_token
field the provider and specifying service account keys using theGOOGLE_APPLICATION_CREDENTIALS
environment variable.Background
Google Client Libraries have supported loading JSON service account keys before Google introduced the Application Default Credentials in 2015.
https://cloudplatform.googleblog.com/2015/07/Easier-Auth-for-Google-Cloud-APIs-Introducing-the-Application-Default-Credentials-feature.html
Terraform supported this since the first release https://github.com/hashicorp/terraform-provider-google/blob/v0.1.0/google/config.go#L61
https://github.com/hashicorp/terraform-provider-google/blob/v3.40.0/google/config.go#L727
However, authentication options have evolved since then and there a number of better options available.
Overview
There is a problem with having a provider configured like this:
Detailed Design
In the next release of the provider, the
credentials
field will be removed. Users who are using this field must specify the environment variableGOOGLE_APPLICATION_CREDENTIALS
to point to the path of the key. Terraform will then evaluate the credentials in the order specified by the golang client library at https://godoc.org/golang.org/x/oauth2/google#FindDefaultCredentials which I have pasted below.The provider docs at https://www.terraform.io/docs/providers/google/index.html will be updated to mention the following scenarios:
gcloud auth application-default login
cloud-platform
GOOGLE_APPLICATION_CREDENTIALS
environment variable to point to the path of the key.The
access_token
field will be removed in favour ofimpersonate_service_account
. The golang client library supports service account impersonation which replaces the need for having multiple providers and using the access_token datasource. You will need to suppply a valid Application Default Credentials and that identity must have Service Account Token Creator role on the service account you are looking to impersonate.There is the added benefit of leaner code and simplified authentication.
The data sourcegoogle_service_account_id_token
needs to be tweaked. I'm not sure why it was coded to exclude User ADCs even though it works with ADCs. Initial Commit: #5670, Issue: #7333The data source
google_storage_object_signed_url
also needs work too. #3558Alternatives Considered
The alternative is to leave the credentials field but it is shame to tell newcomers that the tutorial at Hashicorp or Training Provider X is very far from what we do for real and that it has some bad practices in it.
Also, it is not uncommon to have other applications such as Packer, Ansible, __ present in the same devops/deployment pipelines which all expect Application Default Credentials so providing service account key via the environment variable shouldn't be too difficult.
The text was updated successfully, but these errors were encountered: