GCP service account impersonation permission issues about terraform-provider-sops HOT 3 CLOSED

Hi @viktorvoltaire!
Hm, I think that'd be quite a chunk of work to implement, since sops supports quite a few decryption backends, and we'd then need to build support for them all? Or do you see some simpler way?

For what it's worth, the approach I've taken in Cloud Build specifically is to do impersonation via gcloud in the step image, and it works quite well and transparently (it also means authentication to GKE etc etc works pretty much without any adaptions to the relevant providers). We've wrapped this in our terraform image's ENTRYPOINT:

project_id="$(gcloud config get-value project 2> /dev/null)"
export GOOGLE_OAUTH_ACCESS_TOKEN="$(gcloud auth print-access-token --impersonate-service-account=your-terraform-service-account-name@${project_id}.iam.gserviceaccount.com)"
exec terraform "$@"

So then the entire execution of Terraform is run as the "right" SA.

from terraform-provider-sops.

Hi @carlpett :)

Hm, I think that'd be quite a chunk of work to implement, since sops supports quite a few decryption backends, and we'd then need to build support for them all? Or do you see some simpler way?

Hmm, you are probably right, there is no simple way of doing it.

So then the entire execution of Terraform is run as the "right" SA.

Cloud build actually just released a feature where you can set the service account in the trigger settings, so no assuming is actually needed. I think we will use that to solve this problem.

Thanks for the swift response 🥳

from terraform-provider-sops.

Yep, you can do that too! We tend to have multiple steps that need to happen in our builds, and don't necessarily want the terraform account we use to be allowed to do all of them, but if you can split it up better than we have, then it might be a better alternative :)

from terraform-provider-sops.