2 - 集群和项目角色
Cluster and project roles define user authorization inside a cluster or project. You can manage these roles from the Global > Security > Roles page.
Membership and Role Assignment
The projects and clusters accessible to non-administrative users is determined by membership. Membership is a list of users who have access to a specific cluster or project based on the roles they were assigned in that cluster or project. Each cluster and project includes a tab that a user with the appropriate permissions can use to manage membership.
When you create a cluster or project, Rancher automatically assigns you as the
Owner for it. Users assigned the
Owner role can assign other users roles in the cluster or project.
Note: Non-administrative users cannot access any existing projects/clusters by default. A user with appropriate permissions (typically the owner) must explicitly assign the user membership.
Cluster roles are roles that you can assign to users, granting them access to a cluster. There are two primary cluster roles:
These users have full control over the cluster and all resources in it.
These users can view most cluster level resources and create new projects.
Custom Cluster Roles
Rancher lets you assign custom cluster roles to a user instead of the typical
Member roles. These roles can be either a built-in custom cluster role or one defined by a Rancher administrator. They are convenient for defining narrow or specialized access for a user within a cluster. See the table below for a list of built-in custom cluster roles.
Cluster Role Reference
The following table lists each built-in custom cluster role available in Rancher and whether it is also granted by the
|Custom Cluster Role||Owner||Member|
|Manage Cluster Members||✓|
|View All Projects||✓|
|View Cluster Members||✓||✓|
Note: Each cluster role listed above, including
Member, is comprised of multiple rules granting access to various resources. You can view the roles and their rules on the Global > Security > Roles page.
Project roles are roles that can be used to grant users access to a project. There are three primary project roles:
These users have full control over the project and all resources in it.
These users can manage project-scoped resources like namespaces and workloads, but cannot manage other project members.
These users can view everything in the project but cannot create, update, or delete anything.
Users assigned the
Memberrole for a project automatically inherit the
namespace creationrole. However, this role is a Kubernetes ClusterRole, meaning its scope extends to all projects in the cluster. Therefore, users explicitly assigned the
memberrole for a project can create namespaces in other projects they’re assigned to, even with only the
Read Onlyrole assigned.
Custom Project Roles
Rancher lets you assign custom project roles to a user instead of the typical
Read Only roles. These roles can be either a built-in custom project role or one defined by a Rancher administrator. They are convenient for defining narrow or specialized access for a user within a project. See the table below for a list of built-in custom project roles.
Project Role Reference
The following table lists each built-in custom project role available in Rancher and whether it is also granted by the
Read Only role.
Note: Each project role listed above, including Owner, Member, and Read Only, is comprised of multiple rules granting access to various resources. You can view the roles and their rules on the Global > Security > Roles page.
Defining Custom Roles
As previously mentioned, custom roles can be defined for use at the cluster or project level. The context field defines whether the role will appear on the cluster member page, project member page, or both.
When defining a custom role, you can grant access to specific resources or specify roles from which the custom role should inherit. A custom role can be made up of a combination of specific grants and inherited roles. All grants are additive. This means that defining a narrower grant for a specific resource will not override a broader grant defined in a role that the custom role is inheriting from.
Default Cluster and Project Roles
By default, when a user creates a new cluster or project, they are automatically assigned an ownership role: either cluster owner or project owner. However, in some organizations, these roles may overextend administrative access. In this use case, you can change the default role to something more restrictive, such as a set of individual roles or a custom role.
There are two methods for changing default cluster/project roles:
For example, instead of assigning a role that inherits other roles (such as
cluster owner), you can choose a mix of individual roles (such as
- Although you can lock a default role, the system still assigns the role to users who create a cluster/project.
- Only users that create clusters/projects inherit their roles. Users added to the cluster/project membership afterward must be explicitly assigned their roles.
Configuring Default Roles
You can change the cluster or project role(s) that are automatically assigned to the creating user.
From the Global view, select Security > Roles from the main menu. Select either the Cluster or Project tab.
Find the custom or individual role that you want to use as default. Then edit the role by selecting Ellipsis > Edit.
Enable the role as default.
- From Clustor Creator Default, choose Yes: Default role for new cluster creation.
- Click Save.
- From Project Creator Default, choose Yes: Default role for new project creation.
- Click Save.
If you want to remove a default role, edit the permission and select No from the default roles option.
Result: The default roles are configured based on your changes. Roles assigned to cluster/project creators display a check in the Cluster/Project Creator Default column.
Cluster Membership Revocation Behavior
When you revoke the cluster membership for a user that’s explicitly assigned membership to both the cluster and a project within the cluster, that user loses their cluster roles but retains their project roles. In other words, although you have revoked the user’s permissions to access the cluster and its nodes, the user can still:
- Access the projects they hold membership in.
- Exercise any individual project roles they are assigned.
If you want to completely revoke a user’s access within a cluster, revoke both their cluster and project memberships.