Ease the dependence on VM host names

[felixkasza]

Problem I am still experimenting with cloud-init and using multipass to ease the pain. Regrettably, multipass expects the VM name to be DNS-resolvable. The resulting IP address is used to SSH into the VM. That has two disadvantages, one of which does not really fall into multipass' purview:

Name                    State             IPv4             Image
b                       Running           172.29.174.74    Ubuntu 20.10
                                          172.29.165.73

As you can see, the crappy host.ics updater that comes with Hyper-V's built-in PV network adapter and virtual switch is often derelict in its duty and keeps old IP addresses around. I suspect that at times, multipass picks the "wrong" address, as it has no way to tell which one is the current address.

The other item is not clearly visible: The hostname of the guest OS is not "b" because the user-data YAML file requested cloud-init to change it. A manual change of host name and FQDN has a similar effect. Unless the VM's IP address is known or guessable from a port scan, the VM is no longer accessible.

Proposal In an ideal world, the guest OS would communicate its IP address and maybe even the name of a suitable sudo-capable user to multipass, via a mechanism that is not susceptible to random interference from people like me. 😀 Heck, subject to security considerations, the guest OS might even accept, through the same mechanism, a public key and make sure it is accepted for the mentioned user.

One mechanism, at least on Windows which I know far better than Linux, to communicate from guest to host is the key/value-pair exchange, available in different forms under both Hyper-V and Virtualbox.

• Hyper-V: On the Linux guest-OS side, key/value pairs magically appear in one of a few special files; conversely, key/value pairs written to specific registry keys on the host show up in one of those special files in the Linux VM. The transfer is managed by Linux Integration Services (LIS), supposedly baked right into the kernels used by Ubuntu, but I had to apt install linux-cloud-tools-virtual before the data exchange started to work. Note that the basics, like the current IP address(es) of the guest, are available on the host side without having to do anything else.
• VirtualBox: An apparently similar mechanism, via "guest properties", exists in Virtualbox. “Guest Additions” must be installed, apparently the equivalent to LIS under Hyper-V. The documentation leads me to believe that, once these additions are available in a running guest, the IP address is available automatically, with no further scripting on the guest or anything.
• Other virtualisation hosts: I have no idea, but I would be very surprised if other virtualisation platforms lacked a similar mechanism. I'd appreciate being instructed.

Security considerations Just obtaining a guest's IP address offers no security concerns. Exfiltrating user names might be problematic; , worse yet, backdooring SSH keys into the guest OS essentially amounts to a full breach, to a complete compromise of the guest OS. That is still not a problem: The instant that an OS runs as a guest under virtualisation instead of being sole proprietor on a physical box in a deep bunker with Faraday shielding and lacking networks of any kind &c., that guest is already compromised; in fact, hypervisors generally provide APIs to enable debugging, including reading and writing every bit of the guest's memory (and the CPU registers, too). In short, all guests are compromised,and the rest are just details.

Summary

• Ensure that LIS (or the platform-specific equivalent) are pre-installed and ready to go.
• Launch a guest OS inside a VM.
• For all further interactions requiring the IP address of the guest OS, acquire that address from the VM directly, relegating DNS to a fall-back mechanism.
• Consider, for much later implementation, a backchannel for configuration data.