7.2. User Management

When to Look at This

• When giving a new team member access to the cluster
• When checking who holds which permissions
• When sign-in works but the screen is empty

Users and Groups

The Console signs in with accounts registered on the integrated authentication server (SSO). On this screen you view the registered users and groups and attach cluster access permissions.

Granting permissions per person means adjusting them whenever staffing changes. Granting permissions to a group and putting people in the group is easier to manage. This screen is built around groups for that reason.

The User List

Go to User Management > Users.

Column	Description
User name	The account used to sign in
Name	The display name
Email	The registered address
Groups	The groups they belong to. Selecting one goes to that group's permission screen

This screen is read-only. Creating and deleting users is done on the integrated authentication server. The Console only attaches cluster permissions to those accounts.

The User Group Screen

View the group list under User Management > User Groups. Selecting a group name opens the permission editor on the right.

The unit of editing is one role card = one role. A group can have several roles, and the scope is set separately for each.

How to Choose a Role

Selecting Add role shows the list of roles you can choose from.

There are conditions on which roles appear in the list.

Condition	Description
Roles marked as managed	Roles that operations staff marked as "this role may be granted from the screen"
cluster-admin	The cluster-wide administrator. It always appears, as an exception

Roles without the marker do not appear in the list. A cluster has dozens of roles created by the tools installed on it, and showing them all would make the role you need impossible to find. If a role you need is not visible, ask operations staff to add it to the list.

Namespace-scoped roles (Role) can share a name across namespaces, so they appear in the form name (namespace).

Choosing Between RoleBinding and ClusterRoleBinding

After choosing a role, decide how to attach it within the card.

Method	Scope	Namespace selection
RoleBinding	Only the selected namespaces	Several can be selected
ClusterRoleBinding	All namespaces	The selection field disappears

The default is RoleBinding. It is the safer side, with a narrower scope.

Granting one role across several namespaces is common. For example, to give the development team edit permission on both the dev and test namespaces, select both namespaces in one role card.

A ClusterRoleBinding applies to every namespace, including kube-system. Use it only when truly necessary.

Saving Several Changes at Once

Adding or removing roles does not take effect immediately; a change count and a save bar appear at the bottom of the screen.

1. Make all the changes you need.
2. Review the changes in the save bar at the bottom.
3. Selecting Save opens a confirmation window.
4. Progress is shown per item. If some fail, only those items can be retried.

Selecting Revert returns to the state before saving.

The order of application is revocations first, grants second. This prevents an intermediate state where permissions are wrongly widened.

When the Default Roles Are Missing

If the default roles are not prepared on the cluster, a guidance banner appears at the top of the screen. The Create default roles button creates them.

Three roles are created.

Role	Permissions
cop-cluster-users	Can create and edit resources (edit)
cop-cluster-viewers	Can view resources (read)
cop-namespace-lister	Can view the namespace list

cop-namespace-lister is needed for the screen to work. Without it, sign-in succeeds but the namespace selector appears empty and no lists are shown.

If they already exist, only missing rules are filled in, so selecting it several times is safe.

The Objects the Console Creates

Bindings the Console created carry a marker and their names begin with cop-.

Name	What it is
cop-access-*	A namespace-scoped binding
cop-cluster-access-*	A cluster-wide binding
cop-group-*-ns-lister	An automatic binding for listing namespaces

Bindings the Console did not create cannot be edited. Changing something another person created from the command line would conflict with how they manage it. Such bindings are marked "externally managed", and if necessary you can select Take over in Console to adopt it and then edit it.

When Access Does Not Work

Symptom	What to check
Sign-in works but the screen is empty	Whether cop-namespace-lister is attached to that group
Only some menus appear	Menus are hidden based on permissions. Whether you have view permission on the resources you need
Group permissions do not apply	The group name spelling, and whether the authentication server passes group information
The group list is empty	The authentication server connection. You can also specify it by typing it directly

If group information is not reflected after signing in, sign out and sign in again. Permissions are carried in the token issued at sign-in time.