Launch Ec2 instances with specified KeyPair

[michaelajr]

Many organizations have AWS Ec2 KeyPairs that are reused across instances. E.g., prod or nonprod keys. Kops should allow cluster nodes and masters to be launched with existing key pairs.

[alexanderbez]

I believe you can.

e.g.

$ kops create cluster \
  --name $CLUSTER_NAME \
  --state $K8S_STATE_STORE \
  --ssh-public-key "<path/to/your/pubkey/key.pub>" \
  // ...

[plombardi89]

@alexanderbez I interpreted this request as being able to refer to existing key pair in EC2 rather than creating a new one with the given public key. @michaelajr is that correct? I've often though that would be a nifty feature.

[jrnt30]

That is also how I interpreted the request, which was the same as my "ask"

[michaelajr]

Yes. We have existing KeyPairs that are rotated and audited by our security team. To keep in alignment with our security requirements - at a bare minimum - we need a way to use an existing Key Pair as the SSH key in the cluster. Typically AWS does this when it launches an instance. You just specify the key to use. Is there a reason Kops needs to create one?

[masoman22]

Agree, the ability to specify an existing keypair in AWS when kops spins up the instances is a much needed feature

[floer32]

For posterity, see #251 and https://github.com/kubernetes/kops/blob/master/docs/security.md#ssh-access

[sellers]

The LaunchConfigurations may be modified to support an 'existing' keypair that is available in the AWS account, thus removing the need to duplicate the key (as @hangtwenty mentioned) and make for a single canonical source of key management and auditing.

[michaelajr]

@sellers Are you suggesting a manual update of the launch config via the AWS Console UI?

[pdu]

@michaelajr The way I work around is:
1, download the ssh public key of the existing keypair to local
2, when kops create, specify the --ssh-public-key to the downloaded ssh public key file
Then everything is fine now

But I still don't know how to change the login name, it seems I have to use admin as the login name even I want to use another login name.

It's better kops can support an existing keypair. @sellers

[michaelajr]

@pdu yeah - that's what we do now. The problem is that Kops actually creates a NEW Key pair from the key data. We have very strict ITSec rules and specific keys pairs that are allowed to be used. In fact, to SSH to an instance, we "checkout" the key temporarily (we have a whole system in place to do all this). KOps creating a NEW key pair is not good for us. It also prevents our automatic key rotation. We rotate known keys and update the running instances that use those keys. Further more this is just an odd way to go about all this as when launching an EC2 instance one typically specifies an existing key pair in AWS. IMO, options should be, "use existing key from filesystem" (current behavior), or "use existing Keypair" which would launch the instance by specifying an existing key pair in AWS.

[druidsbane]

@michaelajr @pdu This is a big issue for us as well. We definitely need a way to reuse existing keypairs as creating a new one or having one owned/deleted by kops for any new clusters would be a problem.

[rdrgmnzs]

Link to the docs for future reference https://github.com/kubernetes/kops/blob/master/docs/cluster_spec.md#sshkeyname

@chrislovecnm this ticket could probably be closed.

[mludvig]

How do I do this on the command line? The trouble is that kops create cluster immediately attempts to create the SSH key before I can go and edit the config file. I was hoping for something like kops create cluster --ssh-key-name but that doesn't work.

[jrnt30]

I don't know that it is explicitly exposed in the UI, you can now kops create cluster -f <specification file>.

We have found it more usable to have a template cluster spec and inject some of our customizations on top of that to bake in some of these types of changes more easily.

[badgerspoke]

Does anyone know how to NOT have an SSH key at all?
Consider that either it's already in the (custom) AMI and we have the private key already, or we simply don't want any SSH access at all (deny network access via SG is not sufficient)