rich-agency-75207
05/31/2022, 4:21 AMechoing-dinner-19531
05/31/2022, 6:18 AMNote: my CICD env does not utilise the gcloud sdk. I am purposefully constructing a GitOps workflow where the gcloud sdk is not a dependency.Pulumi's implementation of secrets via googles KMS service is done via the gcloud SDK, so we pick up a dependency on their envvars as well. We do have a workaround for this that we apply to google bucket objects accessed via the gcloud sdk, looks like we just need to copy that workaround to the secret system as well. https://github.com/pulumi/pulumi/issues/3919 tracks that work.
rich-agency-75207
05/31/2022, 6:44 AMGOOGLE_APPLICATION_CREDENTIALS
only and read: "The Pulumi application also works with GOOGLE_APPLICATION_CREDENTIALS
so you can use that instead of GOOGLE_CREDENTIALS
so all good.
QQ - (Prior to the creation of an additional Gitlab GOOGLE_APPLICATION_CREDENTIALS
envvar) - I updated an existing stack re: GCP KMS secret provider change using my local dev env. I do use gcloud sdk there. To resolve that (different to the original permission issue re: CICD job failure) - I re-intialised my default gcloud account to the same SA creds used in my CICD workflow. pulumi, of course, was able to successfully update the secrets provider then.
If I had, instead, simply created the GOOGLE_APPLICATION_CREDENTIALS
envvar in local env would this have worked too? (As opposed to creating a new default account)
btw - thanks for updating the shared ticket too.echoing-dinner-19531
05/31/2022, 6:49 AMGOOGLE_APPLICATION_CREDENTIALS
then the pulumi program would of used that for the KMS provider, while I think the google cloud provider access would prefer GOOGLE_CREDENTIALS
. Not 100% sure about that though.