Note: my CICD env does not utilise the gcloud sdk. I am purposefully constructing a GitOps workflow where the gcloud sdk is not a dependency.

Note: 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.

👍 - Thx @echoing-dinner-19531 Still early here - I was going to see if I could use

GOOGLE_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.

Yeh I think if you had set

GOOGLE_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.