Comment by cryptonector | Hacker News Reader

Comment by cryptonector | Hacker News Reader

First I've heard of cloud-init. So I went looking to see how it does provisioning of SSH keys and... it doesn't really. Sure, it will add public keys to the authorized_keys file, but it won't do anything to register each provisioned hosts' public keys anywhere. And here was I hoping for something to do with TPMs or DICE or something. But sadly, no.

It would be a really good thing to integrate something like Safeboot (https://github.com/osresearch/safeboot), which does use TPMs. Safeboot is implemented as Bash scripts using tpm2-tools, which... I'm really not fond of. I'd rather implement the Safeboot protocol or similar from scratch in Rust or Go, or even maybe parts in C and parts in a safe language. But anyways, the idea is to enroll a host given its TPM's EKcert or the system's platform cert (if it has one), and in the process generate credentials for the host that it will be able to fetch upon attestation upon first boot and which only it can decrypt using its TPM, then after that the host can use those credentials as a root of trust with which to acquire any other necessary credentials (if any). E.g., client certificates, Kerberos keys ("keytabs"), TLS server certificates, etc.

Cloud-init isn't about boot process, it's about initial provisioning of a system.

If you need the host's public keys registered somewhere, you can do that using cloud-init, but there's not built-in mechanism. You'd have to write your own script to do so.

The point of cloud-init is to be a provider independent entry point that runs on first boot and lets you specify per node metadata. You use it to install a package or download a script which then does what you want. Before cloud-init, each cloud provider had their own way of running a bash script on first boot.

For the Raspberry Pi specifically, you would use cloud-init to program Raspberry Pis/compute modules.

Why can't you just simply build a VM image or SD card image and copy it to all the Raspberry Pis? Well you could, but then you need to build a unique image for each Raspberry Pi. Cloud-init lets you factor out the differences between the Raspberry Pis and reuse a single image for all of them. E.g. each Raspberry Pi can have a different hostname, account name, root password and all you have to do is put them in a single configuration file.

Unfortunately the TPM story for the raspberry pi… isn’t, really. It doesn’t come with one, and while it does support secure boot, it’s incredibly limited and more akin to what you’d find in a microcontroller (you can burn vendor keys to EEPROM). So all that to say, it would be kind of pointless, unfortunately.

I’d you’re interested in this, I know systemd has been working pretty hard on getting TPM-provisioned credentials usable on Linux though!

Ooh, thanks for the systemd clue. I'll see if I can find that work.

> It would be a really good thing to integrate something like Safeboot (https://github.com/osresearch/safeboot), which does use TPMs.

What TPMs? This is for the Raspberry Pi line of machines, which don't include that hardware.

I was talking about cloud-init generally, not TFA's specific use.

To all the commenters telling me that cloud-init is not a credential provisioning system, the docs do not make that clear! They talk about provisioning and SSH keys too! So I looked and... then it became clear that that was not really the case, so I expressed an opinion with substantive information that might help someone -if anyone happens upon my comment who contributes or would contribute to clouid-init- improve it.

To add to the other responses, cloud-init is also not a secure delivery mechanism, you shouldn’t be using it to deliver sensitive information, but you could use it to kick off scripts that access more appropriate mechanisms, like in AWS where you can access a local URL to obtain instance credentials.

Reply on news.ycombinator.com