https://pulumi.com logo
Title
m

millions-furniture-75402

10/31/2022, 3:38 PM
What pattern are folks using for duplicating and amending their default provider configuration? I need to declare a second provider with same settings as default, but with a different region. Deploying locally is different than in CI.
let awsProviderDefaults;
if (!process.env.AWS_ACCESS_KEY_ID) {
  aws.sdk.config.credentials = new aws.sdk.SharedIniFileCredentials({ profile: awsConfig.get("profile") });
  awsProviderDefaults = { profile: awsConfig.get("profile") };
} else {
  awsProviderDefaults = {
    accessKey: process.env.AWS_ACCESS_KEY_ID,
    secretKey: process.env.AWS_SECRET_ACCESS_KEY,
    token: aws.sdk.config.sessionToken,
  };
}
const awsUsEast1 = new aws.Provider("east", {
  region: "us-east-1",
  ...awsProviderDefaults,
});
Ahh yes, but this still fails because the default provider has a
profile
and env vars don't override profile any more.
I've resorted to using this command in CI before `up`:
pulumi config rm aws:profile
l

little-cartoon-10569

10/31/2022, 6:25 PM
We do the opposite. Require that aws:profile is always set. Lint rule to check the stack file. Disable default provider, pass provider everywhere. And when constructing providers, always provide
profile: awsConfig.require("profile");
And if we need to change the profile for an environment, we do that in the build script or whatever, before calling Pulumi.
m

millions-furniture-75402

10/31/2022, 7:56 PM
"pass provider everywhere" The part I hate 😞
That said, it's probably the better strategy long-term
The other downside of using an AWS profile in CI is that the secrets would be written to disk
l

little-cartoon-10569

10/31/2022, 8:00 PM
I'm a big fan of being OTT explicit. Allowing people to guess providers isn't convention-over-configuration, it's just making it easier to hide bugs..
Our AWS profiles only ever contain session creds, max duration an hour. We often have "permanent" profiles, but they use role_arn and source_profile. The base profiles are always temporary creds.
And we use OIDC for our CI-initiated deployments. That was great, when GitHub announced that.
m

millions-furniture-75402

10/31/2022, 8:02 PM
Yeah, I think long-term it's the best strategy given the default provider being tightly coupled with the Stack config. The problem isn't even the verbosity, but the cases where we have abstractions that will make passing the explicit provider a bigger chore.
Your setup sounds similar to ours
l

little-cartoon-10569

10/31/2022, 8:06 PM
We have a base library that builds AWS providers for us, based on things like well-known account IDs and stack names. We construct providers wherever needed.
m

millions-furniture-75402

10/31/2022, 8:08 PM
Ahh, interesting. We have similar, for helpers and custom component resource definitions (
pulumi-components
).