Closed upodroid closed 4 months ago
Just a couple minor comments/thoughts from me right now. Nothing necessarily actionable- as Dana noted in https://github.com/GoogleCloudPlatform/magic-modules/pull/3999 it's likely we make a decision when we're closer to 4.0.0
- just writing down some thoughts before I forget them.
credentials
and access_token
allow multiple provider blocks to be defined with distinct auth methods. Is that behaviour we don't think is being used, or shouldn't get used?access_token
is that users wanted it to be able to supply access tokens from Vault. Unfortunately we didn't record that in the original PR. Is that still a desirable usecase?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 google.golang.org/api/transport
package.
@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
@upodroid
The approach of pulling access_tokens from Vault isn't a great idea. Usually, the person running terraform for GCP will have a Google account that they use to interact with the console
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.
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. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
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 source
google_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: https://github.com/hashicorp/terraform-provider-google/pull/5670, Issue: https://github.com/hashicorp/terraform-provider-google/issues/7333~The data source
google_storage_object_signed_url
also needs work too. https://github.com/hashicorp/terraform-provider-google/issues/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.