I feel like the only alternative if you want to use awskms with a profile different than the main provider is to have all your pulumi code using the aws provider initialize its own resource provider and use a completely different profile configuration and pass that thing around to all ResourceOptions (yucky), simply so the awskms stack secrets provider can function with a separate profile.

hey, sorry for the delay.

I set aws:region to invalid, its a workaround to create explicit providers. Then have a context manager (using in .net) to switch assume roles. Also use automation api so secrets provider is set and access keys are in the stack but encrypted.

Okay cool… so that use case may work for us. I’ll have to test it out, but I think last time I tried it, it tried to use the same role i defined in $AWS_PROFILE and the rest of the aws providers [default one, not a reinstantiated custom one as Derek showed] attmpted to use that profile instead of the one set by

aws:profile

. It’s possible I had hit a bug, so I could give it another try. Thanks!

This is the GitHub link for the ‘invalid’ workaround https://github.com/pulumi/pulumi/issues/3383

Confirmed that I am able to set

aws:profile

to use the default aws provider’s aws profile, and set

$AWS_PROFILE

in the environment prior to invoking pulumi with a different profile that has actual access to the CMK. 👍 Thanks @billowy-army-68599. Perhaps a suggestion is a variable like

aws:kms_profile

in the stack would be handy, so that users of the stack do not have to remember to always set that KMS/CMK profile for decrypting the stack contents? not sure if that’s on the roadmap…