Allow to specify ssh-key via flag

[mrIncompetent]

Current state: On initial start, we check if a secret with a private ssh key exists. If no secret is found, we generate a secret with a private key.

This ssh key will be later used when creating instances at cloud-providers. This was made so the user does not have to specify a ssh public key in the machine-manifest, as some cloud providers require to specify a public key when creating a instance (aws).

All public keys from the machine manifest are getting deployed via cloud-init.

Desired state: The controller should accept a path to a private key via a command line flag. If the flag is specified and a valid key got found, this key should be taken. If no flag was specified or the key was not found, the old logic with the secret should apply.

[alvaroaleman]

Thinking about this some more, I dislike that idea. We should instead remove this whole ssh key deployment functionality everywhere where it is not absolutely required (AWS) and let users pass in their ssh key via the machineSpec if they so chose.

Allowing to pass a ssh key via flag is just an incentive to not put the key in the place it belongs, the machineSpec.

[mrIncompetent]

Pro:

• We can get rid of ssh key handling code in all providers - except aws

Cons:

• We would need to extend the key handling code in AWS
  • Check if any of the specified ssh keys exists in the account
  • If none of the specified keys exists, we would need to create it -> which one and which name to take?
• Different behavior on the different cloud-providers -> bad user-experience
• We would introduce a hard coupling of the sshPublicKeys property and the cloud-provider

[alvaroaleman]

No, leave the code for AWS as-is, only remove the handling from the other cloud providers.

[mrIncompetent]

So we maintain the initial creation of the ssh-key + secret but we simply ignore it for everyone except AWS? I'm pretty sure this will create the most confusion - as users now see a secret containing a ssh key secret in their cluster although it'll never get used

[alvaroaleman]

I don't think so, the machine-controller itself is cloud-agnostic, it doesn't have a flag --cloud-provider=<my-cloud-provider> thus it has to do everything that any of the supported clouds may need.

We can just add a note in the Readme why this is needed and also add a comment in the code. I find this much less confusing than creating a ssh key for every cloud provider just because AWS needs it.

[mrIncompetent]

Need to check if the ssh key is still necessary

[mrIncompetent]

Digitalocean requires us to specify an ssh key. Otherwise the api will respond with: The image for this droplet does not use root passwords, please use an SSH key.

AWS, Openstack & Hetzner don't require a SSH key to be specified.

A just had a new idea: Why not creating a random ssh key during the Digitalocean droplet creation & after successfully creating the droplet, we delete the key?

[alvaroaleman]

That good Sir is an awesome idea.

On Wed, Feb 28, 2018 at 6:44 PM, Henrik Schmidt notifications@github.com wrote:

Digitalocean requires us to specify an ssh key. Otherwise the api will respond with: The image for this droplet does not use root passwords, please use an SSH key.

AWS, Openstack & Hetzner don't require a SSH key to be specified.

A just had a new idea: Why not creating a random ssh key during the Digitalocean droplet creation & after successfully creating the droplet, we delete the key?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/kubermatic/machine-controller/issues/107#issuecomment-369321537, or mute the thread https://github.com/notifications/unsubscribe-auth/AGMfZNIx5spPo6aRivj4_jd8fSWvevsuks5tZZCFgaJpZM4SH-d5 .

[mrIncompetent]

closed in favor of https://github.com/kubermatic/machine-controller/issues/119