On 11/12/2024 14:42, Jeremy Stanley wrote:
> On 2024-12-11 11:32:36 +0000 (+0000), Sean Mooney wrote:
> [...]
>> note that we also have a write once mechanic where by a first boot
>> agent can generate an admin password withing the guest and post
>> that back to the metadta api to save it to the nova db.
> [...]
>
> 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?).
so this "feature" is more or less undocumented and i believe it was
originally added because AWS ec2 before we started to use specs for
things like this.
its something we rediscover is a thing every few years when we do a code
audit
This "feature" was added at the request of mordred (Monty Taylor) IIRC. He was specifically concerned about knowing that the machine that he had requested was the one he was actually connecting to. At the time I had reliability concerns because parsing the console log is actually a little hard to do reliably.
Vendordata is a similar use case and was added at the request of Adam Young from Red Hat for use with registering new instances with Active Directory or FreeIPA IIRC -- the idea was that you could provide a cryptographic token to the instance in metadata, and then possession of that token at instance registration time would prove that you were in fact the requested instance.
SPIFFE calls this problem space "identity zero" if that helps. AWS solves it these days with a thing called an "instance identity document" which is part of the instance metadata. Possession of that document proves you are a specific instance (it does however not stop other software on that instance from also proving that thing).
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-identity-documents.htmlI wonder if injecting the ssh hostkey via user-data is a meaningful way to solve these problems as well?
I say all of this by way of trying to say:
- parsing the console log for ssh host keys makes me sad because its not reliable.
- vendordata with a join token is probably a better solution.
- although it would be relatively easy to add an equivalent of the identity document to our metadata service if we wanted to.
(AWS also has an in guest agent called SSM, but I think that would be a lot more work to implement in Nova, especially with the number of hypervisors it would be expected to support).
I hope this helps,
Michael