[18:58] <holmanb> EvanCarroll: catching up on messages now, I went to StackExchange and answered the question before catching up - I see now that minimal suggested pretty much exactly what I did
[18:58] <minimal> holmanb :-)
[18:59] <holmanb> EvanCarroll: also +1 to minimal's take "if you're transfering around privkeys, you're doing it wrong"
[19:28] <holmanb> EvanCarroll: It sounds like you have an engineering problem that has many different potential solutions, but no current "best practice". Minimal has made some really good points and suggestions. IMO this "problem" currently falls into CI/runcmd territory. Some changes to cloud-init could potentially be made to improve your described use-case, but I'm not convinced that we have enough users with this specific need (have the 
[19:28] <holmanb> ability for a "cloud-init"ialized server to securely access remote secure resources without exposing secrets to local users) for this to be a priority. I might be wrong on that, however (please tell me if I am). And of course, contributions are always welcome :)
[19:38] <minimal> holmanb: I always wondered if it would be useful for NoCloud seedurl requests to pass something like a host UUID or similar which might help with provisioning cycles (i.e. to later corrolate with the same UUID passed later via phone-home)
[19:43] <holmanb> minimal: I could see that being useful for a variety of different use cases, including the phone-home one you suggested.
[19:49] <minimal> holmanb: in particular as NoCloud seed-url involves DHCP (can't get it to work with static IP etc) then the server hosting the seed urls can't really distinguish between multiple different machines (server could actually be a script generating custom seed docs on the fly)