Saltar al contenido

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

preguntada hace 3 años903 visualizaciones
3 Respuestas
1
Respuesta aceptada

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

respondido hace 3 años
EXPERTO
revisado hace 2 años
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
INGENIERO DE SOPORTE
respondido hace 3 años
-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
respondido hace 3 años

No has iniciado sesión. Iniciar sesión para publicar una respuesta.

Una buena respuesta responde claramente a la pregunta, proporciona comentarios constructivos y fomenta el crecimiento profesional en la persona que hace la pregunta.