Kops: Bastion improvements

[kris-nova]

After #694 goes through we need a PR to add a bastion configuration feature.

I think the main use case is bastion instance size, but we should also be able to turn it on/off and support things like DNS / ephemeral TCP ports, etc

[jmound]

Some design feedback:

• For on/off, the ASG can be set to desired/min/max =0, which should be sufficient for most needs.
• DNS can be as simple as --bastion-name="bastion" which would then create the route 53 record such that bastion of the --dns-zone domain mapped to the ASG's ELB.
• A t2.medium default instance size with a parallel --bastion-instance-size
• A high idle timeout would make many of us smile more, I'd think.
• And, on a minor note, as mentioned in #694 but more relevant here, just to make sure it doesn't get lost, the ssh to the bastion: ssh -i ~/.ssh/id_rsa [email protected] will need some updating.

[alok87]

It would be great if we can give the user - the flexibility to use an existing bastion from his/her current vpc (which can be vpc-peered with the kops created vpc)

[jmound]

• I left off one additional feature to this list in my previous comment, namely making the bastion aspect completely optional. That would solve your use case @alok87, you can just have it disabled and use whatever pre-existing bastion setup you have.

[kris-nova]

@alok87 it would be great if you could take a stab at this issue!

Basically the high level overview is that we want the bastion server to have some useful features for users..

@jmound has called out a few features he would find useful, and I mentioned a few above..

The steps we would like to see for a larger feature like this are

1. Open up a PR with some documentation around the new feature. What will it do? How will users use it?
2. After we agree on the design it's time to code the feature. Feel free to commit up any code you like and we can all give you helpful feedback on it.
3. After the feature comes to life, we need unit tests for it. Please get those coded.
4. Go through the standard PR process and get feedback/make changes if needed
5. Merge :)

[alok87]

@jmound regarding https://github.com/kubernetes/kops/issues/836#issuecomment-259741194

Instead of turning off bastion and configuring cluster manually with the exisitng bastion. It would be nice if:

• kops peers the current vpc with the new vpc created for kubernetes.
• kops uses the current vpc bastion for the private kube cluster on the new vpc

What do you think?

[jmound]

I think that is likely too complicated to generalize. For example, often, a peered VPC is not needed. Most commonly, it's a single VPC, and access is provided separately via VPN and not via a bastion host.

[chrislovecnm]

@kris-nova any idea on the ssh key thing? Kinda a pain :)

[chrislovecnm]

We have PR inbound thay may help with this ... I am looking through issues to test against #1183

What does this PR address? We are moving bastions to instancegroups, so the bastion can be deleted with an edit.

[chrislovecnm]

I have a bunch of data -

• For on/off, the ASG can be set to desired/min/max =0, which should be sufficient for most needs. - show be fixed see #1206
• DNS can be as simple as --bastion-name="bastion" which would then create the route 53 record such that bastion of the --dns-zone domain mapped to the ASG's ELB.
• A t2.medium default instance size with a parallel --bastion-instance-size - show be fixed see #1206
• A high idle timeout would make many of us smile more, I'd think. - we should have this now
• And, on a minor note, as mentioned in #694 but more relevant here, just to make sure it doesn't get lost, the ssh to the bastion: ssh -i ~/.ssh/id_rsa [email protected] will need some updating. - need more info

Bastions are now instance groups. You can do full CRUD on them. Who can test?

DNS and the note on SSH are the two that are outstanding. Can someone open another issue on each?

[justinsb]

What is remaining here?

[chrislovecnm]

We need to test the above comment :)

[kris-nova]

Closing RE: 1.5.0