IMDSv2 broken and no ETA

0

We discovered an issue with IMDSv2 where logging would fail with 403 errors. AWS has identified it as an issue with their platform and escalated to their "Internal Team". The issue has been open for over a month with no update from the internal team. We have reverted to the IMDSv1 service.

Does anyone else have this issue?

GitHub issue here: https://github.com/aws/elastic-beanstalk-roadmap/issues/294

Spiff
asked 10 months ago400 views
3 Answers
1
Accepted Answer

Looks like AWS fixed this in the latest release of their windows platform 2.11.7

Spiff
answered 8 months ago
profile picture
EXPERT
reviewed 5 days ago
1

Hello,

Greetings!

Thanks for reaching out. I am from support team and would like to add details regarding your concern. To inform you our internal team is actively working on finding the route cause of this issue with IMDSV2.

They have suggested the workaround to use IMDSV1 for the time being but rest assured they will be back with the root cause and resolution. I may not be in a position to provide you an exact ETA when this issue will get resolved as the team doesn't shares an ETA.

Also i would request others to share their feedbacks here if they are also facing the same issue. You can create a issue on https://github.com/aws/elastic-beanstalk-roadmap/projects/1 for tracking and you will be updated on this, once the issue is addressed.

I hope the above information helps.

Regards!

AWS
SUPPORT ENGINEER
answered 10 months ago
-2

This does not sound right as IMDSv1 and IMDSv2 are the same service. So if IMDSv1 works then IMDSv2 is (or should) be working. IMDSv2 uses session oriented requests for extra defense-in-depth. More information on the differences is here: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html

Have you tried a single, manual IMDSv2 call on the instance to see if that works? If it does, then your software may not be making v2 calls correctly. If the call does not work, then it's likely an instance metadata options setting you need to update.

A common "gotcha" is not having the right hop limit in containerized workloads. By default, the Http-put-response-hop-limit is 1 but you may need to increase to 2 or 3 to get a response to your application.

AWS
answered 10 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions