What's the best practice for securing Rancher access/login?

Rancher 2.x
1

Hi all,

I’m very happy with Rancher so far and I’ve been able to get several clusters running now on bare metal.

I have a question about securing access to Rancher itself. Currently I have it hosted on a K8s cluster, and use that to deploy several other RKE clusters in different points of presence. The problem is that Rancher itself is accessible via a URL. I’ve already added TLS and am using Github sign in, but I am concerned that an attacker who stumbles on the URL can use a brute force attack on the admin login. As far as I know, there is no recaptcha or any kind of rate limiting.

What is the best practice for making Rancher not accessible to the public?

Thank you so much for making such a great tool.

Leo

2

Hi, I am still stuck with this issue and unfortunately it may cause us to not use Rancher. As it stands, Rancher appears to be insecure because the login screen is public and the admin login appears to be susceptible to brute force login attacks (unless there is some protection I’m unaware of?).

I have tried to use Cloudflare Access to block access to Rancher, but it requires me to whitelist most paths (/v3, /k8s, etc.) so that the clusters can communicate with Rancher.

Does anyone have any experience with securing the admin login for Rancher?

Thanks.

3

If you really don’t want it to be public, then don’t publish it to the general internet…

But local user passwords are bcrypt-hashed and take ~50-100ms per attempt to validate. You also don’t have to keep the default admin user, nor any other local users. Or you can set the password to 1,000 random characters.

There’s no reason for brute forcing to be remotely practical.

4

Perfect. Thanks for that Vincent. It puts my mind at ease.

Regarding this: “If you really don’t want it to be public, then don’t publish it to the general internet…” on a practical level, how would one do this if the clusters being managed are dispersed? I’m using Rancher to deploy clusters in different geographic zones in separate datacenters, different networks, so they all still have to connect to Rancher. Also, from what I saw, cert-manager webhooks have to be exposed to receive callbacks (I think).

I was able to use Cloudflare Access to block off /login, so that also solves it but your suggestions to remove the admin user, etc is a good one.

Thanks again for your help, it’s much appreciated.

Leo

5

Overlay networks or vpns…

The UI is all static JS files that make API calls; blocking /login isn’t doing anything, it’s one of infinite paths that return the HTML that loads the UI. You’d want to block the API, posts to /v3-public/authConfigs/...).

1 Like
6

You could use another auth/user account provider that has locking on failed attempts. Rancher supports SAML so you can pull in Okta, AD etc users.

1 Like
7

Thanks for the help! I will block the API requests to the authConfigs.
As you both mentioned also we can change/remove the default admin user and use other auth providers. We’ve hooked it up with our company auth which has 2 factor.

Thanks again.