metal: add tectonic_ssh_private_key variable#625
metal: add tectonic_ssh_private_key variable#625coreypobrien wants to merge 1 commit intocoreos:masterfrom
Conversation
|
Can one of the admins verify this patch? |
1 similar comment
|
Can one of the admins verify this patch? |
|
@coreypobrien You probably want to add an entry similar to https://github.com/coreos/tectonic-installer/blob/master/examples/terraform.tfvars.metal#L25-L27 |
platforms/metal/variables.tf
Outdated
| EOF | ||
| } | ||
|
|
||
| variable "tectonic_ssh_private_key" { |
There was a problem hiding this comment.
just a concern relating recent discussion. this private key will end up in the state file, rendering its security useless.
There was a problem hiding this comment.
Hrm, yeah that gets into a more broad discussion of secrets in the state file. Terraform has been wrestling with that issue for a bit: hashicorp/terraform#9556
Since we are already storing secrets like the private keys for the CA, seems like a good discussion to have for the whole repo.
I will go ahead an add a note in the description that the private key will be stored in the state and potentially shared wherever the cluster state is stored.
There was a problem hiding this comment.
I suggest we use the file interpolation function and only configure the location of the private key. Since this is only used for bootstrap time and needs not to be persisted I don't think we need to bend the rule here as was done for the ca key.
There was a problem hiding this comment.
Is there a clean way to have an optional file? I don't know of one off the top of my head, but I know you've been looking at this as a part of #133 so thought maybe you had some insight?
There was a problem hiding this comment.
Unfortunately I didn't find a good alternative yet. I think using the template_file resource with no template variables defined and a count on it could make this work, but it seems very hacky.
@alexsomesan Do you have any creative suggestion to declare "optionally read file x" semantics?
There was a problem hiding this comment.
@coreypobrien ok, I have a silly idea which we already leveraged, namely pointing to /dev/null by default ;-) We have a precedence already when providing optional etcd CA certificates: https://github.com/coreos/tectonic-installer/blob/fff91d9/modules/bootkube/assets.tf#L8-L10
There was a problem hiding this comment.
Ah, nice. I'll head down that path! Thanks!
There was a problem hiding this comment.
Updated to use a path that defaults to /dev/null
coreypobrien
force-pushed
the
sshkey
branch
2 times, most recently
from
353f8c4 to
8c82698
Compare
|
bump on review |
|
ok to test |
|
@coreypobrien Hey, sorry for the late response. Do you mind to correct the offending file? CI says: |
|
Rebased and formatted |
Follow up on coreos#625 for VMware platform
Follow up on coreos#625 for VMware platform
Follow up on #625 for VMware platform
| tectonic_ssh_authorized_key = "" | ||
|
|
||
| // (optional) SSH private key file corresponding to tectonic_ssh_authorized_key. If not provided, SSH agent will be used. | ||
| // Example: `/root/.ssh/id_rsa` |
There was a problem hiding this comment.
based on my testing the key is required to be on PEM format. can we change the line to ~ "Example: /root/.ssh/id_rsa.pem" if that's accurate?
There was a problem hiding this comment.
I'm not super excited about that idea because ~/.ssh/id_rsa is a well-known default name for a private key. Curious to hear other opinions, though.
Allow users to specify the SSH private key via a variable in cases where ssh-agent isn't available or configured.
coreos#625 From 002-ssh-private-key.patch
|
ok to test |
|
Can one of the admins verify this patch? |
1 similar comment
|
Can one of the admins verify this patch? |
|
let's close this for now. if you feel that feature needs to land, feel free to reopen. |
7 participants
Allow users to specify the SSH private key via a variable in cases where
ssh-agent isn't available or configured.