-
Notifications
You must be signed in to change notification settings - Fork 4k
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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(cli): source_profile + credential_process not respected #20956
Comments
Please run the command again with The contents of |
Click to expand
The |
Based on that, there are two mysterious things.
|
Unfortunately this is a bug we'll have to fix in AWS SDK JS v2. |
@rix0rrr Any update on this? Was a bug filed against the JS SDK? |
ping @rix0rrr |
@rix0rrr @TheRealAmazonKendra When will this bug be fixed? |
@rix0rrr in my case it happens when |
I think I have the same issue, setup without SSO.
No ~/.aws/credentials file; ~/.aws/config:
CDK is not picking up the right profile, not asking for mfa. All good with aws cli. |
Can confirm this issue still exists. I'm trying to avoid having credentials in clear-text and I'm using Sample credentials-file with both hardcoded credentials and
Note: Hardcoded credentials are not in use in above due to Testing of CLI with:
...yields the exact same result with either hardcoded credentials or with credential_process enabled. The result is a correct list of available buckets on the account. This is as expected. Testing of CDK with:
...works as expected with hardcoded credentials. It returns a proper diff for the stack and is as expected. But with
... it should return the exact same result in both scenarios... A fix of the bug is preferred, but if this isn't happening then if anyone has a workaround I'll be happy to hear it(and likely others hitting the same issue in the future)... System info used for the above tests: |
Since this functionality is provided by the underlying SDK that we use, we are bound by it. We have plans to migrate CDK to AWS SDK v3. After that, we will re-evalutate this issue. |
Our credential chain is defined here (there's more below but none of those are set in these use cases so we can pretend they don't exist for the purposes of this explanation). So, we're basically checking the following sources in the following order:
Environment Credentials are not set so that link in the credential chain fails and it moves on to the next source. In the AWS SDK v2, and our patched version that is based off of it, only SSO Credentials are not set so that link in the credential chain fails and it moves on to the next source. ProcessCredentials does support The credential chain provided by the AWS SDK v3 does support this setup so this issue should be resolved when we merge and release #31702. |
This PR updates the CDK CLI to use the AWS SDK V3 instead of V2. ### Manual Test Cases for Authorization All tests were run verbosely so that I could manually check the credentials being used from the CLI output. - [x] No credentials setup and no default profile fails as expected (established to ensure nothing was unintentionally setup) - [x] Explicitly provided profile sourced from config file, tested with both `--profile` and `AWS_PROFILE` - [x] `aws_access_key_id` and `aws_secret_access_key` - [x] `aws_access_key_id` and `aws_secret_access_key` and `region` - [x] `source_profile` and `role_arn` that points to another profile with `aws_access_key_id` and `aws_secret_access_key` in both config and credentials - [x] `source_profile` and `role_arn` that points to Environment - [x] `source_profile` that and `role_arn` that points to SSO profile in both config and credentials - [x] SSO both using all fields in `[profile]` and split between `[sso-session]` and `[profile]` - [x] `credential_source` is Environment - [x] `credential_process` - [x] Explicitly provided profile sourced from credentials file - [x] `aws_access_key_id` and `aws_secret_access_key` - [x] `aws_access_key_id` and `aws_secret_access_key` and `region` - [x] `source_profile` and `role_arn` that points to another profile with `aws_access_key_id` and `aws_secret_access_key` in both config and credentials - [x] `source_profile` and `role_arn` that points to Environment - [x] `source_profile` that and `role_arn` that points to SSO profile in both config and credentials - [x] `credential_source` is Environment - [x] `credential_source` is EcsContainer (integ tests in CodeBuild) - [x] `credential_process` - [x] Default profile (in both config file and credentials file) - [x] `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` environment variables set (cleared after test) - [x] `AMAZON_ACCESS_KEY_ID` and `AMAZON_SECRET_ACCESS_KEY` environment variables set (cleared after test) - [x] `aws_access_key_id` and `aws_secret_access_key` - [x] `aws_access_key_id` and `aws_secret_access_key` and `region` - [x] `source_profile` and `role_arn` that points to a profile with `aws_access_key_id` and `aws_secret_access_key` - [x] `source_profile` and `role_arn` that points to Environment (this will use `fromEnv` prior to getting to looking for `source_profile` in the Ini file) - [x] SSO profile is setup as default - [x] `credential_process` Closes #25870, #26292, #20956, #24744, #27265, 20896. ### Reason for this change The AWS SDK V2 is now in maintenance mode. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license* --------- Co-authored-by: Otavio Macedo <[email protected]> Co-authored-by: Rico Huijbers <[email protected]>
This PR updates the CDK CLI to use the AWS SDK V3 instead of V2. ### Manual Test Cases for Authorization All tests were run verbosely so that I could manually check the credentials being used from the CLI output. - [x] No credentials setup and no default profile fails as expected (established to ensure nothing was unintentionally setup) - [x] Explicitly provided profile sourced from config file, tested with both `--profile` and `AWS_PROFILE` - [x] `aws_access_key_id` and `aws_secret_access_key` - [x] `aws_access_key_id` and `aws_secret_access_key` and `region` - [x] `source_profile` and `role_arn` that points to another profile with `aws_access_key_id` and `aws_secret_access_key` in both config and credentials - [x] `source_profile` and `role_arn` that points to Environment - [x] `source_profile` that and `role_arn` that points to SSO profile in both config and credentials - [x] SSO both using all fields in `[profile]` and split between `[sso-session]` and `[profile]` - [x] `credential_source` is Environment - [x] `credential_process` - [x] Explicitly provided profile sourced from credentials file - [x] `aws_access_key_id` and `aws_secret_access_key` - [x] `aws_access_key_id` and `aws_secret_access_key` and `region` - [x] `source_profile` and `role_arn` that points to another profile with `aws_access_key_id` and `aws_secret_access_key` in both config and credentials - [x] `source_profile` and `role_arn` that points to Environment - [x] `source_profile` that and `role_arn` that points to SSO profile in both config and credentials - [x] `credential_source` is Environment - [x] `credential_source` is EcsContainer (integ tests in CodeBuild) - [x] `credential_process` - [x] Default profile (in both config file and credentials file) - [x] `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` environment variables set (cleared after test) - [x] `AMAZON_ACCESS_KEY_ID` and `AMAZON_SECRET_ACCESS_KEY` environment variables set (cleared after test) - [x] `aws_access_key_id` and `aws_secret_access_key` - [x] `aws_access_key_id` and `aws_secret_access_key` and `region` - [x] `source_profile` and `role_arn` that points to a profile with `aws_access_key_id` and `aws_secret_access_key` - [x] `source_profile` and `role_arn` that points to Environment (this will use `fromEnv` prior to getting to looking for `source_profile` in the Ini file) - [x] SSO profile is setup as default - [x] `credential_process` Closes #25870, #26292, #20956, #24744, #27265, 20896. ### Reason for this change The AWS SDK V2 is now in maintenance mode. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license* --------- Co-authored-by: Otavio Macedo <[email protected]> Co-authored-by: Rico Huijbers <[email protected]> (cherry picked from commit 5bc0662)
Comments on closed issues and PRs are hard for our team to see. |
Describe the bug
We configured our profile like so:
The AWS CLI works perfectly fine with this setup. However, CDK throws a nonsense exception.
Expected Behavior
It should work without issue.
Current Behavior
See above.
Reproduction Steps
See above.
Possible Solution
No response
Additional Information/Context
No response
CDK CLI Version
2.28.0 (build ba233f0)
Framework Version
No response
Node.js Version
v16.15.1
OS
Alpine 3.16
Language
Python
Language Version
3.10.5
Other information
No response
The text was updated successfully, but these errors were encountered: