How to mapping Rancher environment roles and ldap groups

Archive Rancher 1.x
1

We created rancher server and use the default environment. successfully set access control with openldap.

But I found, the ldap user who login Rancher isn’t automatically assigned to default environment.

Second, how can I manage the user’s membership roles directly from LDAP groups, so I needn’t do it manually or through API to assign roles for each user?

2

@vincent

Any suggestions for my questions?

3

For the first part of your question: you can invite the ldap users to the default environment as “members”. On login those users will then get access to the default environment instead of their own separate environment.

4

Thanks, @prachi.

We need automate these, no any manual job involved.

So I am looking for the solution to get the ldap users (belong in particular ldap groups) to be member directly for default environment.

Then mapping the ldap groups to rancher’s membership roles, that’s second step.

Currently, if the ldap user doesn’t login Rancher server, the rancher admin can’t manually invite it at all, because the users are not exist in Rancher. We have hundreds of ldap accounts, it is not possible to manually do that, to wait user login rancher first, then ask rancher admin to add it to default environment and assign membership roles.

5

If groups are configured correctly in the openldap config then you can add a group (not just an individual user) as a member of an environment and all members of that group will be able to use it.

Individual users (or another group) can be added separately with a different permission (e.g. Owner vs Member) and users will get the highest their address eligible for.

All the auth providers (except for local where it makes no sense) allow you to add members by name for a person who has not created an account yet (and therefore does not appear in the accounts list).

So either you are confused there, or are actually talking about managing the users access to Rancher as a whole, vs individual environments. You cannot make a group or person who doesn’t have an account yet an Admin, for example.

These are 2 separate concepts that may be getting confused:

Account kind: affects the whole install

  • User: can use the environments they are given access to
  • Admin: can do anything, use any environment, configure auth, etc.

Environment member role (called projectMember in API): affects a single environment

  • Readonly: can see but not change anything
  • Restricted: can manage stacks/services/containers but not hosts
  • Member: can manage all resources in the project
  • Owner: member + can manage the membership list & roles.