cloud-init team mailing list archive

[Rick Hornsby <rhornsby@xxxxxxxx>]

> On Jan 30, 2022, at 17:04, Marcel Hernandez <e6990620@xxxxxxxxx> wrote:
> 
> Doing this involves embedding a secret API key in the user-data file.
> 
> Problem is, after bootstrapping I can find this secret scattered in several
> places around the server, at /run/cloud-init and /var/lib/cloud.
> /run/cloud-init/instance-data.json is particularly vexing because
> it's a world readable file.
> 
> So I'd like to hear your opinion on what's a good approach to sensitive data
> handling. I couldn't come up with any way to securely embed sensitive data
> into the template itself, only do a post-install cleanup.
> After completing the bootstrap I'm rebooting the server and then uninstalling
> cloud-init and manually removing /run/cloud-init and /var/lib/cloud.

A few thoughts offhand on alternatives to hard coding into user data -

If you’re using AWS (or equivalent), you might be able to leverage your cloud provider’s version of AWS secrets manager. At run-time have your script, based on instance authentication, fetch the credential needed and use it without ever needing to write it to disk at all.

Alternatively, you could use Hashicorp Vault to provide the same sort of thing, though the setup process is more involved. Without instance authentication, there might be a way to trigger just-in-time credentials that give your script access to the secret it needs?

If you don’t necessarily need to protect the API key and other values as secrets, but just want to access it without having it written to disk via user-data, a simple k/v store or even a very basic internal http server that your new server could call would do the trick.

Lastly, having the new server call out to say to your DNS provider “I’m in charge now!” might be better handled outside cloud-init, for example with an infrastructure-as-code tool like Terraform, rather than passed along through user-data and making the new host do this work. TF can pull secrets from a bunch of different sources, so you wouldn’t have to embed it in your TF code. Bonus: you can do pretty much all of your external config including building the new server and tearing down the old one with Terraform as well.