is allowing ingress traffic from `0.0.0.0/0` to port 22 necessary?

[itajaja]

Are there any reasons why inbound ssh traffic is allowed in the controller and worker security groups? That expose ssh'ing into the machines from the internet, which could be dangerous https://github.com/coreos/coreos-kubernetes/blob/master/multi-node/aws/pkg/config/templates/stack-template.json#L369

[pieterlange]

It's not strictly required for cluster operations but may help new users who are evaluating the software as you can just SSH into the individual nodes to debug problems. I just sent in a PR today (#628) to prevent assigning a public IP to any component of a kube-aws cluster, but that requires you to set up your own VPC and routetable - again not something a new user is likely to do. But i think most serious users will eventually do something like this.

[itajaja]

thanks, that PR looks interesting

[peebs]

By default, there are no accounts with a password set and so you can only SSH in by public key authentication. If you don't include one of your own SSH public keys, no one can log into the box (except maybe AWS via hypervisor magic).

[itajaja]

still risky ;)

[peebs]

Everyone has to determine their own risk tolerance, what is your main worry here? Just any listening service that was written in C? Seems fair.

We commiserate with the goal of performing admin duties of a cluster without any SSH service running because that is marker of success in regards to the capabilities of kubernetes admin tools. However, I think we will leave this as default for the foreseeable future for debug purposes. OpenSSH is fairly battle hardened/audited and I believe an acceptable risk for the majority of linux users (if, at least, for no other reason then that there are so few alternatives to securely log into a box so almost everyone uses OpenSSH).

You can always mask the ssh service via systemd to disable it, but it seems like #628 is the happy medium here in regards to avoiding ssh being exposed to the internet.

[itajaja]

I am not suggesting to disable SSH, I guess my point is that probably ssh should be opened only inside the vpc, instead of 0.0.0.0/0

[whereisaaron]

Hi @itajaja I raised this earlier and @colhom explained some people prefer to deploy with all the nodes directly exposed on the Internet because they don't want to configure a VPN/NAT or use the controller as a Bastion host.

We currently patch the kube-aws (0.8.1) stack template as below so that the the deployment is entirely VPC internal. Importantly we add our own Security Group (sg-a1234567 below) so we can provide the nodes with Internet access via a NAT instance.

kube-aws (0.8.1) will throw an error right at the end, this is just because it expects the controller will have an external IP to test against and doesn't fail back to the controller's internal IP.

*** stack-template-original.json
--- stack-template.json
***************
*** 90,104 ****
          }
        }
      },
-     "EIPController": {
-       "Properties": {
-         "Domain": "vpc",
-         "InstanceId": {
-           "Ref": "InstanceController"
-         }
-       },
-       "Type": "AWS::EC2::EIP"
-     },
      {{ if .CreateRecordSet }}
      "ExternalDNS": {
        "Type": "AWS::Route53::RecordSet",
--- 90,95 ----
***************
*** 110,116 ****
    {{ end }}
          "Name": "{{.ExternalDNSName}}",
          "TTL": {{.RecordSetTTL}},
!         "ResourceRecords": [{ "Ref": "EIPController"}],
          "Type": "A"
        }
      },
--- 101,107 ----
    {{ end }}
          "Name": "{{.ExternalDNSName}}",
          "TTL": {{.RecordSetTTL}},
!         "ResourceRecords": [{ "Fn::GetAtt": ["InstanceController", "PrivateIp"] }],
          "Type": "A"
        }
      },
***************
*** 315,321 ****
          "SecurityGroups": [
            {
              "Ref": "SecurityGroupWorker"
!           }
          ],
          {{if .WorkerSpotPrice}}
          "SpotPrice": {{.WorkerSpotPrice}},
--- 306,313 ----
          "SecurityGroups": [
            {
              "Ref": "SecurityGroupWorker"
!           },
!           "sg-a1234567"
          ],
          {{if .WorkerSpotPrice}}
          "SpotPrice": {{.WorkerSpotPrice}},
***************
*** 547,553 ****
        "Properties": {
          "AvailabilityZone": "{{$subnet.AvailabilityZone}}",
          "CidrBlock": "{{$subnet.InstanceCIDR}}",
!         "MapPublicIpOnLaunch": true,
          "Tags": [
            {
              "Key": "KubernetesCluster",
--- 539,545 ----
        "Properties": {
          "AvailabilityZone": "{{$subnet.AvailabilityZone}}",
          "CidrBlock": "{{$subnet.InstanceCIDR}}",
!         "MapPublicIpOnLaunch": false,
          "Tags": [
            {
              "Key": "KubernetesCluster",

[itajaja]

thanks for sharing :)

[cknowles]

We've also restricted port 22 more than the default for our clusters via https://github.com/coreos/coreos-kubernetes/issues/212. I submitted https://github.com/coreos/coreos-kubernetes/pull/671 for allowing use of existing subnet but currently considering if it's better to allow re-use of existing route tables instead.