Because my Pulumi state lives in a shared `pulumi-...
# google-cloud
l
Because my Pulumi state lives in a shared
pulumi-state
GCP project and my resources will live in a completely separate project.
g
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).
b
I believe most gcp-native pulumi resources have a
project_id
arg you can manually set. I'd store it as a pulumi config tho
l
I'm exporting a
GOOGLE_CREDENTIALS
env var which points to a service account key
I can set the
project_id
so that's not an issue, but the deployment will try and use the service account (provided by the
GOOGLE_CREDENTIALS
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
gcs://
bucket (eg. called
my-app-deployer
) 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
GOOGLE_CREDENTIALS
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
pulumi-states
project that can write into a GCS bucket to save the state changes; one service account in
my-project
that will actually deploy the resources)
g
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 https://www.pulumi.com/registry/packages/gcp/api-docs/provider/). I'd personally lean toward the config set secret version, but you can use either one.