add access token authentication

[bradkwadsworth-mw]

Signed-off-by: Brad Wadsworth brad.wadsworth@mavenwave.com

Description of your changes

Allow use of temporary service account access tokens to be used for authentication.

Fixes #65

I have:

• Run make reviewable test to ensure this PR is ready for review.

How has this code been tested

Updated Configuration.md with instructions on how to test with access tokens.

[Upbound-CLA]

All committers have signed the CLA.

[ulucinar]

Hi @bradkwadsworth-mw,
Thank you for working on introducing token-based authentication support to provider-gcp.

My understanding is that the PR proposes to switch to token-based auth. by inspecting the referenced credential data (trying to parse the supplied credentials as JSON) and if this succeeds, use token authentication in the underlying Terraform (native) provider by configuring the access_token argument in the provider block. And if it fails, it configures the credentials argument of the provider block for the native provider.

I would prefer a more explicit API where we have a separate credential source (enum) constant for the token-based authentication like we do for provider-aws here. Then we could configure the access_token argument for the native provider configuration block in this switch when the credential source is AccessToken.

This would expose an explicit API for token-based authentication with, in my opinion, better UX. Because we are surfacing the API to the credential source (enums) level, it will be easier for users to follow what options are supported and to enable them to specify their intentions (regarding the auth. mechanism to use) in a more explicit manner. For instance, if the user of the ProviderConfig API would like to use token-based auth. but has a syntax error in the JSON credentials she supplies, then we would implicitly be switching to service principal credentials-based authentication, although the intent was different. What do you think?

[bradkwadsworth-mw]

Hi @bradkwadsworth-mw, Thank you for working on introducing token-based authentication support to provider-gcp.

My understanding is that the PR proposes to switch to token-based auth. by inspecting the referenced credential data (trying to parse the supplied credentials as JSON) and if this succeeds, use token authentication in the underlying Terraform (native) provider by configuring the access_token argument in the provider block. And if it fails, it configures the credentials argument of the provider block for the native provider.

I would prefer a more explicit API where we have a separate credential source (enum) constant for the token-based authentication like we do for provider-aws here. Then we could configure the access_token argument for the native provider configuration block in this switch when the credential source is AccessToken.

This would expose an explicit API for token-based authentication with, in my opinion, better UX. Because we are surfacing the API to the credential source (enums) level, it will be easier for users to follow what options are supported and to enable them to specify their intentions (regarding the auth. mechanism to use) in a more explicit manner. For instance, if the user of the ProviderConfig API would like to use token-based auth. but has a syntax error in the JSON credentials she supplies, then we would implicitly be switching to service principal credentials-based authentication, although the intent was different. What do you think?

That sounds good to me as well. I'll work on that.

[ulucinar]

Triggered to check the Secret provider authentication scheme:
/test-examples="examples/compute/address.yaml"

[ulucinar]

Hi @bradkwadsworth-mw,
Thank you very much for working on the new authentication scheme!
Left some nitpicks but I think the most important review comment is regarding the import statement. Because the actual authentication is performed by the underlying Terraform provider, which is a separate binary, do we really need the import statement?

[ulucinar]

Triggered to check the Secret provider authentication scheme:
/test-examples="examples/compute/address.yaml"