[00:30] <EvanCarroll> minimal: It's interesting how bad this problem is.
[00:30] <EvanCarroll> minimal: like on the rsync/ssh suggestion, the docs on local-exec say Important: Use provisioners as a last resort. There are better alternatives for most situations. Refer to Declaring Provisioners for more details.
[00:31] <EvanCarroll> I still have 0 idea of how to get a private key onto a machine safely.
[00:53] <minimal> EvanCarroll: after the machine is up then scp/sftp it *to* the machine from somewhere else? (assuming the pub key for the "somewhere else" account was in your user-data to add it to a user's authorized_keys file)
[00:57] <minimal> what myself and the other people in the terraform channel are all basically saying is that typically private SSH keys should *never* leave the machine that they are created on...
[01:00] <minimal> how are you intending to machine your VMs on an ongoing basis? Terraform is only for creating them in the 1st place, not for looking after them after that - that's usually where Ansible/Pupper/Salt/Chef/etc come in...
[01:01] <minimal> s/to machine/to look after/
[01:44] <EvanCarroll> minimal: sure, but if provisioning is dependent on that happening _BEFORE_ then it's not clear how cloud-init is supposed to work. What I need cloud-init to do, it can only do _after_ the key exists on the machine.
[01:45] <minimal> EvanCarroll: cloud-init can do what you are trying to do - I merely pointed out that its not a secure thing to do
[01:45] <EvanCarroll> minimal: This is just to so people can create a development sandbox. The idea here is that their working machine has a key which is authenticated with BitBucket and GitLab and that they create a sandbox in the cloud that they can do destructive things on with that key.
[01:46] <minimal> the metadata server is basically an unauthenticated webserver
[01:46] <minimal> so its contents are "open season" for anyone
[01:46] <EvanCarroll> minimal: yes, but it's kind of bothering that there is no secure method to do what I want _with_ cloud init, I would have to use Terraform, ssh the key, then provision it with ansible or something else.
[01:47] <EvanCarroll> yeah, I'm abusing the metadata server. =(
[01:47] <minimal> and I asked how you are intended to admin these VMs going forward....Terraform's not the tool for that
[01:47] <minimal> so whatever you use to admin them could ensure that the key stuff is dealt with
[01:49] <EvanCarroll> minimal: I don't I intend to have these VM's replaced entirely not updated/admin'd.
[01:49] <minimal> can't people use the SSH keys on their own laptops/desktop via SSH agent forwarding?
[01:49] <EvanCarroll> So if the user has a different key, they would just re `terraform apply` and get a fully new sandbox.
[01:50] <minimal> ^^^ my last question
[01:50] <minimal> that way their keys never leave their own device(s)
[01:57] <EvanCarroll> It's just a different security profile, sure I could make that work too I'd just prefer to solve this problem if possible. If I don't forward, the risk is if someone compromises the box as a non-root user they can access a key that I'm storing on the box as root-only. If I do forward, and someone compromises the box and gets root access, they'll have access to all keys from the forwarding agent. 
[01:57] <EvanCarroll> The key I'm installing just has access to source code. The keys in the agent may have access to customer information.
[02:00] <minimal> ok. i'll leave you to figure it out - everyone's basically saying it a bad idea to do things that way
[02:02] <minimal> you're stuck in a catch-22 as how can you securely transfer the private keys if you have not established a secure transfer mechanism yet