On 2024-12-11 16:30:40 +0000 (+0000), Sean Mooney wrote: [...]
Tangential, sorry, but could this sort of mechanism also be used to provide an out-of-band verification of SSH hostkeys generated on first boot for *nix type guests? We used to splat them to the primary terminal and then try to scrape them from the console log, but having a structured API response would be a lot cleaner (or did something similar already get added and I missed it?). [...] i see the merrit in supprot some kind of reporting for limited trusted boot type use cases such as providing the ssh host key fingerprint so you can validate that the vm is the one you expect it to be.
im not sure how i would feel about allowing arbiarty metadata to be store this way.
is there something beyond the host key that would be useful for you to record on boot?
Nothing else comes to mind. Basically it's the desire to avoid ToFU style finger-crossing that the SSH host key you get on initially connecting to a newly booted server instance is really coming from that instance and not a MitM or honeypot. It's possible in most providers to create an authenticated backchannel by abusing the console log, as I described, but that has its own challenges. I suppose there might be alternative management protocols similar to SSH which rely on asymmetric key algorithms to authenticate hosts, but I'm not personally familiar with any (none with the near ubiquity of SSH at any rate).
perhaps we can try and capture this is a spec or separate thread and work out what an mvp would look like. there would basically be two part, one extednign the metadata api to support recording the host key fingerprint somewhere, and then making that discoverable via the main api perhaps in server show.
That would make sense, and it would probably also be a good idea to try to involve e.g. a cloud-init maintainer in any such design discussion, as this would need client-side integration eventually anyway in whatever's going to communicate the key back to nova.
is we allowed read write access to all instance metadata we would would not actually need to modify the main api as you can already list metadata on an instance but im worried that could be abused so i don't know if that is a good idea.
Yes, that sounds like a security nightmare.
the nova metadata api is not intended a a high performance key value store so i dont necessarily think it would be a good idea to extned this to a generic crud api but we certainly could provide limited support for targeted uscease liek the one you raise.
Agreed, I suppose the field could be given a more generic name in case certain kinds of guests wanted to store functionally similar things in it, but as I said I don't know what else that would end up being anyway. -- Jeremy Stanley