Skip to content
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

Strange behavior with sts client #4199

Closed
anoopnarang opened this issue Jul 18, 2023 · 4 comments
Closed

Strange behavior with sts client #4199

anoopnarang opened this issue Jul 18, 2023 · 4 comments
Assignees
Labels
bug This issue is a bug. closing-soon This issue will close in 4 days unless further comments are made. response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 10 days.

Comments

@anoopnarang
Copy link

anoopnarang commented Jul 18, 2023

Describe the bug

I am using sts client to assume roles in various accounts ( account id + role on demand ) to execute some operations. The setup is like, the sts client is created once in beginning and role assumption is done multiple times based on a message from queue or a http request.
In a long running setting, lets say external id gets changed and we recieve new external id from user, assumeRole simply gives UnAuthorized exception. On some testing, I found it takes a several minutes to address this external id change in trust relationship.

While in a short setting, where sts client gets created again and again, changes in external id takes few seconds to be addressed.

What might be reason for this behavior ?

Expected Behavior

StsClient should address changes in external id in same amount of time whether its long running or recreated with every request.

Current Behavior

stsClient in long running setting addresses the change in external id much slower than stsClient which is freshly created.

Reproduction Steps

public static void main(String[] args) {
        StsClient stsClient = StsClient.builder().credentialsProvider(ProfileCredentialsProvider.create("SomeProfile")).build();
        stsClient.assumeRole(AssumeRoleRequest.builder().roleArn("arn:aws:iam::123456789000:role/SomeRole").externalId("customExternalId").roleSessionName("Test").build());
        stsClient.close();
    }

Start with a role you can successfully assume from your local.
In above code, put a debug point on line number 2. Once there, modify the external id in trust relationship of the role in aws console. Evaluate the expression in debugger, it will give Unauthorized for lot of minutes.
If we simply restart the code, it will assume right away.

Possible Solution

No response

Additional Information/Context

No response

AWS Java SDK version used

2.20.103

JDK version used

openjdk 11.0.18 2023-01-17 OpenJDK Runtime Environment Temurin-11.0.18+10 (build 11.0.18+10) OpenJDK 64-Bit Server VM Temurin-11.0.18+10 (build 11.0.18+10, mixed mode)

Operating System and version

mac os 13.3.1

@anoopnarang anoopnarang added bug This issue is a bug. needs-triage This issue or PR still needs to be triaged. labels Jul 18, 2023
@debora-ito debora-ito self-assigned this Aug 7, 2023
@debora-ito
Copy link
Member

@anoopnarang every session created by an AssumeRole call has an expiration date. The STS client will try to refresh the credentials only when the session is close to the expiration date.

If I understood correctly, in you case the externalId is being changed in the middle of the session. Since it's not close enough to the session's expiration date, the STS client will continue to use the old credentials and get Unauthorized until it's time to refresh them.

This doesn't happen when you create a new STS client with every request because it is probably picking up the new externalId right away.

Does it make sense?

@debora-ito debora-ito added response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 10 days. and removed needs-triage This issue or PR still needs to be triaged. labels Aug 7, 2023
@github-actions
Copy link

It looks like this issue has not been active for more than five days. In the absence of more information, we will be closing this issue soon. If you find that this is still a problem, please add a comment to prevent automatic closure, or if the issue is already closed please feel free to reopen it.

@github-actions github-actions bot added the closing-soon This issue will close in 4 days unless further comments are made. label Aug 12, 2023
@anoopnarang
Copy link
Author

@debora-ito Thanks, that makes sense. So I guess for usecases where new roles or roles with new external ids have to be assumed regularly, it would be better to create new client for each request.

@github-actions
Copy link

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This issue is a bug. closing-soon This issue will close in 4 days unless further comments are made. response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 10 days.
Projects
None yet
Development

No branches or pull requests

2 participants