We installed a Rancher production cluster (K8s installation with 3 nodes as per documentation) and configured AD authentication.
However we can see that even if we set a cluster member with extremely limited roles, the user can still access the member menu and list users from the AD without restriction.
The User cannot add a user from the AD nor create a local user but having a standard user being able to read an entire AD doesn’t seem secure to the standpoint of GDPR…
Is this by design ?
Is there a way to fix this besides not using AD authentication ?
Yes, it is intentional.
AD, and every provider we support (other than public GitHub, but that’s also publicly searchable) are closed communities of generally related people, like a company’s employees). In many of them, including standard AD installations, the user’s credentials on their own are enough to get everything we show and much more.
A default Rancher user can create clusters and projects within them, and invite users/groups to manage them. Those users do not have to have logged in to Rancher yet. If you can’t lookup users, then you can’t share anything.
Rancher is not a hosted service; what you do with our software and how GDPR applies between you and your users is entirely up to you.
Thanks for your reply.
That’s unfortunate as we were planning to use it in a multitenant way and we can’t have customer A users see customer B users…
Guess we will stick with local user authentication.
I still think that users without user management permission shouldn’t be able to browse the AD
Local is the same situation so I’m not sure what you’re gaining there. Principals are a global virtual resource any user can access to find others to invite as members.
The only ones that aren’t really searchable, because there’s no standard for it, are the SAML-based providers.
I just have tested and with local authentication a simple user without user management role cannot see other users and cannot find other users (even users who are member of the cluster) with the “add member” menu.
Anyway we have a commercial meeting with someone from Rancher this afternoon so maybe we can talk about this with him
Users (/v3/users) are not the right resource to look at. They are the “physical” account of a person and there is a database entry for each one. These are already only manageable by admins (or a user with “manage users” or equivalent).
You want to be looking at Principals (/v3/principals & /v3/principals?name=a), which are a “virtual” resource that are listed from and searched by the underlying auth provider (for local, we are both and this is a 1:1 mapping, for others there will be Principals for people that have never logged in and have no User)… These are searchable by any User, to the extent we can do given the particulars of the auth provider and how the searching user logged in.
Thanks for the clarification.
We have discussed with a rancher rep yesterday and he will check if something can be done on that topic.
I really think a user without member management permission shouldn’t have access to the member section of the GUI/API