Kops: allow security groups as values for 'sshAccess' array

[jdavisclark]

would be great to be able to do:

sshAccess:
  - "sg-2c999a54"

Right now it looks like only CIDRs are allowed, but security group references are perfectly valid in inbound security group rules outside the context of kops.

My specific use-case is to lock down ssh access to cluster of bastion machines which are not managed by kops.

Right now my workflow is:

1. use the most granular private CIDR I can in my base cluster template
2. manually change the ssh inbound security group rules to a specific security group reference
3. redo manual change after every cluster update (which overwrites manual changes with the CIDR)

Thoughts? Some different syntax might be preferable given that kops might support non-aws platforms at some point; but, I think this is still useful.

[rdtr]

Can't we just use additionalSecurityGroups for necessary instance groups ?

[jdavisclark]

@rdtr that wouldn't let you lock down ssh access further than defined in the main security group via the sshAccess would it?

if the main security group limits it to 10.0.128.0/20 via the sshAccess property, then I can't invalidate that via additionalSecurityGroups. Security groups can only contain "allow" rules.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle rotten
/remove-lifecycle stale

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[gaganapplatix]

I am also interested in this. Our use case is that bastion is created outside of kops and is an ASG created instance and we would like to allow ssh access only from that instance to the nodes and master. We would like to use the sg associated with the Launch Configuration for the bastion ASG to be an ALLOW ssh rule for sg-bastion in the nodes and master sg.

[zee-ahmed]

+1