Adding support for adding ssh public key from file

[mad01]

MVP implementation of adding secret from file related to #2195

cat > secret.yaml <<EOF
apiVersion: kops/v1alpha2
kind: SSHSecret
metadata:
  labels:
    kops.k8s.io/cluster: dev.k8s.example.com
spec:
  username: "admin"
  sshPublicKey: "ssh-rsa AAAAB3NzaC1yc2EEEAADA dev@devbox"
EOF

kops create -f secret.yaml

[k8s-ci-robot]

Hi @mad01. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[mad01]

should be good to go. Did a new PR since i broke something in git on the old one.
/assign @justinsb

[justinsb]

Looks good but two thoughts... Not sure if we discussed them on the previous PR or not:

The username isn't used afaict. And it won't do anything so it might just cause confusion. I like the idea, but I'm thinking we add it when we can make it work? Or we could move it out of spec and into status.

SshSecret implies it is secret, but the public key isn't. I'm thinking either SshCredential, or SshKey or ClusterKey because key is ambiguous. Or ClusterSecret, and we put more secrets in the same api object.

Actually though neither of these is significant enough to block the PR, but I wanted to get your thoughts

[justinsb]

/ok-to-test

[justinsb]

/retest

[justinsb]

Flakiness is being tracked in upstream issue: kubernetes/kubernetes#51128, hopefully fixed by kubernetes/kubernetes#51144

[eparis]

/retest
merged the referenced fix

[mad01]

@justinsb right. It's true it's not actually a secret, your idea of changing the name makes since to something like SshCredential. I rather change it in this PR.

Do you mean that the username can just be that i set to admin can just me a static string of admin in the AddSSHPublicKey func in the create.go file?

[mad01]

@justinsb update the PR to not use secret, i changed it to SSHCredential. if i understand it correctly the username it static to admin. from my understanding it should be ok for now to set the key in AddSSHPublicKey to admin is that correct ?

new example file would be

apiVersion: kops/v1alpha2
kind: SSHCredential
metadata:
  labels:
    kops.k8s.io/cluster: dev.k8s.example.com
spec:
  publicKey: "ssh-rsa AAAAB3NzaC1 dev@devbox"

[justinsb]

Thanks @mad01. On AWS, the SSH public key is currently only set in the user data, and then it is up to the AMI to configure it for whatever account makes sense. debian uses admin, ubuntu uses ubuntu etc. There's no way to configure the username as it is entirely up to the AMI.

The name of the SSH public key as stored by kops is admin, but that isn't always the username used (confusingly!)

/lgtm

[k8s-github-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: justinsb, mad01

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these OWNERS Files:

• OWNERS [justinsb]

You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

[k8s-github-robot]

/test all [submit-queue is verifying that this PR is safe to merge]

[k8s-github-robot]

Automatic merge from submit-queue