Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

aws.eks.Cluster enforces persisting $AWS_PROFILE in the code #647

Closed
filip-zyzniewski opened this issue Dec 24, 2021 · 4 comments
Closed
Assignees
Labels
kind/bug Some behavior is incorrect or out of spec resolution/fixed This issue was fixed
Milestone

Comments

@filip-zyzniewski
Copy link

filip-zyzniewski commented Dec 24, 2021

Hello!

  • Vote on this issue by adding a 馃憤 reaction
  • To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already)

Issue details

When the AWS_PROFILE environment variable is set when running pulumi, the constructor of aws.eks.Cluster fails if the providerCredentialOpts input is not provided.
This assumes that all places where this pulumi program runs have the same setup. This is not the case for us - we run Pulumi on our workstations for previews during development (and we use AWS profiles there), and then CI/CD performs previews and updates on the same program, but without AWS profiles.
It seems strange to be forced to hardcode authentication information in the Pulumi program.

Steps to reproduce

  1. export the AWS_PROFILE environment variable
  2. instantiate aws.eks.Cluster in the Pulumi program
  3. run pulumi preview

Expected: a preview
Actual:

Diagnostics:
  pulumi:pulumi:Stack (<stack>):
    error: Running program '<srcdir>' failed with an unhandled exception:
    Error: It looks like you're using AWS profiles. Please specify this profile in providerCredentialOpts.
        at new Cluster (<srcdir>/node_modules/@pulumi/cluster.ts:1396:19)
        at Object.<anonymous> (<srcdir>/kubernetes-cnc.ts:79:17)
        at Module._compile (node:internal/modules/cjs/loader:1095:14)
        at Module.m._compile (<srcdir>/node_modules/ts-node/src/index.ts:439:23)
        at Module._extensions..js (node:internal/modules/cjs/loader:1124:10)
        at Object.require.extensions.<computed> [as .ts] (<srcdir>/node_modules/ts-node/src/index.ts:442:12)
        at Module.load (node:internal/modules/cjs/loader:975:32)
        at Function.Module._load (node:internal/modules/cjs/loader:816:12)
        at Module.require (node:internal/modules/cjs/loader:999:19)
        at require (node:internal/modules/cjs/helpers:93:18)     

This is being thrown @

if (process.env.AWS_PROFILE && !args.providerCredentialOpts) {
throw new Error("It looks like you're using AWS profiles. Please specify this profile in providerCredentialOpts.");
}
.

@filip-zyzniewski filip-zyzniewski added the kind/bug Some behavior is incorrect or out of spec label Dec 24, 2021
@viveklak
Copy link
Contributor

cc @lblackstone for thoughts here. Ideally setting providerCredentialOpts should just override the environment variables. If not specified the environment variables or pulumi config take precedence.

@lblackstone
Copy link
Member

cc @lblackstone for thoughts here. Ideally setting providerCredentialOpts should just override the environment variables. If not specified the environment variables or pulumi config take precedence.

Yeah, that sounds right to me. We might want to log a warning if they are different, but there are valid cases where they would be.

@soydantaylor
Copy link

This doesn't really cover the use case where you're authenticating via AssumeRole. Lots of security postures out there that won't allow explicit use of an IAM user with ACCESS_KEY_ID and SECRET_ACCESS_KEY Also need a way to put this into a CI/CD pipeline where using credentials like that is an anti-pattern anyway.

@stack72
Copy link
Contributor

stack72 commented Jul 29, 2022

Closed as of #561 - apologies we didn't close this issue out earlier

@stack72 stack72 self-assigned this Jul 29, 2022
@stack72 stack72 added the resolution/fixed This issue was fixed label Jul 29, 2022
@stack72 stack72 added this to the 0.76 milestone Jul 29, 2022
@stack72 stack72 closed this as completed Jul 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Some behavior is incorrect or out of spec resolution/fixed This issue was fixed
Projects
None yet
Development

No branches or pull requests

5 participants