Aws-cdk: CDK_DEFAULT_ACCOUNT Environment variable not respected

Created on 11 Jul 2019  路  8Comments  路  Source: aws/aws-cdk

  • I'm submitting a ...

    • [x] :beetle: bug report
    • [ ] :rocket: feature request
    • [ ] :books: construct library gap
    • [ ] :phone: security issue or vulnerability => Please see policy
    • [ ] :question: support request => Please see note at the top of this template.
  • What is the current behavior?
    If the current behavior is a :beetle:bug:beetle:: Please provide the steps to reproduce

When using a Stack that contains: ec2.Vpc.fromLookup I'm unable to use the CDK_ACCOUNT_DEFAULT environment variable to complete a lookup. If I specify the region & account ID in the cdk.StackProps then it works, but that isn't going to work for my use case. We promote stacks to an Integration account before moving to our Production account. Stacks need to be account agnostic.

CDK_ACCOUNT_DEFAULT=555555555555 cdk list --verbose

Result

...
Setting "CDK_DEFAULT_REGION" environment variable to us-east-2
Resolving default credentials
Unable to determine the default AWS account (did you configure "aws configure"?): SharedIniFileCredentialsProviderFailure: Credentials not set for profile default
    at SharedIniFileCredentials.load (/usr/local/lib/node_modules/aws-cdk/node_modules/aws-sdk/lib/credentials/shared_ini_file_credentials.js:161:11)
    at SharedIniFileCredentials.coalesceRefresh (/usr/local/lib/node_modules/aws-cdk/node_modules/aws-sdk/lib/credentials.js:205:12)
    at SharedIniFileCredentials.refresh (/usr/local/lib/node_modules/aws-cdk/node_modules/aws-sdk/lib/credentials/shared_ini_file_credentials.js:185:10)
    at SharedIniFileCredentials.get (/usr/local/lib/node_modules/aws-cdk/node_modules/aws-sdk/lib/credentials.js:122:12)
    at resolveNext (/usr/local/lib/node_modules/aws-cdk/node_modules/aws-sdk/lib/credentials/credential_provider_chain.js:125:17)
    at /usr/local/lib/node_modules/aws-cdk/node_modules/aws-sdk/lib/credentials/credential_provider_chain.js:126:13
    at /usr/local/lib/node_modules/aws-cdk/node_modules/aws-sdk/lib/credentials.js:124:23
    at EnvironmentCredentials.refresh (/usr/local/lib/node_modules/aws-cdk/node_modules/aws-sdk/lib/credentials/environment_credentials.js:78:9)
    at EnvironmentCredentials.get (/usr/local/lib/node_modules/aws-cdk/node_modules/aws-sdk/lib/credentials.js:122:12)
    at resolveNext (/usr/local/lib/node_modules/aws-cdk/node_modules/aws-sdk/lib/credentials/credential_provider_chain.js:125:17) {
  message: 'Credentials not set for profile default',
  code: 'SharedIniFileCredentialsProviderFailure',
  time: 2019-07-11T18:14:37.944Z
}
Setting "CDK_DEFAULT_ACCOUNT" environment variable to undefined
  • What is the expected behavior (or behavior of feature suggested)?

Should be able to define the desired account ID with the CDK_ACCOUNT_DEFAULT variable. _Really_, I would vote for CDK to respect the AWS_PROFILE environment variable.

  • What is the motivation / use case for changing the behavior or adding this feature?

  • Please tell us about your environment:

    • CDK CLI Version: 1.0.0
    • Module Version: 1.0.0
    • OS: OSX Mojave
    • Language: TypeScript
  • Other information

We're using AWS SSO and credentials for given accounts are managed through aws-cli profiles. Default profile is meaningless, we move between accounts using named profiles and updating the AWS_PROFILE environment variable.

@aws-cdaws-ec2 guidance

Most helpful comment

I am wondering if this should be re-opened. I am running synth and deploy fine, with my credentials specified in the ~/.aws/config and an an existing ~/.aws/credentials. As soon as I include a lookup, I get the behaviour described above and I can fix it by providing an env in code. While I understand that synth needs credentials for the lookup, I do not see why it cannot work in the same way as deploy, which obviously finds the correct account information, even when not given in code.

All 8 comments

Obviously, I've obfuscated the account ID. I'v verified that when using my active profile the session is valid and as identified in the bug report, when explicitly defining the account ID and region in the cdk.StackProps I'm able to cdk list, etc

I was having a similar problem yesterday, and found a resolution here: #3083

Hope that helps!

Hi @cynicaljoy,

@sjschmidt44 provided what should be a helpful link in resolving this problem (thank you for the assist!). Let me know if the information helped resolve this problem, and I will close out the issue, otherwise I will investigate further.

That worked, however I'd say some documentation about the use of CDK_DEFAULT_REGION and CDK_DEFAULT_ACCOUNT could be added.

Error: Cannot retrieve value from context provider vpc-provider since account/region are not specified at the stack level. Either configure "env" with explicit account and region when you define your stack, or use the environment variables "CDK_DEFAULT_ACCOUNT" and "CDK_DEFAULT_REGION" to inherit environment information from the CLI (no
t recommended for production stacks)

This indicates to me that these environment variables are integrated into the cdk.StackProps -- not that I have to explicitly define the env object. But, now that I'm using it...it makes sense 馃榿

@cynicaljoy glad to hear that worked for you, and I really appreciate the input! I will definitely pass it along for consideration for the next docs rev.

Please let us know if you run into any other problems!

We have recently updated this topic. Can you read through it and let us know if it explains this behavior properly?

I am wondering if this should be re-opened. I am running synth and deploy fine, with my credentials specified in the ~/.aws/config and an an existing ~/.aws/credentials. As soon as I include a lookup, I get the behaviour described above and I can fix it by providing an env in code. While I understand that synth needs credentials for the lookup, I do not see why it cannot work in the same way as deploy, which obviously finds the correct account information, even when not given in code.

Agree with the above ^

Was this page helpful?
0 / 5 - 0 ratings