ec2metadata does not speak EC2 IMDSv2
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cloud-utils |
Fix Released
|
Undecided
|
Paride Legovini | ||
cloud-utils (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Bionic |
Triaged
|
Undecided
|
Paride Legovini | ||
Focal |
Triaged
|
Undecided
|
Paride Legovini |
Bug Description
Forwarded from https:/
The ec2metadata command queries a well-known link-local endpoint
(169.254.169.254 in Amazon EC2) to obtain information about the instance
on which it runs. Last year, AWS released "IMDSv2" in an effort to
protect customers against some potentially severe information leaks
related to accidentally proxying this local data to the network. Details
at
https:/
IMDSv2 makes use of a session-based protocol, requiring clients to first
retrieve a time-limited session token, and then to include that token with
subsequent requests.
Because the intended purpose of IMDSv2 is to provide an additional layer
of defense against network abuses, customers utilizing it may choose to
disable IMDSv1. Doing so today causes ec2metadata to fail.
Changed in cloud-utils: | |
status: | New → Triaged |
assignee: | nobody → Paride Legovini (paride) |
Changed in cloud-utils: | |
status: | Triaged → In Progress |
Changed in cloud-utils: | |
status: | In Progress → Fix Committed |
no longer affects: | cloud-utils (Ubuntu Hirsute) |
Changed in cloud-utils (Ubuntu Bionic): | |
status: | New → Triaged |
assignee: | nobody → Paride Legovini (paride) |
I've attached a patch the implements IMDSv2 support. Flake8 reports no issues. Tested on EC2 with the following configurations:
1. IMDSv1 support enabled (token optional).
2. IMDSv2 support enabled (token required).
3. IMDS endpoint disabled (raises an exception due to a 403 response from the metadata endpoint).
In the attached patch, if the token retrieval endpoint returns a 404, we assume we're running on some other cloud (not EC2) that presents an EC2-compatible IMDS. In that case, we continue operation as normal, but without using the token. So essentially we've fallen back to IMDSv1 mode, and functionality is not impacted. In theory, some implementation may return something other than a 404, and we should handle its response in a similar way. I don't specifically know of any implementation where this happens.