Because my Pulumi state lives in a shared `pulumi-...
# google-cloud
Because my Pulumi state lives in a shared
GCP project and my resources will live in a completely separate project.
Pulumi is authorizing using your credentials, right? Not a service account? If it's the former, Pulumi is being authenticated via your creds, which have access to both projects. Then you can set up the code to access different projects (most resources in GCP native, if I remember correctly, have a project field).
I believe most gcp-native pulumi resources have a
arg you can manually set. I'd store it as a pulumi config tho
I'm exporting a
env var which points to a service account key
I can set the
so that's not an issue, but the deployment will try and use the service account (provided by the
env var) to do the deployment
basically, my pattern so far has been to create a GCP service account that only has the ability to write the Pulumi state in the provided
bucket (eg. called
) This has been fine because I've been deploying K8s services so far, so not had the need to deploy GCP resources too.
Now that I want to deploy some GCP resources, I realise that Pulumi is trying to use the
service account key for both my state storage and as the account to deploy the GCP resources
I can give this account access to do both, but I was hoping to keep them separate (ie. one service account in
project that can write into a GCS bucket to save the state changes; one service account in
that will actually deploy the resources)
Ah, got it. Yes, it can be done to have multiple service accounts. Keep the env var to access state storage. Then, you'll set the resource creds either in the stack configuration (
pulumi config set --secret <service-account-name> <secret-key>
as an example) or as an explicit provider in the resource options (as in I'd personally lean toward the config set secret version, but you can use either one.