We are trying to automate the installation of Rancher. One of the last steps is to enable LDAP authentication and assign access rights to groups in LDAP via the API. While this works we are missing on crucial element, how to give Rancher Admin role to a LDAP user? When enabling LDAP via the GUI, the person to enable LDAP becomes the admin.
We couldn’t figure out how to create a Rancher Admin user out of an ldap user over the API after LDAP has been enabled? We enable LDAP with API keys which have been created for a local admin account that has been created in the previous steps while local authentication is still enabled…
Is there a way to make a single LDAP user or a LDAP group Rancher admins via the API? For environments admins this works fine, but couldnt figure out how to do it in Ranchel level.
TL;DR: You can make users an admin once they’ve logged in, but not before.
First terminology clarifications:
Environments have members and owners (not admins).
The global Rancher installation as a whole has users and users that are admins.
And environments are called projects in the API, because…reasons.
People and groups in the external auth system (LDAP here) can be searched for with the identities endpoint; e.g. GET /v2-beta/identities?name=terozio. This can return anything under the configured search base, regardless of whether that person has ever logged in to Rancher.
Projects have a list of projectMembers which is a list of identities who have access to the project and what role they have. You can update the list of member identities and their allowed role with the setMembers action on the project.
When a person logs into Rancher for the first time, an account entry is created for their identity. So all the resources inside Rancher are owned by an account, and n account has an associated identity (which maps to something in LDAP here).
The accounts then have a kind field, which is either user or admin. So to make someone an admin, they must first have logged in (so that they have an account entry) and then an admin (or the API key of one) can update their account to make their kind=admin.
There is an initial id=1a1 admin account in the database on first startup, and when access control is off everyone is implicitly that account. When you turn access control on, the admin account is updated and the person that’s enabling auth becomes the existing 1a1 account and therefore the admin.
There is not currently a way to make an arbitrary identity (user or group) that does not have an account in Rancher yet preemptively an admin. We are planning to address this with RBAC improvements in 2.0 so that you can optionally have e.g. an “admins” LDAP group and membership in that determines your access rather than the source of truth being in Rancher.