Passer au contenu

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

demandé il y a 3 ans902 vues
3 réponses
1
Réponse acceptée

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

répondu il y a 3 ans
EXPERT
vérifié il y a 2 ans
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
INGÉNIEUR EN ASSISTANCE TECHNIQUE
répondu il y a 3 ans
-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
répondu il y a 3 ans

Vous n'êtes pas connecté. Se connecter pour publier une réponse.

Une bonne réponse répond clairement à la question, contient des commentaires constructifs et encourage le développement professionnel de la personne qui pose la question.