-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
feat: sdkv3 upgrade for CLI (wip) #31624
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.
A comment requesting an exemption should contain the text Exemption Request
. Additionally, if clarification is needed add Clarification Request
to a comment.
78798f5
to
fd34c5c
Compare
// ECS and EKS instances also run on EC2 boxes but the creds represent something different. | ||
// Same behavior as upstream code. | ||
sources.push(() => new AWS.EC2MetadataCredentials()); | ||
return fromIni({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently, SSO has precedence over process, but in fromIni
, it's the other way around. It's highly unlikely that someone mistakenly configures both, but I think we should keep the current behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, fromIni actually covers SSO in v3. It didn't work with V2, which is why we manually put it ahead of Ini.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, but we are changing the behavior now. If someone has both credential_process
and sso_*
set in their config file, the current version of the CLI will use the SSO credentials. With this change, after they upgrade, the CLI will start using the process credentials. Maybe this is ok, but but we need at least to document this somewhere.
return shouldPrioritizeEnv() | ||
? createCredentialChain(fromEnv(), nodeProviderChain).expireAfter(60 * 60_000) | ||
: nodeProviderChain; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[feedback on readability] when I was reviewing this, I found it a bit hard to follow how the env variables fit into the chain. It's surprising to see a method whose name starts with "should" that modifies environment variables, that then gets picked up by fromEnv()
(or not).
I suggest we implement our own provider that reads from both AWS_*
and AMAZON_*
sets of variables. And this provider is always put at the beginning of the chain. Up to you.
try { | ||
await sdk.forceCredentialRetrieval(); | ||
// Force retrieval here |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can remove this whole try-catch now, can't we?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. Removing it.
config: { | ||
'profile ecs': { role_arn: 'arn:aws:iam::12356789012:role/Assumable', credential_source: 'EcsContainer', $account: '22222' }, | ||
// GIVEN | ||
const calls = jest.spyOn(console, 'debug'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't we be using the mocked metadata service?
@@ -35,15 +36,16 @@ interface AssumedRole { | |||
* Instead, we want to validate how we're setting up credentials for the | |||
* SDK, so we pretend to be the STS server and have an in-memory database | |||
* of users and roles. | |||
* | |||
* With the v3 upgrade, this is only now half way being used as |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
being used as?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I died half way though writing this comment. There is no way of knowing the ending.
But also, the "as" is that the mock sdk client made some of it unnecessary. I'll fix this comment to clarify.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of deleting these tests, can't we keep them and use a mocked STS and a mocked token file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know why it's outdated, but the question still applies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason I deleted these instead of trying to rewrite them is that previously we wrote our own functionality for whether or not to call these, now we're just using the credential provider that the sdk provides so we'd essentially be unit testing their code, not ours.
|
||
const env = { | ||
account: '123456789012', | ||
region: 'us-east-1', | ||
name: 'mock', | ||
}; | ||
|
||
const templateBody = toYAML(deserializeStructure(serializeStructure(legacyBootstrapTemplate({}), true))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the difference between this and:
const templateBody = serializeStructure(legacyBootstrapTemplate({}), false);
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is silly looking but unfortunately necessary. If we only serialize it, the template body isn't formatted correctly due to the escape characters that get added in. If we skip the deserialization/serialization part and just do toYAML, we get the same output.
fd34c5c
to
54a35cf
Compare
54a35cf
to
8f7b25c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should also add some CLI integration tests for the credential loading scenarios.
66ed30f
to
723afa7
Compare
723afa7
to
f56fe7f
Compare
…ns (#31658) #31624 is too big so I'm splitting out the parts that I can without causing type conflicts. This upgrades all sdk v3 versions to the most recent version used in every region by lambda's node18 and node20 runtime bundle. Closes #<issue number here>. ### Reason for this change ### Description of changes ### Description of how you validated changes ### Checklist - [ ] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md) ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
f56fe7f
to
4acc721
Compare
16ffad3
to
714b314
Compare
714b314
to
de3c43d
Compare
de3c43d
to
9b9c312
Compare
9b9c312
to
c36eb47
Compare
This is succeeding in our build pipeline but not in the PR Build. What in the world is going on. |
e46a6ca
to
3bb1c21
Compare
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
➡️ PR build request submitted to A maintainer must now check the pipeline and add the |
Working on it! |
The pull request linter fails with the following errors:
PRs must pass status checks before we can provide a meaningful review. If you would like to request an exemption from the status checks or clarification on feedback, please leave a comment on this PR containing |
Comments on closed issues and PRs are hard for our team to see. |
Issue # (if applicable)
Closes #.
Reason for this change
Description of changes
Description of how you validated changes
Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license