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

aws-config credentials providers inconsistently cache when explicitly configured #629

Closed
Tracked by #1692
jdisanti opened this issue Oct 5, 2022 · 3 comments
Closed
Tracked by #1692
Assignees
Labels
bug This issue is a bug. p2 This is a standard priority issue

Comments

@jdisanti
Copy link
Contributor

jdisanti commented Oct 5, 2022

The default credentials chain has caching, and AssumeRoleCredentialsProvider has caching when set explicitly on SdkConfig. The rest of the credentials providers don't cache when set up explicitly though. Ideally, credentials providers would just always cache—one should not need to think about it. Even better if things are smart enough to not double-cache (does AssumeRoleCredentialsProvider add a redundant layer of caching to the default chain?).

@jdisanti jdisanti added the bug This issue is a bug. label Oct 5, 2022
@jdisanti
Copy link
Contributor Author

jdisanti commented Oct 5, 2022

The type system could potentially be used to enforce that caching is configured correctly. The SdkConfig could take a dyn CachingCredentialsProvider trait while all the credentials providers only implement CredentialsProvider. Then the caching wrappers such as LazyCachingCredentialsProvider could implement CachingCredentialsProvider. This would make it impossible to override credentials providers without caching, or if someone really wanted no caching, a manual implementation of CachingCredentialsProvider would be needed.

@jmklix jmklix added the p2 This is a standard priority issue label Nov 14, 2022
koivunej added a commit to neondatabase/neon that referenced this issue Dec 16, 2022
IMDSv2 has limits, and if we query it on every s3 interaction we are
going to go over those limits. Changes the s3_bucket client
configuration to use:
- ChainCredentialsProvider to handle env variables or imds usage
- LazyCachingCredentialsProvider to actually cache any credentials

Related: awslabs/aws-sdk-rust#629
Possibly related: #3118
koivunej added a commit to neondatabase/neon that referenced this issue Dec 16, 2022
IMDSv2 has limits, and if we query it on every s3 interaction we are
going to go over those limits. Changes the s3_bucket client
configuration to use:
- ChainCredentialsProvider to handle env variables or imds usage
- LazyCachingCredentialsProvider to actually cache any credentials

Related: awslabs/aws-sdk-rust#629
Possibly related: #3118
koivunej added a commit to neondatabase/neon that referenced this issue Dec 16, 2022
IMDSv2 has limits, and if we query it on every s3 interaction we are
going to go over those limits. Changes the s3_bucket client
configuration to use:
- ChainCredentialsProvider to handle env variables or imds usage
- LazyCachingCredentialsProvider to actually cache any credentials

Related: awslabs/aws-sdk-rust#629
Possibly related: #3118
@goabv goabv moved this to In Progress in AWS Rust SDK Public Roadmap Jan 19, 2023
@ysaito1001
Copy link
Collaborator

Closing this, as it's been implemented in smithy-lang/smithy-rs#2122 (plus its follow-up smithy-lang/smithy-rs#2227).

@github-project-automation github-project-automation bot moved this from In Progress to Done in AWS Rust SDK Public Roadmap Jan 23, 2023
@github-actions
Copy link

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or 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. p2 This is a standard priority issue
Projects
Archived in project
Development

No branches or pull requests

3 participants