rich-agency-7520705/31/2022, 4:21 AM
echoing-dinner-1953105/31/2022, 6:18 AM
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.
rich-agency-7520705/31/2022, 6:44 AM
only and read: "The Pulumi application also works with
so you can use that instead of
so all good. QQ - (Prior to the creation of an additional Gitlab
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
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-1953105/31/2022, 6:49 AM
then the pulumi program would of used that for the KMS provider, while I think the google cloud provider access would prefer
. Not 100% sure about that though.