cli: CDK does not seem to be compatible with config generated from aws configure sso
#27265
Comments
marcusirgens
added
bug
marcusirgens
changed the title
aws configure ssoaws configure sso
|
Just want to say thank you, after a long struggle with why Further notes on the topic which may be helpful, I do not have any Additionally I found out that if I use the flag |
|
There's a handful of possible issues here.
|
indrora
added
p2
response-requested
|
@indrora were you able to reproduce this? |
@indrora Do you mean with CDK? $ AWS_PROFILE=my-org-dev cdk bootstrap
# Output:
# ⏳ Bootstrapping environment aws://123456789012/eu-north-1...
# ❌ Environment aws://123456789012/eu-north-1 failed bootstrapping: Error: Need to perform AWS calls for account 123456789012, but no credentials have been configured
# at SdkProvider.forEnvironment (/Users/buggs/node/n/lib/node_modules/aws-cdk/lib/index.js:367:13075)
# at async _BootstrapStack.lookup (/Users/buggs/node/n/lib/node_modules/aws-cdk/lib/index.js:454:20535)
# at async Bootstrapper.modernBootstrap (/Users/buggs/node/n/lib/node_modules/aws-cdk/lib/index.js:455:1084)
# at async /Users/buggs/node/n/lib/node_modules/aws-cdk/lib/index.js:459:2104
# at async Promise.all (index 0)
# at async CdkToolkit.bootstrap (/Users/buggs/node/n/lib/node_modules/aws-cdk/lib/index.js:459:1949)
# at async exec4 (/Users/buggs/node/n/lib/node_modules/aws-cdk/lib/index.js:512:53102)
#
# Need to perform AWS calls for account 123456789012, but no credentials have been configuredWithout $ AWS_PROFILE=my-org-dev cdk bootstrap
# Output:
# ⏳ Bootstrapping environment aws://123456789012/eu-north-1...
#Trusted accounts for deployment: (none)
#Trusted accounts for lookup: (none)
#Using default execution policy of 'arn:aws:iam::aws:policy/AdministratorAccess'. Pass '--cloudformation-execution-policies' to customize.
#
# ✨ hotswap deployment skipped - no changes were detected (use --force to override)
#
# ✅ Environment aws://123456789012/eu-north-1 bootstrapped (no changes).
Yes, as far as I can tell (the bottom part is a script that assumes all roles with CDK in their names): $ AWS_PROFILE=my-org-dev aws sts get-caller-identity --output json
# Output:
# {
# "UserId": "ARARANDOMREDACTED:buggs@iterate.no",
# "Account": "123456789012",
# "Arn": "arn:aws:sts::123456789012:assumed-role/AWSReservedSSO_AdministratorAccess_randomsuffix/buggs@iterate.no"
# }
# This script lists all roles with "cdk" in the name, and runs aws sts assume-role for those, and prints the assumed role.
$ AWS_PROFILE=my-org-dev aws iam list-roles --output json | \
jq '.Roles[] | .Arn | select(. | ascii_downcase | contains("cdk")) | .' --raw-output0 | \
AWS_PROFILE=my-org-dev xargs -0n1 -I'{}' aws sts assume-role --role-arn '{}' --role-session-name 'demo-github' --output json | \
jq '.AssumedRoleUser.Arn'
# Output:
# # An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:sts::123456789012:assumed-role/AWSReservedSSO_AdministratorAccess_9291ebc2c934fe48/buggs@iterate.no is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::123456789012:role/cdk-hnb659fds-cfn-exec-role-123456789012-eu-central-1
#
# An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:sts::123456789012:assumed-role/AWSReservedSSO_AdministratorAccess_9291ebc2c934fe48/buggs@iterate.no is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::123456789012:role/cdk-hnb659fds-cfn-exec-role-123456789012-eu-north-1
#
# An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:sts::123456789012:assumed-role/AWSReservedSSO_AdministratorAccess_9291ebc2c934fe48/buggs@iterate.no is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::123456789012:role/cdk-hnb659fds-cfn-exec-role-123456789012-us-east-1
# "arn:aws:sts::123456789012:assumed-role/cdk-hnb659fds-deploy-role-123456789012-eu-central-1/demo-github"
# "arn:aws:sts::123456789012:assumed-role/cdk-hnb659fds-deploy-role-123456789012-eu-north-1/demo-github"
# "arn:aws:sts::123456789012:assumed-role/cdk-hnb659fds-deploy-role-123456789012-us-east-1/demo-github"
# "arn:aws:sts::123456789012:assumed-role/cdk-hnb659fds-file-publishing-role-123456789012-eu-central-1/demo-github"
# "arn:aws:sts::123456789012:assumed-role/cdk-hnb659fds-file-publishing-role-123456789012-eu-north-1/demo-github"
# "arn:aws:sts::123456789012:assumed-role/cdk-hnb659fds-file-publishing-role-123456789012-us-east-1/demo-github"
# "arn:aws:sts::123456789012:assumed-role/cdk-hnb659fds-image-publishing-role-123456789012-eu-central-1/demo-github"
# "arn:aws:sts::123456789012:assumed-role/cdk-hnb659fds-image-publishing-role-123456789012-eu-north-1/demo-github"
# "arn:aws:sts::123456789012:assumed-role/cdk-hnb659fds-image-publishing-role-123456789012-us-east-1/demo-github"
# "arn:aws:sts::123456789012:assumed-role/cdk-hnb659fds-lookup-role-123456789012-eu-central-1/demo-github"
# "arn:aws:sts::123456789012:assumed-role/cdk-hnb659fds-lookup-role-123456789012-eu-north-1/demo-github"
# "arn:aws:sts::123456789012:assumed-role/cdk-hnb659fds-lookup-role-123456789012-us-east-1/demo-github"The three roles I cannot assume have the following trust policies: {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "cloudformation.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
} |
|
To be 100 % clear: With the following config, I can perform [profile my-org-dev]
sso_session = Admin in My Org
sso_account_id = <REDACTED>
sso_role_name = AdministratorAccess
region = eu-north-1
[sso-session 'Admin in My Org']
sso_start_url = https://<REDACTED>.awsapps.com/start#
sso_region = eu-central-1
sso_registration_scopes = sso:account:accessThis is my entire I've also removed files from
When removing the [profile my-org-dev]
# sso_session = Admin in My Org
sso_account_id = <REDACTED>
sso_role_name = AdministratorAccess
region = eu-north-1
sso_start_url = https://<REDACTED>.awsapps.com/start#
sso_region = eu-central-1
# [sso-session 'Admin in My Org']
# sso_registration_scopes = sso:account:accessThe output of |
|
@peterwoodworth I don't have an account set up with SSO right now, so I wasn't able to do a proper repro. Some notes, however: Discussion #21316 might be of interest: If you're behind an SSL crusher like ZScaler so that Corporate IT can do SSL inspection, the AWS client the CDK uses just wanders into the sun because it doesn't support the custom CA bundle. I don't know if that's the case here, but it's a plausible lead. I have found numerous issues with AWS SSO and CDK discussed by other customers(1) and in our own ticket tracker (#23520), and found one customer who found a... While not great workaround, a workaround(2). There is a known suggestion on re:post to just do it the hard way(3) for some applications. PR #19454 was supposed to fix this need back in 2022, but I don't know how well that's worked in the long run. There was also work in #23702 to handle an edge case in SSO profiles. |
github-actions
bot
removed
the
response-requested
|
I had this issue and it turned out I had some old entries in my Removing all of those (and leaving the newer |
|
same issues for me, please fix. |
Clarifying that this is not the issue I've raised here, nor the fix for it - this issue seems to be that CDK does not understand the SSO session field. The "workaround" seems to be to not enter anything when prompted for while running |
|
Not one of the solutions proposed work for me when trying to quickly deploy CDK stacks into multiple accounts. Whichever one I configure and use, will cause the other to error out with the "need to perform for A, but current creds are for B". The unacceptable work-around involves a rigmarole of cleaning/purging of credential and auth caches. Then switch to the other, deploy, and of course get the same error when trying to use the other account, except this time with "need to perform for B, but current creds are for A". Somewhat ironically, this used to work without issues when using different SSO providers (from Okta to Jumpcloud). |
|
There's a chance this old issue is related: #24744 |
|
To add another data point: I'm also using Sounds like a bug in the CLI that sometimes randomly fails to return SSO credentials to CDK. |
The CLI does not provide credentials to the CDK, not directly. Running The issue is probably somewhere in the JavaScript SDK. As I understand it, different parts of the CDK use v2 and v3 of the JS SDK, and Identity Center support in v2 was very late in coming, so I wouldn't be surprised if it also has issues with the change to session-based profiles and refresh tokens. Potentially this: aws/aws-sdk-js#4441 |
|
What can I do to help diagnose the source of the bug? Is there a debug log I can turn on? I could post the logs when the problem reproduces itself. |
|
After much messing about, I found out that I could get it to work by removing any spaces in my sso-session name and removing the single quotes around the sso-session name (not certain if this was necessary or not) So Could be changed to: Seems like other config readers have run into this too (ruby, go). If I'm following the code right here the correct fix would need to be in https://github.com/smithy-lang/smithy-typescript. Though it seems like the aws cli is actually generating configuration that violates the spec. It should probably prevent using sso session names with spaces in them.
|
|
I'm having this issue even without spaces or quotes in my session name. |
This works to me |
|
I was seeing something similar using bootstrap and the trick for me was to have an "SSO session name" without spaces. Was able to enter a value for it though |
|
I suspect this should have been fixed when we upgraded our AWS SDK to v2.1691.0 because of aws/aws-sdk-js#4443. Can you please upgrade your cdk cli to our most recent version and see if this is still impacting you? If it is, you should see a resolution when #31702 is merged. |
Describe the bug
When setting up a project from scratch with SSO credentials, CDK fails to authorize.
The steps I'm following are as follows:
aws configure ssoaws sso login --profile my-org-devbin/{stack}.tsAWS_PROFILE=my-org-dev cdk deployI receive the following error message:
Expected Behavior
I expect CDK to be compatible with credentials generated with
aws configure ssoandaws sso login.Current Behavior
When deploying, I get the following output:
Getting my current session details:
This is what my
AWS_CONFIG_FILElooks like:Reproduction Steps
I install
aws-cdkand check the version:I back up my
AWS_CONFIG_FILEand delete the existing file:I go to the SSO start URL for my organization, https://acme.awsapps.com/start. Under the account I want to use, I click Command line or programmatic access, where I read the following instructions:
In my shell, I configure the AWS CLI using
aws configure sso:In my shell, I verify that I have a valid session:
I initialize a CDK project in a new directory:
I attempt to deploy the stack, which fails because CDK cannot determine which account to use:
I follow the instructions in
bin/{the application name}.ts, as indicated in the output from the failingcdk deploy, and add:I attempt to deploy the stack, which fails because CDK cannot find the credentials:
If I remove the
sso-sessionblock and move some settings up to themy-org-devprofile, I am able to deploy:$AWS_CONFIG_FILE:Possible Solution
No response
Additional Information/Context
No response
CDK CLI Version
2.97.0 (build d7cf3be)
Framework Version
No response
Node.js Version
18.14.0
OS
macOS 13.4 (22F66)
Language
Typescript
Language Version
~5.2.2
Other information
Similar issues
This seems to be somewhat related to a couple of other issues.
aws --profile my-org-dev sts get-caller-identitysucceeds, butnpx cdk diff --profile my-org-devfails like above). As far as I can tell, my$AWS_CONFIG_FILEhas the same properties.The text was updated successfully, but these errors were encountered: