4. User Management¶
Kubernetes User Management
Kubernetes clusters support two categories of users: service accounts, and normal users (users). Service accounts are managed by the Kubernetes cluster. Kubernetes doesn’t have a mechanism for managing users, however. In fact, it doesn’t even contain an object that represents a user, nor is there any way for a user to log into a Kubernetes cluster. In a Kubernetes cluster, user management is off-loaded to an external facility or auth provider.
Namespaces
Kubernetes provides a construct, called ‘namespace’, which allows a cluster to be partitioned into multiple “virtual clusters”. Names for resources deployed in a namespace must be unique, however that restriction does not apply acrosss namespaces. In addition to isolating application resources, namespaces also provide a way to isolate groups of users and aportion cluster resources to those groups.
Usernames
In a Kubernetes cluster, each user is identified by a unique username and possibly one or more affiliated group names. Kubernetes maps (binds) the username and affiliated group names to roles that define which resources can be accessed and which operations can be performed on those resources. These role bindings can apply to a specific namespace or they can apply across the entire cluster (namespaced roles bindings cannot reference more than one namespace).
There are no hard and fast rules regarding what form a Kubernetes username may take. It may be a user’s email address that they use when authenticating themselves with an Auth Provider. Or it may be an arbitrary name that is encoded in an externally generated TLS certificate. Whatever username is specified, it needs to map to role bindings that provide full access to the namespace where the user’s applications are deployed (this should already be the case if the user used helm or an operator to deploy their application). It is beyond the scope of this document to determine how Kubernetes users should be managed. The following command can be used, however, to ensure that a username is mapped to a role with adequate permissions for a specific namespace:
$ kubectl create rolebinding <role_binding_name> --clusterrole=edit --user=<username> -n=<namespace>
Authentication and Authorization
Each time a user issues a kubectl or helm command, their credentials (bearer token, TLS certificate, username/password, etc.) are sent on their behalf to the Kubernetes API server. There, the API server performs a user authentication check and if the user is authenticated, the user’s username and group names are matched against role bindings, to determine if the user is authorized to perform the requested operation. If the user is not authenticated, or the user does not have adequate permissions to perform the operation, then an error will be returned.
ROBIN User Management
ROBIN clusters include a robust user management system with Role Based Access Control (RBAC) that allows fine grain control of what operations each user is able to perform in the ROBIN cluster and which resources they are able to access.
Tenants
Tenants are a construct within ROBIN Platform that allow users to be organized into descrete groups based on function or business requirements. A user can be a member of multiple tenants, however, they are only able to access resources that are bound to the tenant they are currently logged into (e.g., a user would not be able to access resources for an application they deployed when logged into a different tenant). Note that in ROBIN Storage, all users who will be managing Kubernetes stateful applications (created by helm, operators, etc.), are grouped together in a single tenant called K8sCluster
.
User Roles
ROBIN users are assigned a user role for each tenant they are a member of. The user role determines which capabilities they have and which objects they are able to access. Users who are members of multiple tenants can have a different user role in each of the tenant they are a member of. Note that ROBIN Storage only supports one tenant, which is K8sCluster
. Members of this tenant can be assigned one of two user roles:
clusteradmin
A user who is assigned the clusteradmin role has full access to all ROBIN API endpoints, can view all resources, and is able to perform all administrative functions in the ROBIN cluster, such as adding users to the cluster, registering and sharing storage repositories, exporting/importing application backups, etc.
clusteruser
A user who is assigned the clusteruser role has no cluster admin capabilities and is, generally speaking, limited to managing the applications they have registered.
User Administration
Before a user can begin to use ROBIN to manage their applications, they need to log into the ROBIN cluster using the ROBIN CLI utility. Before they can do that, however, they need a user account. ROBIN user accounts are created by the cluster administrator (a user having the clusteradmin role). The following information needs to be supplied when creating a user account:
username (must be unique within the ROBIN cluster)
role (
clusteradmin
orclusteruser
)namespace (the Kubernetes namespace where the user’s applications are deployed)
Kubernetes username (must have adequate role bindings to manage applications in the specified namespace)
Affiliated group names (optional)
Initial password
ROBIN will generate a TLS certificate for each user added to the cluster. The certificate includes the user’s Kubernetes username and any affiliated group names. ROBIN will pass this certificate to the Kubernetes API server any time it makes a call on the user’s behalf. Note that role bindings with adequate permissions to manage applications in the specified namespace (bound to the user’s Kubernetes username and/or group names) must already exist before a user’s account is created. A validity test will be performed to ensure the user has adequate permissions and the user account will only get added if they do.
Before a user can make use of the ROBIN CLI, they must first authenticate themselves to the ROBIN cluster. They do this by issuing the following command:
$ robin login <username>
which prompts the user to enter their password. Upon a successful login, a token is returned that identifies the user, the tenant they are currently logged into, and their current namespace. This token is stashed in the user’s home directory, to be used with each successive commands the user issues.
Topics covered in this chapter:
|
Log a user into the ROBIN cluster |
|
Change the password for the current ROBIN user |
|
Add a new user to the ROBIN cluster |
|
List ROBIN cluster users |
|
Update a user |
|
Remove a user from the ROBIN cluster |
|
Change the current namespace for a ROBIN user |
4.1. User Login¶
Initiate a ROBIN cluster login session:
$ robin login username
[--password <password>]
[--tenant <tenant>]
[--namespace <namespace>]
|
The username for the user logging into the ROBIN cluster
|
|
User password (for testing purposes only)
|
|
Name of tenant the user will be logged into (default is the same tenant from previous login).
|
|
Change the current namespace for the user who is logging in (note that this option is only valid when a user is logging into the ‘K8sCluster’ tenant).
|
4.2. Change Current User’s Password¶
Change the password for the current ROBIN user:
$ robin password change
4.3. Add a User¶
Add a new user to the ROBIN cluster:
$ robin user add username cluster_username tenant_role [namespace]
[--password <password>]
[--ldap]
[--ldap-server <ldap_server>]
[--first-name <first_name>]
[--last-name <last_name>]
[--email <email_address]
[--setup-tiller]
[--cluster-groups <cluster_groups>]
[--context-name <context_name>]
[--auth-type <auth_type>]
[--bearer-token <bearer_token>]
[--cert-data <cert_data>]
[--key-data <key_data>]
[--cert-file <cert_file>]
[--key-file <key_file>]
|
The user’s ROBIN cluster username. Note that this username can only contain .-_ and alphanumeric characters.
|
|
The user’s K8s cluster username. Note that this namespace can only contain .-_@ and alphanumeric characters.
|
|
Role to assign to the user (clusteradmin or clusteruser)
|
|
The K8s namespace to set as the current namespace. Note that the namespace specified must be a valid namespace (default namespace is ‘default’)
|
|
User password (for testing purposes only)
|
|
Authentication with an ldap server
|
|
Name of LDAP server user will get authentication from.
|
|
First name for user being added
|
|
Last name for user being added
|
|
Email address for user being added
|
|
Setup all k8s objects required for a user deployment
|
|
A comma separated list of groups the cluster user is a member of, which it’s assumed are mapped to k8s cluster and namespaced role bindings
|
|
User context name for the user
|
|
The type of auth credentials to use (valid options are AUTH_CERT and AUTH_BEARER_TOKEN)
|
|
Bearer token
|
|
Certificate data
|
|
Key data
|
|
Certificate file
|
|
Key file
|
Note
The ability to add users is subject to ROBIN Role Based Access Control (RBAC). By default, only Cluster Administrators (users having the clusteradmin role) have permission to do so.
4.4. List Users¶
List information about ROBIN users:
$ robin user list [username]
[--all, -a]
[--full]
[--permissions]
|
The username of the ROBIN user to display information for
|
|
List all users including hidden, disabled, and deleted users
|
|
Display additional information about each user (e.g., access permissions)
|
|
List individual user permissions
|
Note
The ability to list users is subject to ROBIN Role Based Access Control (RBAC). By default, only Cluster Administrators (users having the clusteradmin role) have permission to do so.
4.5. Update a User¶
Update a ROBIN user’s attributes:
$robin user update username
[--password, -p]
[--first-name <first_name>]
[--last-name <last_name>]
[--email <email_address>]
|
The username for the ROBIN user to update attributes for
|
|
Change a user’s password
|
|
First name for user being added
|
|
Last name for user being added
|
|
Email address for user being added
|
Note
The ability to update users is subject to ROBIN Role Based Access Control (RBAC). By default, only Cluster Administrators (users having the clusteradmin role) have permission to do so.
4.6. Remove a User¶
Remove a ROBIN user:
$ robin user remove username
[--yes, -y]
|
Comma separated list of usernames for user being removed (can be a single also)
|
|
Do not prompt the user for confirmation
|
Note
The ability to remove users is subject to ROBIN Role Based Access Control (RBAC). By default, only Cluster Administrators (users having the clusteradmin role) have permission to do so.
4.7. Change Current Namespace¶
Change the current namespace for the current ROBIN user:
$ robin user change-namespace namespace
|
The namespace to set as current namespace
|