-
Notifications
You must be signed in to change notification settings - Fork 864
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: Support account ID based endpoints #3718
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.
I know I'm not one of the reviewers, but I started looking earlier today and had some comments I don't want to lose.
Also, I don't quite understand all the code removal in sdk/src/Core/Amazon.Runtime/CredentialManagement/Internal/CredentialProfileTypeDetector.cs
(even after reading the PR description, it doesn't look that would have to be completed at the same time as account-ID based endpoints)
sdk/src/Core/Amazon.Runtime/Credentials/AssumeRoleWithWebIdentityCredentials.cs
Outdated
Show resolved
Hide resolved
sdk/src/Core/Amazon.Runtime/Credentials/AssumeRoleAWSCredentials.cs
Outdated
Show resolved
Hide resolved
sdk/src/Core/Amazon.Runtime/CredentialManagement/AWSCredentialsFactory.cs
Outdated
Show resolved
Hide resolved
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.
Is this file needed? I assume the tests above are hand-written, right? (If that's the case, I'd prefer not including the JSON from the SEP 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.
It isn't needed since it's actually not being read from but I like having it here as reference so someone can know where the tests came from. I also found some mistakes in the SEP's test cases so I pasted the correct version here. (I intend to raise a CR to the sep repo with the fixes).
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.
That's interesting, you should create the SEP CR as soon you can.
We should be confident the issues are with the test cases and not our implementation (not to mention other SDKs have already released support for this feature).
Edit: By as soon as you can I mean before merging this PR even.
generator/.DevConfigs/8a48524d-da8b-4c04-b57e-ad196a51debb.json
Outdated
Show resolved
Hide resolved
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.
With the rework of CredentialProfileTypeDetector
how confident do you feel with the existing test coverage and your testing? I like simplifying the logic but there is a lot of specific credential profile configuration I want to be sure we are breaking.
/// </summary> | ||
/// <param name="accessKey"></param> | ||
/// <param name="secretKey"></param> | ||
/// <param name="accountId"></param> |
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.
Lets add some descriptions for this parameters. I think in the past access key and secret key were obvious but account id not so much, particular what it is used for. Also if there are format requirements like the account id with no hyphens we should call that out. Once add comments for the parameters update the other constructor with the docs for access key and secret key.
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.
done
} | ||
|
||
public AssumeRoleImmutableCredentials(string awsAccessKeyId, string awsSecretAccessKey, string token, DateTime expiration, string accountId) : this (awsAccessKeyId, awsSecretAccessKey, token, expiration) |
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.
Constructor needs docs. For account be sure to add any formatting requirements like no hyphens.
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.
done
{ | ||
if (string.IsNullOrEmpty(token)) throw new ArgumentNullException(nameof(token)); | ||
Expiration = expiration; | ||
AccountId = accountId; |
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.
You are passing accountId
to the base constructor so setting this again here does not seem necessary.
sdk/src/Core/Amazon.Runtime/Credentials/ImmutableCredentials.cs
Outdated
Show resolved
Hide resolved
That was added as part of my work for service-specific endpoints and we have extensive test coverage that was added when I did that work. The tests here. I've always wanted to clean this class up b/c I realized only after I did that work that I should've added them to |
aed93cf
to
8fcde17
Compare
Description
Adds support for Account ID based endpoints. For most assume role operations, the account Id will be taken from the assumed role arn. For SSO we take the accountID from the request. Most static credentials were updated to include accountId as a value in their constructors in a backwards compatible way.
NOTE One other thing I did as part of this is move
Services
andEndpointUrl
toCredentialProfile
and away fromCredentialProfileOptions
. This is because these aren't being used to create unique credential types. It was causing theCredentialProfileType
enum to get exponentially larger, making us have to account for all the combinations of EndpointUrl and Services. This also meant that I removed a bunch ofCredentialProfileType
s. I figured this was safe to do because it is V4 and this is where we can make breaking changes. Without this change, any addition toCredentialProfileOptions
would make theCredentialProfileType
enum grow even larger which i thought is unsustainable.Motivation and Context
Testing
DRY_RUN-2958ec6b-8cf7-417d-8454-5283d4caa519
PS dry run passed
Screenshots (if appropriate)
Types of changes
Checklist
License