I’m getting confused by the documentation around remote authentication. The documentation at: http://docs.rancher.com/rancher/latest/en/configuration/access-control/ suggests remotely authenticated users are given an admin level account. “You will also be logged in as an admin of Rancher.”
The account which enables access control (in the “test and enable” section) becomes the (only) admin at that time.
After access control is on, you can mark additional individual accounts as admins (after that person has logged in once, for us to create an account entry and show up in the Accounts tab).
You can also downgrade yourself from Admin to User, after there is another Admin defined.
Admin-ness is directly stored in the Rancher DB. There is not currently a way to derive it by a user’s membership in a group/org according the auth provider.
Being an admin allows you to use the stuff in the Admin tab, which is primarily system-wide configuration. And also to manipulate any Environment (without having to be a member of it).
Environments have a separate, unrelated concept of Role. Users/groups/orgs can be added as a member of an Environment, and given (currently) 4 levels of control over that environment. This is the level that controls access to individual resources like Hosts.
For #4 and #6, when can we have the feature to easily assign group (not users) in ldap (or other auth providers) with Rancher access control permission and Environment membership roles?
That exists for Environment membership (#6) today, you can add a group/org to an Environment and assign them a role.
It could be done for Admin (#4) too, but doesn’t exist today. It’s mostly a question of moving the storage of the admin bit from Accounts and into a list of Identities, handling backwards compatibility/migration, and writing some logic in the UI that attempts to prevent you from accidentally locking yourself out by removing the last entry which causes you to be an Admin.