]> git.ipfire.org Git - thirdparty/systemd.git/commit
Basic IMDS support (#40980)
authorZbigniew Jędrzejewski-Szmek <zbyszek@amutable.com>
Thu, 26 Mar 2026 13:12:31 +0000 (14:12 +0100)
committerGitHub <noreply@github.com>
Thu, 26 Mar 2026 13:12:31 +0000 (14:12 +0100)
commit1cf9e4e25e9801b9e8e72f356d70e7b5f684f527
tree3d6fccc7bcc089f0b6bd46d16c13f2a1288dff0f
parent437278abd56c3d5593c258e877558f40036845be
parent29f45d1342511949cc9913a8088ba868e665e679
Basic IMDS support (#40980)

This adds a new cloud IMDS client, that can cover AWS, Azure, GCP,
Hetzner imds to varying degrees. Each cloud has this and it's very basic
functionality, hence I think it makes sense to add this to systemd.

Since the clouds are all different this tries hard to do the abstract
common logic in code, but encode the endpoint details, and well-known
keys in hwdb, attached to the DMI id device.

Why all this?

* Efficiency: we can schedule this in the initrd, at the earliest points
possible, without unnecessary delays
* Robustness: imds is typically slow and/or heavily rate-limited:
systemd-imdsd as single entrypoint can deal with that, and provide a
reliable, cached interface
* Security: the idea is that systemd-imdsd is the only service behing
able to access the IMDS HTTP, and the host carries a blackhole route for
it otherwise. That way sensitive info can be kept away from clients, and
requires polkit auth for access
* Simplicity: extraction of systemd's system credentials from IMDS
userdata happens with systemd's own infra, and for many usecases that
should already be enough.
* Measurements: before accepting the IDMS userdata, it can be measured
into a PCR, as any other configuration input for the system

Fixes: #40763