Question:
Azure, AWS and Google all allow info from the hypervisor to be passed down to the host through talking to a non-routable link-local address. Which should be accessible immediately when the machine boots. I want to add an additional credential fetching mechanism to early boot next to SMBIOS and UEFI that tries fetching credentials from there to e.g. have systemd-tmpfiles populate ssh.authorized_keys.root Credential from it. But for that I need to add quite early a routing rule that link local addresses should go to the main ethernet interface. I know it's hard to guarantee when IP addresses are configured. But for link-local this should be easier no? Basically when the interface appears.
But currently systemd-networkd runs I guess too late to have systemd-tmpfiles-setup.service depend on it. And also just that networkd started doesn't mean it already applied link local routing.
Curious if there is some way to get link local networking set up early and know when the link-local address is actually available?
Reply:
link local addresses by ipv4ll spec require probing, i.e. you check first a couple of times whether some other host uses them
so the full, correct ipv4ll logic is not necessarily fast
this is the benefit of the SMBIOS logic, it's just there and just works, and blazingly fast.
note that the ivp4ll implementation is actually a library in systemd
which was supposed to be a public library eventually
but that hasn't really happened in the last 10y
but theoretically you could write a tool that just runs independently from networkd
could even do something like this: create some ipvlan iface or so off the main interface, inside a private network namespace. then manage that iface there, pick up the data in there, and pass it into the system. This would isolate this early network communication from the rest of the host: no other network stack would be tempted to talk on the network, wouldn't even see any interface go up
that said, the current model for the credentials logic we implement assumes that we can pick up creds "fast", i.e pid1 picks them up directly from smbios super early on, it's just there, and the rest of userspace only starts afterwards. And we assume that's when creds are installed in the system and not afterwards (well, the $CREDENTIALS_DIRECTORY creds, not the /run/credstore/ creds). This matters since PID 1 itself is one consumer of the creds (for machine ID and so on), and it can't consumer them anymore if the creds just show up late
but: we provide another place that creds are incorporated into $CREDENTIALS_DIRECTORY; and that's during the initrd→host transition
my assumption was always that ignition/cloudinit would insert their creds there
which however means that they aren't available in the initrd to configure initrd tasks