https://pulumi.com logo
Join Slack
Powered by
AWS credential insanity -- we have a `Pulumi.dev.y...
# getting-started
a
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.
l
Golden rule: never use any default provider. Always create and use explicit providers.
a
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:
Copy code
// 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"?
l
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.
You should avoid calling 
pulumi.getStack()
or similar antwhere except index.ts. It makes unit testing very hard.
a
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
l
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.
a
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
l
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:
Copy code
const nestResource = new Bucket(`${name}-discriminator`, { /* args */ }, { ...opts, parent: this });
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?
a
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:
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
Thanks again @little-cartoon-10569 much appreciated
19 Views
Open in Slack
PreviousNext
Powered by