-
Notifications
You must be signed in to change notification settings - Fork 4.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
No credential caching when using AWS AssumeRole #37787
Labels
bug
Filebeat
Filebeat
libbeat
Metricbeat
Metricbeat
needs_team
Indicates that the issue/PR needs a Team:* label
Comments
botelastic
bot
added
needs_team
Indicates that the issue/PR needs a Team:* label
labels
Jan 30, 2024
This issue doesn't have a |
1 similar comment
This issue doesn't have a |
andrewkroh
added a commit
to andrewkroh/beats
that referenced
this issue
Jan 30, 2024
Add caching for AWS AssumeRole session credentials are not requested for every single request. Sessions are valid for 15m by default but without caching that did not matter. This will speed up requests and stop users from hitting rate-limiting issues with the STS (session token service). Fixes elastic#37787
8 tasks
Proposed change: #37788 |
andrewkroh
added a commit
that referenced
this issue
Jan 31, 2024
Add caching so that AWS `AssumeRole` session credentials are not requested for every single request. Sessions are valid for 15m by default but without caching that does not matter. This will speed up requests for users of `role_arn` by removing the overhead of most STS (session token service) calls and stop users from hitting rate-limiting issues with the STS. Fixes #37787
mergify bot
pushed a commit
that referenced
this issue
Jan 31, 2024
Add caching so that AWS `AssumeRole` session credentials are not requested for every single request. Sessions are valid for 15m by default but without caching that does not matter. This will speed up requests for users of `role_arn` by removing the overhead of most STS (session token service) calls and stop users from hitting rate-limiting issues with the STS. Fixes #37787 (cherry picked from commit a6e5b04)
mergify bot
pushed a commit
that referenced
this issue
Jan 31, 2024
Add caching so that AWS `AssumeRole` session credentials are not requested for every single request. Sessions are valid for 15m by default but without caching that does not matter. This will speed up requests for users of `role_arn` by removing the overhead of most STS (session token service) calls and stop users from hitting rate-limiting issues with the STS. Fixes #37787 (cherry picked from commit a6e5b04) # Conflicts: # x-pack/libbeat/common/aws/credentials.go # x-pack/libbeat/docs/aws-credentials-config.asciidoc
andrewkroh
added a commit
that referenced
this issue
Jan 31, 2024
Add caching so that AWS `AssumeRole` session credentials are not requested for every single request. Sessions are valid for 15m by default but without caching that does not matter. This will speed up requests for users of `role_arn` by removing the overhead of most STS (session token service) calls and stop users from hitting rate-limiting issues with the STS. Fixes #37787
andrewkroh
added a commit
that referenced
this issue
Jan 31, 2024
…ole sessions (#37808) Add caching so that AWS `AssumeRole` session credentials are not requested for every single request. Sessions are valid for 15m by default but without caching that does not matter. This will speed up requests for users of `role_arn` by removing the overhead of most STS (session token service) calls and stop users from hitting rate-limiting issues with the STS. Fixes #37787 (cherry picked from commit a6e5b04) --------- Co-authored-by: Andrew Kroh <andrew.kroh@elastic.co>
Scholar-Li
pushed a commit
to Scholar-Li/beats
that referenced
this issue
Feb 5, 2024
) Add caching so that AWS `AssumeRole` session credentials are not requested for every single request. Sessions are valid for 15m by default but without caching that does not matter. This will speed up requests for users of `role_arn` by removing the overhead of most STS (session token service) calls and stop users from hitting rate-limiting issues with the STS. Fixes elastic#37787
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
bug
Filebeat
Filebeat
libbeat
Metricbeat
Metricbeat
needs_team
Indicates that the issue/PR needs a Team:* label
When using the
AssumeRole
authentication feature of the AWS SDK, libbeat's helper does not add a credential caching layer. The impact is that every operation that needs to retrieve credentials (i.e. every signed API request) must issue a request to AWS to get a new session token for that one request.This has multiple impacts:
AssumeRole session tokens normally having a minimum TTL of 15 minutes (and up to 12 hour max). So the expected behavior is for one request to be made every 15 minutes. Another issue is that the TTL duration is not configurable so it will always be 15m.
Example error message:
failed to sign request: failed to retrieve credentials: operation error STS: AssumeRole, failed to get rate limit token, retry quota exceeded, 2 available, 5 requested
For confirmed bugs, please report:
role_arn
The text was updated successfully, but these errors were encountered: