-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
[BUG] s3 module fails when IMDSv2 is enforced on ec2 instances #60668
Comments
Hi there! Welcome to the Salt Community! Thank you for making your first contribution. We have a lengthy process for issues and PRs. Someone from the Core Team will follow up as soon as possible. In the meantime, here’s some information that may help as you continue your Salt journey.
There are lots of ways to get involved in our community. Every month, there are around a dozen opportunities to meet with other contributors and the Salt Core team and collaborate in real time. The best way to keep track is by subscribing to the Salt Community Events Calendar. |
It's been a year since this was opened. Any updates on this? |
Bumping this as its impacting my team as well. Our AWS policy forces IMDSv2 so this is crucial. |
Bumping the bump: Being able to use IMDSv2 is a best security practice, and having this support is critical for encouraging use of IMDSv2. |
Closed by #63067 |
Actually looking a bit closer at the code I'm not certain it was fixed by this PR. Can someone confirm if this is still broken on the latest version of Salt? |
Yeah I tested it, it works. |
Description
An ec2 minion with IMDSv2 enabled cannot properly use it's IAM instance profile with the s3 module. The s3 module fails with the message Error running 's3.get': Failed s3 operation. InvalidAccessKeyId: The AWS Access Key Id you provided does not exist in our records.
Setup
Enforce IMDSv2 on a standalone minion running in AWS EC2:
Steps to Reproduce the behavior
With IMDSv2 enforced, attempt to use the s3 module either on its own or in a state (i.e. file.managed with
s3://{bucket}
as the source). The call will fail with:Expected behavior
The s3 module should be able to retrieve proper credentials for subsequent calls to s3 api and the s3 module should work with no additional setup.
Versions Report
salt --versions-report
(Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)Additional context
See also #57514
The text was updated successfully, but these errors were encountered: