| 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:30 |
| EvanCarroll | I still have 0 idea of how to get a private key onto a machine safely. | 00:31 |
| 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:53 |
| 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... | 00:57 |
| 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:00 |
| minimal | s/to machine/to look after/ | 01:01 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:49 |
| minimal | ^^^ my last question | 01:50 |
| minimal | that way their keys never leave their own device(s) | 01:50 |
| 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. | 01:57 |
| minimal | ok. i'll leave you to figure it out - everyone's basically saying it a bad idea to do things that way | 02:00 |
| 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 | 02:02 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!