[notice] CDK CLI Authentication Issues

[rix0rrr]

The CDK CLI has some limitations compared to the AWS CLI. If you are having authentication issues, they might be covered by one of the following issues. Please use this thread to discuss further.

CDK CLI will not read your region from your [default] profile

If your ~/.aws/config is set up like this:

[default]
region = us-east-1

[profile MyProfile]
role_arn = arn:aws:iam::123456789012:role/myprofile
source_profile = SomeOtherProfile

Even though your profile MyProfile does not contain a region, the AWS CLI will read the region from the [default] section. The AWS SDK for JavaScript that the CDK is built on does not do this, so the CDK does not support this. Make sure every profile section contains the region.

Cannot have a profile named "default" in the config file

The following will not work:

[default]
...

[profile default]
...

The AWS CLI seems to accept this, but the AWS SDK for JavaScript will fail to load the configuration file properly.

How to properly select AWS CLI profiles for your stacks/accounts

See issue #3961

[vschumaker]

I ran in to the case where a [profile default] of the following format

[default]
output = text
region = us-east-1

[profile default]
role_arn = arn:aws:iam::123456789012:role/myrole
source_profile = default

[profile dev]
source_profile = default
role_arn = arn:aws:iam::987654321012:role/myrole
region = us-east-1

caused the following error, even though my AWS_PROFILE environment variable was set to dev

cdk deploy
Need to perform AWS calls for account unknown-account, but no credentials found. Tried: default credentials.

Removing the [profile default] section allowed me to successfully cdk deploy my stack.

[moofish32]

I'm trying to run npm run integ I have my assume role credentials sourced in the following env vars:

AWS_ACCESS_KEY_ID=xxxxx
AWS_SECRET_ACCESS_KEY=xxxx
AWS_SESSION_TOKEN=xxxx

Is there any reason I would still get an error like:

Trying to deploy ec2/integ.event-task.lit.js
[Error at /aws-ecs-integ-ecs/Vpc] Cannot determine scope for context provider availability-zones with props: account=undefined,region=us-west-2.

Is there a new process for running integ tests?

[moofish32]

Answering my own question for the next person.

My issue was that at some point ~/.aws/config added a similar file to the example above. I deleted the ~/.aws/config because I no longer use it and set the AWS_DEFAULT_REGION=xxxx env var in my shell. After that everything started working. @rix0rrr actually found this. So if you have ~/.aws/credentials and ~/.aws/config they both can't have a default profile section.

[0xdevalias]

Another edge case, in case anyone else runs into it. Using aws-vault

⇒  aws-vault exec myprofile -- cdk diff
Need to perform AWS calls for account unknown-account, but no credentials found. Tried: default credentials.

Looking at ~/.aws/config I had an empty profile: [profile myprofile]

By changing it to include a region, the issue was resolved and cdk diff worked as expected:

[profile myprofile]
region=ap-southeast-2

Maybe updating the error message to be a bit more explicit in what the actual issue is would be helpful?

[r-kuhr]

Just to add on for MFA:

I am having this problem WITHOUT a [profile default] entry. Any idea why I am getting the same error?

[default]
region = eu-central-1

[profile int-server]
source_profile = default
role_arn = arn:aws:iam::121212121212:role/deployer
mfa_serial = arn:aws:iam::421212121212:mfa/[email protected]

[profile prod-server]
source_profile = default
role_arn = arn:aws:iam::321212121212:role/deployer
mfa_serial = arn:aws:iam::421212121212:mfa/[email protected]

error:

Setting "aws:cdk:toolkit:default-region" context to eu-central-1
Resolving default credentials
Unable to determine the default AWS account (did you configure "aws configure"?): { AccessDenied: Access denied

[LechuckThePirate]

Hello... I'm having another authentication issue...

We use a identity account and a governor account role with MFA enabled... my config file looks like this:

[profile default]
region=eu-west-1
role_arn=arn:aws:iam::xxxxxxxxxxxxx:role/xxxxxxxx
mfa_serial=arn:aws:iam::xxxxxxxxxxxx:mfa/[email protected]
source_profile=default

and I have a [default] credentials with my client and secret keys.

I'm running CDK from a AWS Workspace (I don't know if this can be the problem). I get an error saying that I didn't do aws configure ... I did, and I'm providing --profile default to be sure.

Any fix/workaround?

If I try to deploy the hello-cdk app I get this (with --verbose)

PS > cdk deploy --profile default -v
CDK toolkit version: 0.27.0 (build 7638a58)
Command line arguments: { _: [ 'deploy' ],
  trace: false,
  strict: false,
  'ignore-errors': false,
  ignoreErrors: false,
  json: false,
  j: false,
  verbose: true,
  v: true,
  ec2creds: undefined,
  i: undefined,
  'version-reporting': undefined,
  versionReporting: undefined,
  'path-metadata': true,
  pathMetadata: true,
  'asset-metadata': true,
  assetMetadata: true,
  ci: false,
  version: false,
  help: false,
  h: false,
  exclusively: false,
  e: false,
  profile: 'default',
  'role-arn': undefined,
  r: undefined,
  roleArn: undefined,
  'build-exclude': [],
  E: [],
  buildExclude: [],
  '$0': '..\\..\\..\\AppData\\Roaming\\npm\\node_modules\\aws-cdk\\bin\\cdk',
  app: undefined,
  context: undefined,
  plugin: undefined,
  rename: undefined,
  proxy: undefined,
  'toolkit-stack-name': undefined,
  'require-approval': undefined,
  STACKS: [] }
Determining whether we're on an EC2 instance.
cdk.json: {
  "app": "node bin/testapp.js"
}
Setting "aws:cdk:toolkit:default-region" context to undefined
Resolving default credentials
Looks like EC2 instance.
Looking up default account ID from STS
Unable to determine the default AWS account (did you configure "aws configure"?): { InvalidClientTokenId: The security token included in the request is invalid.
    at Request.extractError (D:\xxxxxxxxxxxxxx\AppData\Roaming\npm\node_modules\aws-cdk\node_modules\aws-sdk\lib\protocol\query.js:50:29)
    at Request.callListeners (D:\xxxxxxxxxxxxxx\AppData\Roaming\npm\node_modules\aws-cdk\node_modules\aws-sdk\lib\sequential_executor.js:106:20)
    at Request.emit (D:\xxxxxxxxxxxxxx\AppData\Roaming\npm\node_modules\aws-cdk\node_modules\aws-sdk\lib\sequential_executor.js:78:10)
    at Request.emit (D:\xxxxxxxxxxxxxx\AppData\Roaming\npm\node_modules\aws-cdk\node_modules\aws-sdk\lib\request.js:683:14)
    at Request.transition (D:\xxxxxxxxxxxxxx\AppData\Roaming\npm\node_modules\aws-cdk\node_modules\aws-sdk\lib\request.js:22:10)
    at AcceptorStateMachine.runTo (D:\xxxxxxxxxxxxxx\AppData\Roaming\npm\node_modules\aws-cdk\node_modules\aws-sdk\lib\state_machine.js:14:12)
    at D:\xxxxxxxxxxxxxx\AppData\Roaming\npm\node_modules\aws-cdk\node_modules\aws-sdk\lib\state_machine.js:26:10
    at Request.<anonymous> (D:\xxxxxxxxxxxxxx\AppData\Roaming\npm\node_modules\aws-cdk\node_modules\aws-sdk\lib\request.js:38:9)
    at Request.<anonymous> (D:\xxxxxxxxxxxxxx\AppData\Roaming\npm\node_modules\aws-cdk\node_modules\aws-sdk\lib\request.js:685:12)
    at Request.callListeners (D:\xxxxxxxxxxxxxx\AppData\Roaming\npm\node_modules\aws-cdk\node_modules\aws-sdk\lib\sequential_executor.js:116:18)
  message: 'The security token included in the request is invalid.',
  code: 'InvalidClientTokenId',
  time: 2019-04-01T10:23:27.706Z,
  requestId: '30626f19-5468-11e9-b302-4524a75e3687',
  statusCode: 403,
  retryable: false,
  retryDelay: 16.893920433979147 }
Setting "aws:cdk:toolkit:default-account" context to undefined
context: { 'aws:cdk:toolkit:default-region': undefined,
  'aws:cdk:toolkit:default-account': undefined,
  'aws:cdk:enable-path-metadata': true,
  'aws:cdk:enable-asset-metadata': true }
outdir: D:\xxxxxxxxxxxxxx\AppData\Local\Temp\cdkYL2v9X
outfile: D:\xxxxxxxxxxxxxx\AppData\Local\Temp\cdkYL2v9X\cdk.out
{ version: '0.19.0',
  artifacts: 
   { TestappStack: 
      { type: 'aws:cloudformation:stack',
        environment: 'aws://unknown-account/unknown-region',
        properties: [Object],
        metadata: [Object] } },
  runtime: 
   { libraries: 
      { '@aws-cdk/cdk': '0.27.0',
        '@aws-cdk/cx-api': '0.27.0',
        '@aws-cdk/aws-s3': '0.27.0',
        '@aws-cdk/aws-events': '0.27.0',
        '@aws-cdk/aws-iam': '0.27.0',
        '@aws-cdk/region-info': '0.27.0',
        '@aws-cdk/aws-kms': '0.27.0',
        '@aws-cdk/aws-s3-notifications': '0.27.0',
        '@aws-cdk/aws-codepipeline-api': '0.27.0',
        'jsii-runtime': 'node.js/v8.12.0' } },
  stacks: 
   [ { name: 'TestappStack',
       environment: [Object],
       template: [Object],
       metadata: [Object] } ] }
Removing outdir D:\xxxxxxxxxxxxxx\AppData\Local\Temp\cdkYL2v9X
The stack TestappStack already includes a CDKMetadata resource
Stack name not specified, so defaulting to all available stacks: TestappStack
Reading existing template for stack TestappStack.
Need to perform AWS calls for account unknown-account, but no credentials found. Tried: default credentials.
Error: Need to perform AWS calls for account unknown-account, but no credentials found. Tried: default credentials.
    at CredentialsCache.getCredentials (D:\xxxxxxxxxxxxxx\AppData\Roaming\npm\node_modules\aws-cdk\lib\api\util\sdk.ts:209:11)
    at <anonymous>

[Sparkboxx]

CDK not using the --profile setting

Is it expected behaviour that when a profile is configured in cdk.json that cdk uses your [default] credential profile if you don't give it an explicit --profile ? Or should it be safe to assume that if the profile is set in the cdk.json that when running a cdk command it uses the configured profile?

The story
I forgot to include the --profile myProfile a bunch of times while creating my app and ended up creating infrastructure my [default] profile account. This of course is user error, but I think an error other people might make too.

In order to avoid the problem I now setup an empty [default] profile, so that if I forget to include --profile myProfile I get an error. (Which is probably a good thing for me to do anyway working with multiple profiles)

CDK is configured with:

{
  "app": "node bin/app.js",
  "profile": "myProfile"
}

[kadishmal]

I'm trying to deploy a CDK app from within a Lambda function. Now it complains with:

Need to perform AWS calls for account unknown-account, but no credentials found. Tried: default credentials.

Passing --role-arn doesn't seem to work. Why is CDK bound to ~/.aws/credentials and ~/.aws/config?

Lambda function itself already has a role that has all the permissions to deploy a CDK app. Is this even possible? The final resort is to duplicate CDK's cdk.js and remove the credential checker part which feels so unnecessary.

[mrgrain]

I have a CDK app which is deployed from a docker container inside an EC2 instance.

The EC2 instance has a role in the target account which does nothing but allow me to assume an other role.

I have a CDK plugin which handles assuming the role.

When I try to deploy via CDK, the app is loading the plugin, but is not requesting credentials from it. Instead CDK resolves and looks up "default credentials" for the account. Since the role is for the account, CDK moves on and subsequently fails as the instance role has no permissions.

Is there a way to tell CDK to not use this account, or better to just use my plugin?

AWS_EC2_METADATA_DISABLED won't work as the plugin is relying on metadata.

[kadishmal]

@mrgrain I went on with a different approach I described in this #2637 (comment). It might give you some ideas.

[mrgrain]

@kadishmal I found a solution for my issue. Since the problem came down to AWS CDK trying to use ec2 meta data credentials by default, we can disable that behaviour by setting --ec2creds false on the cli.

I guess what would be nice if that option is explicitly called out in the log. Something like

Looks like an EC2 instance. Trying ec2 meta data credentials (disable this behaviour with `--ec2creds false`).

[zzenonn]

I have two weird issues:

My config file is setup like this:

[default]
output = json
region = ap-southeast-1
role_arn = arn:aws:iam::123456789012:role/AdminRole
source_profile = default

[profile company]
region=ap-southeast-1
output=json
cli_follow_urlparam = false

[profile educate]
region=us-east-1
output=json

When I run cdk deploy,

My first issue is I get this error which uses a different region from my default (which is very strange).

My second issue is that the CDK also does not assume the role specified in the configuration.

User: arn:aws:iam::123456789012:user/zenon is not authorized to perform: cloudformation:GetTemplate on resource: arn:aws:cloudformation:us-east-2:123456789012:stack/hello-cdk-1/*

[mbonig]

Is there any verified way of leverage just the AWS_SECRET_ACCESS_KEY and AWS_ACCESS_KEY_ID (but no AWS_SESSION_TOKEN) environment variables?

[skinny85]

Is there any verified way of leverage just the AWS_SECRET_ACCESS_KEY and AWS_ACCESS_KEY_ID (but no AWS_SESSION_TOKEN) environment variables?

I believe if you're not using temporary credentials like assumeRole, but something like an IAM User, you don't need to set AWS_SESSION_TOKEN.

[kevinslin]

for mfa, I use aws-mfa to make things a bit more bearable. it writes short term credentials into your .credentials file and works with cdk!

[mbonig]

Is there any verified way of leverage just the AWS_SECRET_ACCESS_KEY and AWS_ACCESS_KEY_ID (but no AWS_SESSION_TOKEN) environment variables?

I believe if you're not using temporary credentials like assumeRole, but something like an IAM User, you don't need to set AWS_SESSION_TOKEN.

So, just to round out the issue... I have been trying to run cdk synth inside a Jenkins pipeline that was given temp credentials from the AWS Credentials Jenkins plugin. However, CDK couldn't find the env variable creds properly. So, I just write them to a file first and then point AWS_SHARED_CREDENTIALS_FILE at it and now things are working fine.

[jonnyyu]

1. using aws-cdk 1.3.0 on a EC2 AMI Linux 2 instance with role attached.
2. run 'aws configure' with secret/access=None, region=us-west-2
3. run 'cdk deploy myservice' failed with

Need to perform AWS calls for account XXXXXXXXXXX, but no credentials found. 

Detail logs:

Tried: default credentials.
Error: Need to perform AWS calls for account XXXXXXXXXXX, but no credentials found. Tried: default credentials.
    at CredentialsCache.getCredentials (/home/ec2-user/.nvm/versions/node/v12.7.0/lib/node_modules/aws-cdk/lib/api/util/sdk.ts:261:11)
    at processTicksAndRejections (internal/process/task_queues.js:85:5)
    at CredentialsCache.get (/home/ec2-user/.nvm/versions/node/v12.7.0/lib/node_modules/aws-cdk/lib/api/util/sdk.ts:223:25)
    at SDK.cloudFormation (/home/ec2-user/.nvm/versions/node/v12.7.0/lib/node_modules/aws-cdk/lib/api/util/sdk.ts:117:20)
    at CloudFormationDeploymentTarget.readCurrentTemplate (/home/ec2-user/.nvm/versions/node/v12.7.0/lib/node_modules/aws-cdk/lib/api/deployment-target.ts:52:17)
    at CdkToolkit.deploy (/home/ec2-user/.nvm/versions/node/v12.7.0/lib/node_modules/aws-cdk/lib/cdk-toolkit.ts:94:33)
    at main (/home/ec2-user/.nvm/versions/node/v12.7.0/lib/node_modules/aws-cdk/bin/cdk.ts:192:16)
    at initCommandLine (/home/ec2-user/.nvm/versions/node/v12.7.0/lib/node_modules/aws-cdk/bin/cdk.ts:150:9)

A workaround is to touch ~/.aws/credentials, then it can correctly retrieve credentials from EC2 metadata.
But AWS CLI doesn't require ~/.aws/credentials exist

[SteveHoggNZ]

@kadishmal I got CDK running in a Lambda. Setting the a HOME environment variable to /tmp for the Lambda allows create the credentials files and use the Lambda's role.

The CDK CLI also needs --output /tmp/cdk.out

[kadishmal]

@SteveHoggNZ just like that? Set the HOME env to /tmp and CDK will stop using the credentials? Can you paste some sample code?

[whilp]

A workaround is to touch ~/.aws/credentials, then it can correctly retrieve credentials from EC2 metadata.

This workaround may feel slightly less painful if you use the AWS_SHARED_CREDENTIALS_FILE environment variable.

export AWS_SHARED_CREDENTIALS_FILE=/tmp/aws-cdk-1656-workaround
touch $AWS_SHARED_CREDENTIALS_FILE

[aisamu]

aws creds exec cdk deploy

@julienlepine is this available on a future version of the cli?

[mateja82]

Not sure if this helps anyone, but in my organization we use AWS SSO, with over 90 AWS Accounts, with MFA, so it was impossible to manage CDK without AWS SSO support. I found a way to solve it, so till its officially relesed, you can use this, it works quite all right: MatsCloud blog - CDK with AWS SSO multi account multi profile

[drissamri]

Encountered this issue today as well on our CI server (GitLab) there is no credentials/config file, setting the ACCESS_KEY and SECRET_KEY works fine until you try to assume a role in another account (https://www.npmjs.com/package/cdk-assume-role-plugin). Also to reproduce this locally.

Creating anempty credentials/config file does not help sadly!

Could not load credentials from TemporaryCredentials: Missing credentials in config, if using AWS_CONFIG_FILE, set AWS_SDK_LOAD_CONFIG=1: 
Could not load credentials from SharedIniFileCredentials: ENOENT: no such file or directory, open '/root/.aws/credentials'

[drissamri]

After banging my head on this for a few days, finally got it working..

Use case

• GitLab CI (but Jenkins, Bitbucket, etc should be the same)
• No aws/credentials or aws/config file
• AWS_SECRET_ACCESS_KEY & AWS_ACCESS_KEY_ID set with a user that can assume roles on other accounts

Solution

• Assume cross account role and put in variable (KST)
• Create credentials file
• Set AWS_SHARED_CREDENTIALS_FILE to created credentials file
• Unset AWS_SECRET_ACCESS_KEY & AWS_ACCESS_KEY_ID variables which allowed me to do the assuming

    - KST=(`aws sts assume-role --role-arn "arn:aws:iam::$AWS_DEPLOY_ACCOUNT:role/$AWS_DEPLOY_ROLE" --role-session-name "$CI_JOB_ID-dev" --query '[Credentials.AccessKeyId,Credentials.SecretAccessKey,Credentials.SessionToken]' --output text`)
    - printf "[default]\naws_access_key_id=${KST[0]}\naws_secret_access_key=${KST[1]}\naws_session_token=${KST[2]}" > credentials
    - export AWS_SHARED_CREDENTIALS_FILE=credentials && unset AWS_ACCESS_KEY_ID && unset AWS_SECRET_ACCESS_KEY

Hope this won't be needed in the near future.. If theres an easier way, do let me know here or on Twitter @drissamri88

[robert-hanuschke]

that helped a lot, thanks @drissamri !
For those using CodeBuild, be sure to also export the KST variable to be usable in the following command.

[dhensen]

I'm having the same issue, normally I would not bump this as enough people are troubled by this, but I'm using the awsprocesscreds-saml to get access to a corporate account. My config might look like this:

[default]
region = eu-west-2

[profile mn-x01-dnp]
region = eu-central-1
credential_process=awsprocesscreds-saml -e https://sts.mn-services.nl/adfs/ls/IdpInitiatedSignOn.aspx?loginToRp=urn:amazon:webservices -u [email protected] -p adfs -a arn:aws:iam::111111111111:role/mn-developer

(I changed my emailaddress and my account id)
aws-cli is working perfectly.

[dtelaroli]

Tests with no success (1.70.0):

Using --server

cdk synth -i or 
cdk synth --ec2cred

Directly

aws-vault exec my-profile -- cdk synth

Results

Cannot retrieve value from context provider ssm 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 (not recommended for production stacks)
Subprocess exited with error 1

Configuring explicitly account and region I received another error:

ENAMETOOLONG: name too long, lstat '/Users/dtelaroli/vitrine/cdk/cdk.out/asset.cd1c5b327c1fa83b53cf74ac46abb1f897478a725cba6d1997e654e2fe04b0bf/cdk.out/asset.cd1c5b327c1fa8[...]

Downgrading to 1.59:

I'm lost!
Any workaround?

[hoegertn]

The screenshot looks like a dependency version mismatch. Remove your lockfile and node_modules folder and install again.

[dtelaroli]

@hoegertn You right, but solving it I get again:

/cdk.out/asset.901cce368a283e6ec621cec0a2fa44915487e0edac14bb928adb66d5d47f38c2/cdk.out/asset.901cce368a283e6ec621cec0a2fa44915487e0edac14bb928adb66d5d47f38c2/cdk.out/asset.901cce368a283e6ec621cec0a2fa44915487e0edac14bb928adb66d5d47f38c2/cdk.out/asset.901cce368a283e6ec621cec0a2fa44915487e0edac14bb928adb66d5d47f38c2/cdk.out/asset.901cce368a283e6ec621cec0a2fa44915487e0edac14bb928adb66d5d47f38c2/cdk.out/asset.901cce368a283e6ec621cec0a2fa44915487e0edac14bb928adb66d5d47f38c2/cdk.out/asset.901cce368a283e6ec621cec0a2fa44915487e0edac14bb928adb66d5d47f38c2/cdk.out/asset.901cce368a283e6ec621cec0a2fa44915487e0edac14bb928adb66d5d47f38c2/cdk.out/asset.901cce368a283e6ec621cec0a2fa44915487e0edac14bb928adb66d5d47f38c2/cdk.out/asset.3c401e72ea16f4d9e87e74ee10991f1bb706f7689a13c63210555ee59affb287'
Subprocess exited with error 1

[dtelaroli]

Never mind people, this problem is a bed configuration.
The problem now, it's just with aws-vault permission. It's bed configure account id, because I'm using multiple-accounts.

[usmanbinnaeem]

Hi, Hope You all are doing well, need little help, I have created my IAM user and configured every thing fine, but still getting this error, "Unable to resolve AWS account to use. It must be either configured when you define your CDK or through the environment" any body can help to know what I am doing wrong.

here is my .aws/config and .aws/credentials files
.aws/credentials :

[default]
aws_access_key_id=AKIAZGKxxxxxxxxxxx
aws_secret_access_key=aK83fP4v7Lmsly8Yxxxxxxxxxxxxx

.aws/config:

[default]
region=us-east-1

Regards: usman Naeem.

[rix0rrr]

This issue was originally intended as an announcement about differences between CDK CLI auth configuration and AWS CLI auth configuration.

It has morphed into a thread where everybody posts an error which they think might have something to do with authentication.

We will move the original content to the developer guide, and close this thread. If you're not sure if the behavior you're seeing is a bug, come and ask on Slack.

Otherwise, we will start using individual issues to start tracking individual bugs.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

[ebol2000]

In case anyone is running into this problem while trying to run the script from Octopus Deploy (using this feature: https://octopus.com/docs/deployments/custom-scripts/aws-cli-scripts) please note:

Do not use --profile. This seems to get you into this mess. After loosing days monkeying around with alternatives, someone on our team discovered by accident that if you leave off the --profile it just worked. After looking at the statement

Precedence of options

If you specify an option by using one of the environment variables described in this topic, it overrides any value loaded from a profile in the configuration file.

If you specify an option by using a parameter on the CLI command line, it overrides any value from either the corresponding environment variable or a profile in the configuration file.

from https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-envvars.html

I realized that Octopus was already setting the environment variables (scoped for session) in the script, and simply by removing the --profile, it worked. Specifically the PS1 script below worked for us

$packageVer = '#{Octopus.Action.Package.PackageVersion}'
Write-Host "packageVer: $packageVer"

Write-Host ""
Set-Location "{insert project path here }"
Write-Host "********************Running Synth********************"
npx cdk synth

Write-Host $"********************Running Deploy********************"
npx cdk deploy --require-approval never

[stepcheunghk]

After spending a couple hours on this authentication issue, I finally figured this out.

For everyone who has this issue, you may have a try with the following configurations.

What I have done before, it worked perfectly with aws-cli, but NOT CDK.

In ~/.aws/credentials,

[cn]
AWS_ACCESS_KEY_ID=<redacted>
AWS_SECRET_ACCESS_KEY=<redacted>

[global]
AWS_ACCESS_KEY_ID=<redacted>
AWS_SECRET_ACCESS_KEY=<redacted>

[global-dev]
role_arn = arn:aws:iam::<AWS_ACCOUNT_ID>:role/<ASSUME_ROLE_CROSS_ACCOUNT>
source_profile = global

When I tried to bootstrap, npx aws-cdk bootstrap --profile global-dev, CDK returned following error.
Need to perform AWS calls for account <AWS_ACCOUNT_ID>, but no credentials have been configured

It seemed CDK cannot read my credentials and profiles.

After tons of attempts, it finally worked with the following configurations.

In ~/.aws/credentials,

[cn]
aws_access_key_id = <redacted>
aws_secret_access_key = <redacted>

[global]
aws_access_key_id = <redacted>
aws_secret_access_key = <redacted>

In ~/.aws/config,

[profile global-dev]
role_arn = arn:aws:iam::<AWS_ACCOUNT_ID>:role/<ASSUME_ROLE_CROSS_ACCOUNT>
source_profile = global

cdk version: 2.21.0 (build 3f74a81)
aws-cli version: 2.4.7

[scottwn]

@rix0rrr the Slack link in this comment is dead

[kizggerg]

@kadishmal I found a solution for my issue. Since the problem came down to AWS CDK trying to use ec2 meta data credentials by default, we can disable that behaviour by setting --ec2creds false on the cli.

I guess what would be nice if that option is explicitly called out in the log. Something like

Looks like an EC2 instance. Trying ec2 meta data credentials (disable this behaviour with `--ec2creds false`).

Building on this solution, for anyone who came across this issue when trying to run aws-vault in server mode (aws-vault exec -s <profile>), passing --ec2creds true into your cdk command seems to get CDK to recognize your vault's sts server to obtain its credentials.