Added support for access tokens in gcpkms

[christoffer-eide]

This PR adds support for access token (via the GOOGLE_CREDENTIALS env var).

If the env var GOOGLE_CREDENTIALS is not set, the gcloud sdk fetches an access token from the instance metadata endpoint http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token.

In our workload on GKE, we don't want to use the access token returned by the metadata endpoint directly. We use this access token to impersonate another service account, which has the minimum of permissions required for the kms decrypt.

There is no facility to set access tokens in sops, only static (long lived) credentials via the credentials file/GOOGLE_CREDENTIALS.

[devstein]

Thanks for contributing @christoffer-eide 🥇

Looks good to me. Can you quickly fix the merge conflicts?

cc @getsops/maintainers if anyone else wants to take a look

[devstein]

(Meant to comment, not approve yet)

[devstein]

Can you add a note to the GCP KMS docs for others to discover this feature?

[devstein]

Hey @christoffer-eide 👋 - someone else just opened a PR #1578 for the same functionality.

Are you able to address the comments, so we can get this merged?

[christoffer-eide]

I'm so sorry, I completely forgot about this 😱

Regarding the proposed change in #1578, it would make it more convenient to have a separate env var for setting the access token.

It would interact better with the gcloud cli,

CLOUDSDK_AUTH_ACCESS_TOKEN ="$(gcloud auth print-access-token)"

vs

GOOGLE_CREDENTIALS ="$(gcloud auth print-access-token --format json | jq '{"access_token": .token}')"

If you think that #1578 is a better solution, this PR can be closed without merging.

[devstein]

All good @christoffer-eide! I agree that using a separate env var CLOUDSDK_AUTH_ACCESS_TOKEN, which is the same behavior as the GCP libraries, makes more sense.

Appreciate the contribution!

Closing in favor of #1578