EvanCarrollminimal: It's interesting how bad this problem is.00:30
EvanCarrollminimal: 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:30
EvanCarrollI still have 0 idea of how to get a private key onto a machine safely.00:31
minimalEvanCarroll: 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:53
minimalwhat 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...00:57
minimalhow 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:00
minimals/to machine/to look after/01:01
EvanCarrollminimal: 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:44
minimalEvanCarroll: cloud-init can do what you are trying to do - I merely pointed out that its not a secure thing to do01:45
EvanCarrollminimal: 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:45
minimalthe metadata server is basically an unauthenticated webserver01:46
minimalso its contents are "open season" for anyone01:46
EvanCarrollminimal: 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:46
EvanCarrollyeah, I'm abusing the metadata server. =(01:47
minimaland I asked how you are intended to admin these VMs going forward....Terraform's not the tool for that01:47
minimalso whatever you use to admin them could ensure that the key stuff is dealt with01:47
EvanCarrollminimal: I don't I intend to have these VM's replaced entirely not updated/admin'd.01:49
minimalcan't people use the SSH keys on their own laptops/desktop via SSH agent forwarding?01:49
EvanCarrollSo if the user has a different key, they would just re `terraform apply` and get a fully new sandbox.01:49
minimal^^^ my last question01:50
minimalthat way their keys never leave their own device(s)01:50
EvanCarrollIt'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
EvanCarrollThe key I'm installing just has access to source code. The keys in the agent may have access to customer information.01:57
minimalok. i'll leave you to figure it out - everyone's basically saying it a bad idea to do things that way02:00
minimalyou're stuck in a catch-22 as how can you securely transfer the private keys if you have not established a secure transfer mechanism yet02:02

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!