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

fix: Cache AWS Creds instead of getting a Session on every invoke #1494

Merged
merged 4 commits into from
Dec 11, 2019

Conversation

jfuss
Copy link
Contributor

@jfuss jfuss commented Oct 31, 2019

Addresses Issue #1375.

Due to Boto3.session.Session objects not being thread safe, we
create a Session object on every invoke to get credentials to
mount into the container. This works well except for customers
using MFA. When using MFA, this dehavior requires customers to
provide MFA code/pin on every invoke. This creates much longer
debug sessions for customers and pauses invokes until the MFA
code/pin is provided. This PR changes that behavior to one we
had between version v0.8.0 and v0.16.0, which is caching the
creds/session to be reused on other invokes until the credentials
expire. Once the credentials expire, customers will need to restart
the command (which was the same behavior on version 0.8.0 to 0.16.0.

Issue #, if available:

Description of changes:

Checklist:

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Addresses Issue aws#1375.

Due to Boto3.session.Session objects not being thread safe, we
create a Session object on every invoke to get credentials to
mount into the container. This works well except for customers
using MFA. When using MFA, this dehavior requires customers to
provide MFA code/pin on every invoke. This creates much longer
debug sessions for customers and pauses invokes until the MFA
code/pin is provided. This PR changes that behavior to one we
had between version v0.8.0 and v0.16.0, which is caching the
creds/session to be reused on other invokes until the credentials
expire. Once the credentials expire, customers will need to restart
the command (which was the same behavior on version 0.8.0 to 0.16.0.
@jfuss jfuss requested a review from awood45 October 31, 2019 16:31
@jfuss jfuss added area/lambda-invoke area/local/start-api sam local start-api command area/local/start-lambda sam local start-lambda command type/bug labels Nov 12, 2019
@@ -205,6 +207,22 @@ def _make_env_vars(self, function):
aws_creds=aws_creds,
)

def _get_session_creds(self):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we could make this a lazy property in the future.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea. Going to leave it as is for now but something we should consider for the future when dealing with things like this.

@jfuss jfuss removed the request for review from awood45 December 6, 2019 16:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/lambda-invoke area/local/start-api sam local start-api command area/local/start-lambda sam local start-lambda command type/bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants