AWS credential insanity we have a `Pulumi dev yaml` and `Pul

Question

AWS credential insanity we have a `Pulumi dev yaml` and `Pulumi prod yaml` Each of these files has a single `aws allowedAccountIds` account id They also each set a single `aws profile` While on our `dev` stack I ran `pulumi up` and Pulumi created some of the resources in AWS account 1 dev and others in AWS account 2 prod Honestly I m absolutely astounded this is even remotely possible It seems to me even with the `allowedAccountIds` and `aws profile` config options set pulumi sometimes somehow just decides to use the ` default ` credentials in aws credentials Has anyone else experienced this This is not the first time I ve experienced strange AWS credential issues with Pulumi This seems extremely extremely bad

little-cartoon-10569 · Answer

Golden rule never use any default provider Always create and use explicit providers

acoustic-plumber-13001 · Answer

Thanks < little cartoon 10569> I ve read the pulumi aws docs time and again but still not sure what that means I think it means

acoustic-plumber-13001 · Answer

``` Create an ACM certificate in us east 1 let cert = new aws acm Certificate cert domainName <http foo com|foo com> validationMethod EMAIL provider useast1 ``` For every single resource you create explicitly pass a provider If that s what you meant then when creating the provider object you need to use pulumi get environment

little-cartoon-10569 · Answer

Yes it s that Link <https www pulumi com docs intro concepts resources options provider > However you don t need to get environment anywhere outside of your index ts Create all the providers you need in index ts then pass them around Use option inheritance in ComponentResources and you re good

little-cartoon-10569 · Answer

You should avoid calling `pulumi getStack ` or similar antwhere except index ts It makes unit testing very hard

acoustic-plumber-13001 · Answer

gt Use option inheritance in ComponentResources and you re good Meaning you don t need to explicitly set provider on every resource only on parent resources correct All children resources can inherit from that And thanks these things should be explained in the pulumi getting started docs

little-cartoon-10569 · Answer

I think at getting started level default provider is okay and examples never use component resources But the getting started with component resources docs should definitely include best practices like this

acoustic-plumber-13001 · Answer

Agreed I ll submit a github issue but the fact that pulumi could accidentally deploy resources to an aws account that is not listed in `aws allowedAccountIds` seems really bad

little-cartoon-10569 · Answer

Yes you don t need to define providers inside components that have been given a provider they inherit However I recommend always explicitly inheriting all options because that s good for opts like protect additionalSecretOutputs and ignoreChanges ```const nestResource = new Bucket `$ name discriminator` args opts parent this ```

little-cartoon-10569 · Answer

I don t know about `allowedAccountIds` It s listed in <https www pulumi com registry packages aws api docs provider allowedaccountids nodejs> but not documented Does it ever work

acoustic-plumber-13001 · Answer

It didn t just now Deployed 10 resources to our dev account 1 resource to our prod account On a totally new stack with dev yaml and prod yaml including both `aws allowedAccountIds` and `aws profile` Our dev yaml

acoustic-plumber-13001 · Answer

Either used the ` default ` from aws credentials or one named ` prodpulumi ` I m glad I caught this early could have been quite bad if I had been attempting to delete or edit existing resources in dev account

acoustic-plumber-13001 · Answer

Thanks again < little cartoon 10569> much appreciated