https://pulumi.com logo
Title
g

gorgeous-minister-41131

06/02/2021, 7:13 PM
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.
b

billowy-army-68599

06/02/2021, 8:00 PM
hey, sorry for the delay.
The providers you pass to the resources and the awskms auth are handled differently. You can set the
aws:profile
configuration key using
pulumi config set aws:profile
and that becomes the default for all resources. You could then use
AWS_PROFILE
as an env var for the aws_kms
b

bored-activity-40468

06/03/2021, 3:20 AM
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.
ported form the C# version, haven't tested it much yet
g

gorgeous-minister-41131

06/10/2021, 2:04 AM
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!
b

bored-activity-40468

06/10/2021, 2:32 PM
This is the GitHub link for the ‘invalid’ workaround https://github.com/pulumi/pulumi/issues/3383
g

gorgeous-minister-41131

06/10/2021, 7:52 PM
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…
Ideally we should just move to not relying on the default provider, but that still doesn’t make it easy for one to use the awscmk decrypt without remembering to set a profile. It’s not the worst thing, but would help with the out-of-the-box experience
We currently isolate 90% of our stacks by AWS account [isolation] so rarely have to call in a second provider, thus, the default provider is sufficient for our needs.