Rancher add rule to security group

Hello,

I created a new cluster in rancher with Amazon as cloud provider and use template node.
Rancher automatically add rule on my security group (I don’t use security group from Rancher).

How can I avoid this ?

Thanks for your help.

PS: by default, Rancher open SSH and docker socket to the world, it’s a bad thing right?

I have exactly the same problem. You posted this in July and no answer whatsoever …

Rancher uses docker-machine to create instances. It adds the ports. You can’t avoid it and use Rancher to create instances for you at the same time. While it may be moderately undesirable, there is nothing particularly “bad” about exposing ssh (with only key auth possible) or the secure docker port (which requires the tls private key).

Hello Vincent,

Thank you very much for your reply. The “problem” is that is not just two ports. There are several ports created by Rancher when it automatically creates the security group on AWS and assigns it to the nodes:

While I understand the need to have 80, 443 opened to the world I dont understand why the following ports are opened to the world instead of being restricted.

30000 - 32767 - 0.0.0.0/0 (TCP/UDP) shouldn’t this range be accessible just from the AWS ELBs ip ranges ?
6443 - 0.0.0.0/0 (TCP) why is this opened to the world ? How can I restrict it ?
2376 - 0.0.0.0/0 (TCP) why is this opened to the world ? How can I restrict it ?

Thank you in advance much appreciated !

Francesco

30000-32767 is the default node port range. When most users expose a service as a NodePort, they expect to be able to reach it.

6443 is the kubernetes API (what kubectl talks to). If the rancher server is down you can still use this to talk directly to a particular cluster. In a future release the generated kubeconfig for a cluster will have an option to point directly at the cluster instead of always going through the central rancher server.

2376 is the docker remote API I mentioned earlier (what docker CLI talks to). There is no specific need for it but docker-machine exposes it by default and uses its presence to test that an instance is created becuase that’s what you’d typically use it for as a standalone tool.

TL;DR: If you want full control over what is exposed and how then you are going to have to make your own instances and register them as a custom cluster. And most people asking these sorts of questions would be using private-ip-only instances.

Thanks a lot Vincent it is way clearer now.

I guess then I would be safe leaving the network ports opened as they are correct ? My boss concerns a lot about security and he was wondering about those ports exactly like me.

If they use SSL and a private key I’d be safe and I will leave them as they are.

I use AWS EC2 cluster option. I have tried to make rancher deploying nodes on a private subnet while keeping Rancher on a public one.

Subnets are:

  • 10.11.1.0/24 Public subnet with Rancher installed and the nat gateway for the private subnet 10.11.2.0/24. I configured also access from this subnet to 10.11.0.0/16.
  • 10.11.2.0/24 Private subnet where all nodes are deployed with access to the internet through the nat gateway and access to 10.11.0.0/16

After configuring the networks correctly and ensured that 10.11.2.0/24 has access to the internet through the nat gateway and to 10.11.0.0/16 to talk with the Rancher server and after made sure that Rancher can access 10.11.0.0/16, I launched the creation of the cluster with 3 nodes and everything seems to work except that when I create a workload and I expose it selecting Load Balancer Layer 4 it stays in Pending on the Rancher UI and stays there forever no errors in the Rancher docker logs. It just hangs and does not create anything on AWS.

Instead if I deploy to public IPs nodes when I deploy a workload and I create a load balancer everything works.

Hi Vincent,

Thanks a lot for your answer. Like every service, K8s, SSH, … can have 0 day. So every admin should try to not open SSH to the world or any other port and try to don’t open unnecessary port even if it’s a private network.

We should have an option to avoid Rancher to change our security group (especially if we select an existing security group). Do you plan to add this option?

So we switch to use Custom Cluster with AWS option enable for the moment.

Although old, this post is still up-to-date as this problem persist.

I must say that hearing something like “there is nothing particularly “bad” about exposing ssh (with only key auth possible) or the secure docker port (which requires the tls private key).” from a rancher developer, increases my idea that rancher is “insecure by default”.

Exposing services to the internet just for the sake of it it’s a totally wrong way of trying to have a production grade product. Ssh is not a perfect protocol, neither is tls.

“30000-32767 is the default node port range. When most users expose a service as a NodePort, they expect to be able to reach it.” People should expect to work correctly and expose it through a load balancer or only through a VPN, no to 0.0.0.0/0. All other points can be answered the same way.

“TL;DR: If you want full control over what is exposed and how then you are going to have to make your own instances and register them as a custom cluster. And most people asking these sorts of questions would be using private-ip-only instances.” Custom clusters doesn’t have the same properties as rancher ones, we should expect a certain grade of security.

Totally disappointed by the answer from a rancher developer, hopefully this path to insecurity will be addressed.