This message was deleted.

Hey! I believe it uses the permissions of the underlying user invoking the Pulumi CLI. The provider isn’t aware of the secrets.

So if I try to do

pulumi stack config get secretValue --secret

and the underlying secret provider is GCP KMS, it will fail if I don’t have the proper RBAC permissions for the Pulumi stack regardless of whether my

gcloud

user can access the KMS key?

I don't actually know the answer to that one /cc @white-balloon-205?

Pulumi stack RBAC defines what data you can read and write to the Pulumi service - data about projects, stacks, updates, etc. I actually do not believe any RBAC permissions are needed for

pulumi config get

as that does not need to read or write from the Pulumi service. Are you seeing errors when you try to do this?

I wasn’t, was just doing some GCP work on KMS and an engineer suggested using it as a secret provider (we use the default right now) and I was wondering how the encryption key access was going to play with Pulumi access. It sounds like they don’t overlap since in encryption and decryption happens separately from managing Pulumi resources

You configure the KMS key for each stack you initialize, so you are in control of whether you share across stacks or use unique keys per stack.

Perfect