mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 20:48:11 +00:00
Remove unneeded intermediate folders
This commit is contained in:
Billy Tat
+195
@@ -0,0 +1,195 @@
|
||||
---
|
||||
title: Cluster and Project Roles
|
||||
weight: 1127
|
||||
aliases:
|
||||
- /rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/
|
||||
---
|
||||
|
||||
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 project and cluster membership.
|
||||
|
||||
### Cluster Roles
|
||||
|
||||
_Cluster roles_ are roles that you can assign to users, granting them access to a cluster. There are two primary cluster roles: `Owner` and `Member`.
|
||||
|
||||
- **Cluster Owner:**
|
||||
|
||||
These users have full control over the cluster and all resources in it.
|
||||
|
||||
- **Cluster Member:**
|
||||
|
||||
These users can view most cluster level resources and create new projects.
|
||||
|
||||
#### Custom Cluster Roles
|
||||
|
||||
Rancher lets you assign _custom cluster roles_ to a standard user instead of the typical `Owner` or `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 standard 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 and whether that level of access is included in the default cluster-level permissions, `Cluster Owner` and `Cluster Member`.
|
||||
|
||||
| Built-in Cluster Role | Owner | Member <a id="clus-roles"></a> |
|
||||
| ---------------------------------- | ------------- | --------------------------------- |
|
||||
| Create Projects | ✓ | ✓ |
|
||||
| Manage Cluster Backups | ✓ | |
|
||||
| Manage Cluster Catalogs | ✓ | |
|
||||
| Manage Cluster Members | ✓ | |
|
||||
| Manage Nodes | ✓ | |
|
||||
| Manage Storage | ✓ | |
|
||||
| View All Projects | ✓ | |
|
||||
| View Cluster Catalogs | ✓ | ✓ |
|
||||
| View Cluster Members | ✓ | ✓ |
|
||||
| View Nodes | ✓ | ✓ |
|
||||
|
||||
For details on how each cluster role can access Kubernetes resources, you can go to the **Global** view in the Rancher UI. Then click **Security > Roles** and go to the **Clusters** tab. If you click an individual role, you can refer to the **Grant Resources** table to see all of the operations and resources that are permitted by the role.
|
||||
|
||||
> **Note:**
|
||||
>When viewing the resources associated with default roles created by Rancher, if there are multiple Kubernetes API resources on one line item, the resource will have `(Custom)` appended to it. These are not custom resources but just an indication that there are multiple Kubernetes API resources as one resource.
|
||||
|
||||
### Giving a Custom Cluster Role to a Cluster Member
|
||||
|
||||
After an administrator [sets up a custom cluster role,]({{<baseurl>}}/rancher/v2.5/en/admin-settings/rbac/default-custom-roles/) cluster owners and admins can then assign those roles to cluster members.
|
||||
|
||||
To assign a custom role to a new cluster member, you can use the Rancher UI. To modify the permissions of an existing member, you will need to use the Rancher API view.
|
||||
|
||||
To assign the role to a new cluster member,
|
||||
|
||||
1. Go to the **Cluster** view, then go to the **Members** tab.
|
||||
1. Click **Add Member.** Then in the **Cluster Permissions** section, choose the custom cluster role that should be assigned to the member.
|
||||
1. Click **Create.**
|
||||
|
||||
**Result:** The member has the assigned role.
|
||||
|
||||
To assign any custom role to an existing cluster member,
|
||||
|
||||
1. Go to the member you want to give the role to. Click the **⋮ > View in API.**
|
||||
1. In the **roleTemplateId** field, go to the drop-down menu and choose the role you want to assign to the member. Click **Show Request** and **Send Request.**
|
||||
|
||||
**Result:** The member has the assigned role.
|
||||
|
||||
### Project Roles
|
||||
|
||||
_Project roles_ are roles that can be used to grant users access to a project. There are three primary project roles: `Owner`, `Member`, and `Read Only`.
|
||||
|
||||
- **Project Owner:**
|
||||
|
||||
These users have full control over the project and all resources in it.
|
||||
|
||||
- **Project Member:**
|
||||
|
||||
These users can manage project-scoped resources like namespaces and workloads, but cannot manage other project members.
|
||||
|
||||
>**Note:**
|
||||
>
|
||||
>By default, the Rancher role of `project-member` inherits from the `Kubernetes-edit` role, and the `project-owner` role inherits from the `Kubernetes-admin` role. As such, both `project-member` and `project-owner` roles will allow for namespace management, including the ability to create and delete namespaces.
|
||||
|
||||
- **Read Only:**
|
||||
|
||||
These users can view everything in the project but cannot create, update, or delete anything.
|
||||
|
||||
>**Caveat:**
|
||||
>
|
||||
>Users assigned the `Owner` or `Member` role for a project automatically inherit the `namespace creation` role. However, this role is a [Kubernetes ClusterRole](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole), meaning its scope extends to all projects in the cluster. Therefore, users explicitly assigned the `owner` or `member` role for a project can create namespaces in other projects they're assigned to, even with only the `Read Only` role assigned.
|
||||
|
||||
#### Custom Project Roles
|
||||
|
||||
Rancher lets you assign _custom project roles_ to a standard user instead of the typical `Owner`, `Member`, or `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 standard 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 `Owner`, `Member`, or `Read Only` role.
|
||||
|
||||
| Built-in Project Role | Owner | Member<a id="proj-roles"></a> | Read Only |
|
||||
| ---------------------------------- | ------------- | ----------------------------- | ------------- |
|
||||
| Manage Project Members | ✓ | | |
|
||||
| Create Namespaces | ✓ | ✓ | |
|
||||
| Manage Config Maps | ✓ | ✓ | |
|
||||
| Manage Ingress | ✓ | ✓ | |
|
||||
| Manage Project Catalogs | ✓ | | |
|
||||
| Manage Secrets | ✓ | ✓ | |
|
||||
| Manage Service Accounts | ✓ | ✓ | |
|
||||
| Manage Services | ✓ | ✓ | |
|
||||
| Manage Volumes | ✓ | ✓ | |
|
||||
| Manage Workloads | ✓ | ✓ | |
|
||||
| View Secrets | ✓ | ✓ | |
|
||||
| View Config Maps | ✓ | ✓ | ✓ |
|
||||
| View Ingress | ✓ | ✓ | ✓ |
|
||||
| View Project Members | ✓ | ✓ | ✓ |
|
||||
| View Project Catalogs | ✓ | ✓ | ✓ |
|
||||
| View Service Accounts | ✓ | ✓ | ✓ |
|
||||
| View Services | ✓ | ✓ | ✓ |
|
||||
| View Volumes | ✓ | ✓ | ✓ |
|
||||
| View Workloads | ✓ | ✓ | ✓ |
|
||||
|
||||
> **Notes:**
|
||||
>
|
||||
>- 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.
|
||||
>- When viewing the resources associated with default roles created by Rancher, if there are multiple Kubernetes API resources on one line item, the resource will have `(Custom)` appended to it. These are not custom resources but just an indication that there are multiple Kubernetes API resources as one resource.
|
||||
>- The `Manage Project Members` role allows the project owner to manage any members of the project **and** grant them any project scoped role regardless of their access to the project resources. Be cautious when assigning this role out individually.
|
||||
|
||||
### 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 standard user creates a new cluster or project, they are automatically assigned an ownership role: either [cluster owner](#cluster-roles) or [project owner](#project-roles). 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:
|
||||
|
||||
- **Assign Custom Roles**: Create a [custom role]({{<baseurl>}}/rancher/v2.5/en/admin-settings/rbac/default-custom-roles) for either your [cluster](#custom-cluster-roles) or [project](#custom-project-roles), and then set the custom role as default.
|
||||
|
||||
- **Assign Individual Roles**: Configure multiple [cluster](#cluster-role-reference)/[project](#project-role-reference) roles as default for assignment to the creating user.
|
||||
|
||||
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 `manage nodes` and `manage storage`).
|
||||
|
||||
>**Note:**
|
||||
>
|
||||
>- Although you can [lock]({{<baseurl>}}/rancher/v2.5/en/admin-settings/rbac/locked-roles/) 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 for Cluster and Project Creators
|
||||
|
||||
You can change the cluster or project role(s) that are automatically assigned to the creating user.
|
||||
|
||||
1. From the **Global** view, select **Security > Roles** from the main menu. Select either the **Cluster** or **Project** tab.
|
||||
|
||||
1. Find the custom or individual role that you want to use as default. Then edit the role by selecting **⋮ > Edit**.
|
||||
|
||||
1. Enable the role as default.
|
||||
|
||||
<details id="cluster">
|
||||
<summary>For Clusters</summary>
|
||||
|
||||
1. From **Cluster Creator Default**, choose **Yes: Default role for new cluster creation**.
|
||||
1. Click **Save**.
|
||||
|
||||
</details>
|
||||
<details id="project">
|
||||
|
||||
<summary>For Projects</summary>
|
||||
1. From **Project Creator Default**, choose **Yes: Default role for new project creation**.
|
||||
1. Click **Save**.
|
||||
|
||||
</details>
|
||||
|
||||
1. 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 standard user that's explicitly assigned membership to both the cluster _and_ a project within the cluster, that standard user [loses their cluster roles](#clus-roles) but [retains their project roles](#proj-roles). In other words, although you have revoked the user's permissions to access the cluster and its nodes, the standard user can still:
|
||||
|
||||
- Access the projects they hold membership in.
|
||||
- Exercise any [individual project roles](#project-role-reference) they are assigned.
|
||||
|
||||
If you want to completely revoke a user's access within a cluster, revoke both their cluster and project memberships.
|
||||
+141
@@ -0,0 +1,141 @@
|
||||
---
|
||||
title: Custom Roles
|
||||
weight: 1128
|
||||
aliases:
|
||||
- /rancher/v2.5/en/tasks/global-configuration/roles/
|
||||
- /rancher/v2.x/en/admin-settings/rbac/default-custom-roles/
|
||||
---
|
||||
|
||||
Within Rancher, _roles_ determine what actions a user can make within a cluster or project.
|
||||
|
||||
Note that _roles_ are different from _permissions_, which determine what clusters and projects you can access.
|
||||
|
||||
> It is possible for a custom role to enable privilege escalation. For details, see [this section.](#privilege-escalation)
|
||||
|
||||
This section covers the following topics:
|
||||
|
||||
- [Prerequisites](#prerequisites)
|
||||
- [Creating a custom role for a cluster or project](#creating-a-custom-role-for-a-cluster-or-project)
|
||||
- [Creating a custom global role](#creating-a-custom-global-role)
|
||||
- [Deleting a custom global role](#deleting-a-custom-global-role)
|
||||
- [Assigning a custom global role to a group](#assigning-a-custom-global-role-to-a-group)
|
||||
- [Privilege escalation](#privilege-escalation)
|
||||
|
||||
# Prerequisites
|
||||
|
||||
To complete the tasks on this page, one of the following permissions are required:
|
||||
|
||||
- [Administrator Global Permissions]({{<baseurl>}}/rancher/v2.5/en/admin-settings/rbac/global-permissions/).
|
||||
- [Custom Global Permissions]({{<baseurl>}}/rancher/v2.5/en/admin-settings/rbac/global-permissions/#custom-global-permissions) with the [Manage Roles]({{<baseurl>}}/rancher/v2.5/en/admin-settings/rbac/global-permissions/) role assigned.
|
||||
|
||||
# Creating A Custom Role for a Cluster or Project
|
||||
|
||||
While Rancher comes out-of-the-box with a set of default user roles, you can also create default custom roles to provide users with very specific permissions within Rancher.
|
||||
|
||||
The steps to add custom roles differ depending on the version of Rancher.
|
||||
|
||||
1. From the **Global** view, select **Security > Roles** from the main menu.
|
||||
|
||||
1. Select a tab to determine the scope of the roles you're adding. The tabs are:
|
||||
|
||||
- **Cluster:** The role is valid for assignment when adding/managing members to _only_ clusters.
|
||||
- **Project:** The role is valid for assignment when adding/managing members to _only_ projects.
|
||||
|
||||
1. Click **Add Cluster/Project Role.**
|
||||
|
||||
1. **Name** the role.
|
||||
|
||||
1. Optional: Choose the **Cluster/Project Creator Default** option to assign this role to a user when they create a new cluster or project. Using this feature, you can expand or restrict the default roles for cluster/project creators.
|
||||
|
||||
> Out of the box, the Cluster Creator Default and the Project Creator Default roles are `Cluster Owner` and `Project Owner` respectively.
|
||||
|
||||
1. Use the **Grant Resources** options to assign individual [Kubernetes API endpoints](https://kubernetes.io/docs/reference/) to the role.
|
||||
|
||||
> When viewing the resources associated with default roles created by Rancher, if there are multiple Kubernetes API resources on one line item, the resource will have `(Custom)` appended to it. These are not custom resources but just an indication that there are multiple Kubernetes API resources as one resource.
|
||||
|
||||
> The Resource text field provides a method to search for pre-defined Kubernetes API resources, or enter a custom resource name for the grant. The pre-defined or `(Custom)` resource must be selected from the dropdown, after entering a resource name into this field.
|
||||
|
||||
You can also choose the individual cURL methods (`Create`, `Delete`, `Get`, etc.) available for use with each endpoint you assign.
|
||||
|
||||
1. Use the **Inherit from a Role** options to assign individual Rancher roles to your custom roles. Note: When a custom role inherits from a parent role, the parent role cannot be deleted until the child role is deleted.
|
||||
|
||||
1. Click **Create**.
|
||||
|
||||
# Creating a Custom Global Role
|
||||
|
||||
### Creating a Custom Global Role that Copies Rules from an Existing Role
|
||||
|
||||
If you have a group of individuals that need the same level of access in Rancher, it can save time to create a custom global role in which all of the rules from another role, such as the administrator role, are copied into a new role. This allows you to only configure the variations between the existing role and the new role.
|
||||
|
||||
The custom global role can then be assigned to a user or group so that the custom global role takes effect the first time the user or users sign into Rancher.
|
||||
|
||||
To create a custom global role based on an existing role,
|
||||
|
||||
1. Go to the **Global** view and click **Security > Roles.**
|
||||
1. On the **Global** tab, go to the role that the custom global role will be based on. Click **⋮ (…) > Clone.**
|
||||
1. Enter a name for the role.
|
||||
1. Optional: To assign the custom role default for new users, go to the **New User Default** section and click **Yes: Default role for new users.**
|
||||
1. In the **Grant Resources** section, select the Kubernetes resource operations that will be enabled for users with the custom role.
|
||||
|
||||
> The Resource text field provides a method to search for pre-defined Kubernetes API resources, or enter a custom resource name for the grant. The pre-defined or `(Custom)` resource must be selected from the dropdown, after entering a resource name into this field.
|
||||
|
||||
1. Click **Save.**
|
||||
|
||||
### Creating a Custom Global Role that Does Not Copy Rules from Another Role
|
||||
|
||||
Custom global roles don't have to be based on existing roles. To create a custom global role by choosing the specific Kubernetes resource operations that should be allowed for the role, follow these steps:
|
||||
|
||||
1. Go to the **Global** view and click **Security > Roles.**
|
||||
1. On the **Global** tab, click **Add Global Role.**
|
||||
1. Enter a name for the role.
|
||||
1. Optional: To assign the custom role default for new users, go to the **New User Default** section and click **Yes: Default role for new users.**
|
||||
1. In the **Grant Resources** section, select the Kubernetes resource operations that will be enabled for users with the custom role.
|
||||
|
||||
> The Resource text field provides a method to search for pre-defined Kubernetes API resources, or enter a custom resource name for the grant. The pre-defined or `(Custom)` resource must be selected from the dropdown, after entering a resource name into this field.
|
||||
|
||||
1. Click **Save.**
|
||||
|
||||
# Deleting a Custom Global Role
|
||||
|
||||
When deleting a custom global role, all global role bindings with this custom role are deleted.
|
||||
|
||||
If a user is only assigned one custom global role, and the role is deleted, the user would lose access to Rancher. For the user to regain access, an administrator would need to edit the user and apply new global permissions.
|
||||
|
||||
Custom global roles can be deleted, but built-in roles cannot be deleted.
|
||||
|
||||
To delete a custom global role,
|
||||
|
||||
1. Go to the **Global** view and click **Security > Roles.**
|
||||
2. On the **Global** tab, go to the custom global role that should be deleted and click **⋮ (…) > Delete.**
|
||||
3. Click **Delete.**
|
||||
|
||||
# Assigning a Custom Global Role to a Group
|
||||
|
||||
If you have a group of individuals that need the same level of access in Rancher, it can save time to create a custom global role. When the role is assigned to a group, the users in the group have the appropriate level of access the first time they sign into Rancher.
|
||||
|
||||
When a user in the group logs in, they get the built-in Standard User global role by default. They will also get the permissions assigned to their groups.
|
||||
|
||||
If a user is removed from the external authentication provider group, they would lose their permissions from the custom global role that was assigned to the group. They would continue to have their individual Standard User role.
|
||||
|
||||
> **Prerequisites:** You can only assign a global role to a group if:
|
||||
>
|
||||
> * You have set up an [external authentication provider]({{<baseurl>}}/rancher/v2.5/en/admin-settings/authentication/#external-vs-local-authentication)
|
||||
> * The external authentication provider supports [user groups]({{<baseurl>}}/rancher/v2.5/en/admin-settings/authentication/user-groups/)
|
||||
> * You have already set up at least one user group with the authentication provider
|
||||
|
||||
To assign a custom global role to a group, follow these steps:
|
||||
|
||||
1. From the **Global** view, go to **Security > Groups.**
|
||||
1. Click **Assign Global Role.**
|
||||
1. In the **Select Group To Add** field, choose the existing group that will be assigned the custom global role.
|
||||
1. In the **Custom** section, choose any custom global role that will be assigned to the group.
|
||||
1. Optional: In the **Global Permissions** or **Built-in** sections, select any additional permissions that the group should have.
|
||||
1. Click **Create.**
|
||||
|
||||
**Result:** The custom global role will take effect when the users in the group log into Rancher.
|
||||
|
||||
# Privilege Escalation
|
||||
|
||||
The `Configure Catalogs` custom permission is powerful and should be used with caution. When an admin assigns the `Configure Catalogs` permission to a standard user, it could result in privilege escalation in which the user could give themselves admin access to Rancher provisioned clusters. Anyone with this permission should be considered equivalent to an admin.
|
||||
|
||||
The `Manager Users` role grants the ability to create, update, and delete _any_ user. This presents the risk of privilege escalation as even non-admin users with this role will be able to create, update, and delete admin users. Admins should take caution when assigning this role.
|
||||
+236
@@ -0,0 +1,236 @@
|
||||
---
|
||||
title: Global Permissions
|
||||
weight: 1126
|
||||
aliases:
|
||||
- /rancher/v2.x/en/admin-settings/rbac/global-permissions/
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
_Permissions_ are individual access rights that you can assign when selecting a custom permission for a user.
|
||||
|
||||
Global Permissions define user authorization outside the scope of any particular cluster. Out-of-the-box, there are three default global permissions: `Administrator`, `Standard User` and `User-base`.
|
||||
|
||||
- **Administrator:** These users have full control over the entire Rancher system and all clusters within it.
|
||||
|
||||
- <a id="user"></a>**Standard User:** These users can create new clusters and use them. Standard users can also assign other users permissions to their clusters.
|
||||
|
||||
- **User-Base:** User-Base users have login-access only.
|
||||
|
||||
You cannot update or delete the built-in Global Permissions.
|
||||
|
||||
This section covers the following topics:
|
||||
|
||||
- [Restricted Admin](#restricted-admin)
|
||||
- [Global permission assignment](#global-permission-assignment)
|
||||
- [Global permissions for new local users](#global-permissions-for-new-local-users)
|
||||
- [Global permissions for users with external authentication](#global-permissions-for-users-with-external-authentication)
|
||||
- [Custom global permissions](#custom-global-permissions)
|
||||
- [Custom global permissions reference](#custom-global-permissions-reference)
|
||||
- [Configuring default global permissions for new users](#configuring-default-global-permissions)
|
||||
- [Configuring global permissions for existing individual users](#configuring-global-permissions-for-existing-individual-users)
|
||||
- [Configuring global permissions for groups](#configuring-global-permissions-for-groups)
|
||||
- [Refreshing group memberships](#refreshing-group-memberships)
|
||||
|
||||
# Restricted Admin
|
||||
|
||||
A new `restricted-admin` role was created in Rancher v2.5 in order to prevent privilege escalation from the local Rancher server Kubernetes cluster. This role has full administrator access to all downstream clusters managed by Rancher, but it does not have permission to alter the local Kubernetes cluster.
|
||||
|
||||
The `restricted-admin` can create other `restricted-admin` users with an equal level of access.
|
||||
|
||||
A new setting was added to Rancher to set the initial bootstrapped administrator to have the `restricted-admin` role. This applies to the first user created when the Rancher server is started for the first time. If the environment variable is set, then no global administrator would be created, and it would be impossible to create the global administrator through Rancher.
|
||||
|
||||
To bootstrap Rancher with the `restricted-admin` as the initial user, the Rancher server should be started with the following environment variable:
|
||||
|
||||
```
|
||||
CATTLE_RESTRICTED_DEFAULT_ADMIN=true
|
||||
```
|
||||
### List of `restricted-admin` Permissions
|
||||
|
||||
The permissions for the `restricted-admin` role differ based on the Rancher version.
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="v2.5.7+">
|
||||
|
||||
The `restricted-admin` permissions are as follows:
|
||||
|
||||
- Has full admin access to all downstream clusters managed by Rancher.
|
||||
- Can add other users and assign them to clusters outside of the local cluster.
|
||||
- Can create other restricted admins.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="v2.5.0-v2.5.6">
|
||||
|
||||
The `restricted-admin` permissions are as follows:
|
||||
|
||||
- Has full admin access to all downstream clusters managed by Rancher.
|
||||
- Has very limited access to the local Kubernetes cluster. Can access Rancher custom resource definitions, but has no access to any Kubernetes native types.
|
||||
- Can add other users and assign them to clusters outside of the local cluster.
|
||||
- Can create other restricted admins.
|
||||
- Cannot grant any permissions in the local cluster they don't currently have. (This is how Kubernetes normally operates)
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### Upgrading from Rancher with a Hidden Local Cluster
|
||||
|
||||
Before Rancher v2.5, it was possible to run the Rancher server using this flag to hide the local cluster:
|
||||
|
||||
```
|
||||
--add-local=false
|
||||
```
|
||||
|
||||
You will need to drop this flag when upgrading to Rancher v2.5. Otherwise, Rancher will not start. The `restricted-admin` role can be used to continue restricting access to the local cluster.
|
||||
|
||||
### Changing Global Administrators to Restricted Admins
|
||||
|
||||
If Rancher already has a global administrator, they should change all global administrators over to the new `restricted-admin` role.
|
||||
|
||||
This can be done through **Security > Users** and moving any Administrator role over to Restricted Administrator.
|
||||
|
||||
Signed-in users can change themselves over to the `restricted-admin` if they wish, but they should only do that as the last step, otherwise they won't have the permissions to do so.
|
||||
|
||||
# Global Permission Assignment
|
||||
|
||||
Global permissions for local users are assigned differently than users who log in to Rancher using external authentication.
|
||||
|
||||
### Global Permissions for New Local Users
|
||||
|
||||
When you create a new local user, you assign them a global permission as you complete the **Add User** form.
|
||||
|
||||
To see the default permissions for new users, go to the **Global** view and click **Security > Roles.** On the **Global** tab, there is a column named **New User Default.** When adding a new local user, the user receives all default global permissions that are marked as checked in this column. You can [change the default global permissions to meet your needs.](#configuring-default-global-permissions)
|
||||
|
||||
### Global Permissions for Users with External Authentication
|
||||
|
||||
When a user logs into Rancher using an external authentication provider for the first time, they are automatically assigned the **New User Default** global permissions. By default, Rancher assigns the **Standard User** permission for new users.
|
||||
|
||||
To see the default permissions for new users, go to the **Global** view and click **Security > Roles.** On the **Global** tab, there is a column named **New User Default.** When adding a new local user, the user receives all default global permissions that are marked as checked in this column, and you can [change them to meet your needs.](#configuring-default-global-permissions)
|
||||
|
||||
Permissions can be assigned to an individual user with [these steps.](#configuring-global-permissions-for-existing-individual-users)
|
||||
|
||||
You can [assign a role to everyone in the group at the same time](#configuring-global-permissions-for-groups) if the external authentication provider supports groups.
|
||||
|
||||
# Custom Global Permissions
|
||||
|
||||
Using custom permissions is convenient for providing users with narrow or specialized access to Rancher.
|
||||
|
||||
When a user from an [external authentication source]({{<baseurl>}}/rancher/v2.5/en/admin-settings/authentication/) signs into Rancher for the first time, they're automatically assigned a set of global permissions (hereafter, permissions). By default, after a user logs in for the first time, they are created as a user and assigned the default `user` permission. The standard `user` permission allows users to login and create clusters.
|
||||
|
||||
However, in some organizations, these permissions may extend too much access. Rather than assigning users the default global permissions of `Administrator` or `Standard User`, you can assign them a more restrictive set of custom global permissions.
|
||||
|
||||
The default roles, Administrator and Standard User, each come with multiple global permissions built into them. The Administrator role includes all global permissions, while the default user role includes three global permissions: Create Clusters, Use Catalog Templates, and User Base, which is equivalent to the minimum permission to log in to Rancher. In other words, the custom global permissions are modularized so that if you want to change the default user role permissions, you can choose which subset of global permissions are included in the new default user role.
|
||||
|
||||
Administrators can enforce custom global permissions in multiple ways:
|
||||
|
||||
- [Changing the default permissions for new users](#configuring-default-global-permissions)
|
||||
- [Configuring global permissions for individual users](#configuring-global-permissions-for-individual-users)
|
||||
- [Configuring global permissions for groups](#configuring-global-permissions-for-groups)
|
||||
|
||||
### Custom Global Permissions Reference
|
||||
|
||||
The following table lists each custom global permission available and whether it is included in the default global permissions, `Administrator`, `Standard User` and `User-Base`.
|
||||
|
||||
| Custom Global Permission | Administrator | Standard User | User-Base |
|
||||
| ---------------------------------- | ------------- | ------------- |-----------|
|
||||
| Create Clusters | ✓ | ✓ | |
|
||||
| Create RKE Templates | ✓ | ✓ | |
|
||||
| Manage Authentication | ✓ | | |
|
||||
| Manage Catalogs | ✓ | | |
|
||||
| Manage Cluster Drivers | ✓ | | |
|
||||
| Manage Node Drivers | ✓ | | |
|
||||
| Manage PodSecurityPolicy Templates | ✓ | | |
|
||||
| Manage Roles | ✓ | | |
|
||||
| Manage Settings | ✓ | | |
|
||||
| Manage Users | ✓ | | |
|
||||
| Use Catalog Templates | ✓ | ✓ | |
|
||||
| User Base\* (Basic log-in access) | ✓ | ✓ | |
|
||||
|
||||
> \*This role has two names:
|
||||
>
|
||||
> - When you go to the <b>Users</b> tab and edit a user's global role, this role is called <b>Login Access</b> in the custom global permissions list.
|
||||
> - When you go to the <b>Security</b> tab and edit the roles from the roles page, this role is called <b>User Base.</b>
|
||||
|
||||
For details on which Kubernetes resources correspond to each global permission, you can go to the **Global** view in the Rancher UI. Then click **Security > Roles** and go to the **Global** tab. If you click an individual role, you can refer to the **Grant Resources** table to see all of the operations and resources that are permitted by the role.
|
||||
|
||||
> **Notes:**
|
||||
>
|
||||
> - Each permission listed above is comprised of multiple individual permissions not listed in the Rancher UI. For a full list of these permissions and the rules they are comprised of, access through the API at `/v3/globalRoles`.
|
||||
> - When viewing the resources associated with default roles created by Rancher, if there are multiple Kubernetes API resources on one line item, the resource will have `(Custom)` appended to it. These are not custom resources but just an indication that there are multiple Kubernetes API resources as one resource.
|
||||
|
||||
### Configuring Default Global Permissions
|
||||
|
||||
If you want to restrict the default permissions for new users, you can remove the `user` permission as default role and then assign multiple individual permissions as default instead. Conversely, you can also add administrative permissions on top of a set of other standard permissions.
|
||||
|
||||
> **Note:** Default roles are only assigned to users added from an external authentication provider. For local users, you must explicitly assign global permissions when adding a user to Rancher. You can customize these global permissions when adding the user.
|
||||
|
||||
To change the default global permissions that are assigned to external users upon their first log in, follow these steps:
|
||||
|
||||
1. From the **Global** view, select **Security > Roles** from the main menu. Make sure the **Global** tab is selected.
|
||||
|
||||
1. Find the permissions set that you want to add or remove as a default. Then edit the permission by selecting **⋮ > Edit**.
|
||||
|
||||
1. If you want to add the permission as a default, Select **Yes: Default role for new users** and then click **Save**.
|
||||
|
||||
1. If you want to remove a default permission, edit the permission and select **No** from **New User Default**.
|
||||
|
||||
**Result:** The default global permissions are configured based on your changes. Permissions assigned to new users display a check in the **New User Default** column.
|
||||
|
||||
### Configuring Global Permissions for Individual Users
|
||||
|
||||
To configure permission for a user,
|
||||
|
||||
1. Go to the **Users** tab.
|
||||
|
||||
1. On this page, go to the user whose access level you want to change and click **⋮ > Edit.**
|
||||
|
||||
1. In the **Global Permissions** section, click **Custom.**
|
||||
|
||||
1. Check the boxes for each subset of permissions you want the user to have access to.
|
||||
|
||||
1. Click **Save.**
|
||||
|
||||
> **Result:** The user's global permissions have been updated.
|
||||
|
||||
### Configuring Global Permissions for Groups
|
||||
|
||||
If you have a group of individuals that need the same level of access in Rancher, it can save time to assign permissions to the entire group at once, so that the users in the group have the appropriate level of access the first time they sign into Rancher.
|
||||
|
||||
After you assign a custom global role to a group, the custom global role will be assigned to a user in the group when they log in to Rancher.
|
||||
|
||||
For existing users, the new permissions will take effect when the users log out of Rancher and back in again, or when an administrator [refreshes the group memberships.](#refreshing-group-memberships)
|
||||
|
||||
For new users, the new permissions take effect when the users log in to Rancher for the first time. New users from this group will receive the permissions from the custom global role in addition to the **New User Default** global permissions. By default, the **New User Default** permissions are equivalent to the **Standard User** global role, but the default permissions can be [configured.](#configuring-default-global-permissions)
|
||||
|
||||
If a user is removed from the external authentication provider group, they would lose their permissions from the custom global role that was assigned to the group. They would continue to have any remaining roles that were assigned to them, which would typically include the roles marked as **New User Default.** Rancher will remove the permissions that are associated with the group when the user logs out, or when an administrator [refreshes group memberships,](#refreshing-group-memberships) whichever comes first.
|
||||
|
||||
> **Prerequisites:** You can only assign a global role to a group if:
|
||||
>
|
||||
> * You have set up an [external authentication provider]({{<baseurl>}}/rancher/v2.5/en/admin-settings/authentication/#external-vs-local-authentication)
|
||||
> * The external authentication provider supports [user groups]({{<baseurl>}}/rancher/v2.5/en/admin-settings/authentication/user-groups/)
|
||||
> * You have already set up at least one user group with the authentication provider
|
||||
|
||||
To assign a custom global role to a group, follow these steps:
|
||||
|
||||
1. From the **Global** view, go to **Security > Groups.**
|
||||
1. Click **Assign Global Role.**
|
||||
1. In the **Select Group To Add** field, choose the existing group that will be assigned the custom global role.
|
||||
1. In the **Global Permissions,** **Custom,** and/or **Built-in** sections, select the permissions that the group should have.
|
||||
1. Click **Create.**
|
||||
|
||||
**Result:** The custom global role will take effect when the users in the group log into Rancher.
|
||||
|
||||
### Refreshing Group Memberships
|
||||
|
||||
When an administrator updates the global permissions for a group, the changes take effect for individual group members after they log out of Rancher and log in again.
|
||||
|
||||
To make the changes take effect immediately, an administrator or cluster owner can refresh group memberships.
|
||||
|
||||
An administrator might also want to refresh group memberships if a user is removed from a group in the external authentication service. In that case, the refresh makes Rancher aware that the user was removed from the group.
|
||||
|
||||
To refresh group memberships,
|
||||
|
||||
1. From the **Global** view, click **Security > Users.**
|
||||
1. Click **Refresh Group Memberships.**
|
||||
|
||||
**Result:** Any changes to the group members' permissions will take effect.
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: Locked Roles
|
||||
weight: 1129
|
||||
aliases:
|
||||
- /rancher/v2.x/en/admin-settings/rbac/locked-roles/
|
||||
---
|
||||
|
||||
You can set roles to a status of `locked`. Locking roles prevent them from being assigned users in the future.
|
||||
|
||||
Locked roles:
|
||||
|
||||
- Cannot be assigned to users that don't already have it assigned.
|
||||
- Are not listed in the **Member Roles** drop-down when you are adding a user to a cluster or project.
|
||||
- Do not affect users assigned the role before you lock the role. These users retain access that the role provides.
|
||||
|
||||
**Example:** let's say your organization creates an internal policy that users assigned to a cluster are prohibited from creating new projects. It's your job to enforce this policy.
|
||||
|
||||
To enforce it, before you add new users to the cluster, you should lock the following roles: `Cluster Owner`, `Cluster Member`, and `Create Projects`. Then you could create a new custom role that includes the same permissions as a __Cluster Member__, except the ability to create projects. Then, you use this new custom role when adding users to a cluster.
|
||||
|
||||
Roles can be locked by the following users:
|
||||
|
||||
- Any user assigned the `Administrator` global permission.
|
||||
- Any user assigned the `Custom Users` permission, along with the `Manage Roles` role.
|
||||
|
||||
|
||||
## Locking/Unlocking Roles
|
||||
|
||||
If you want to prevent a role from being assigned to users, you can set it to a status of `locked`.
|
||||
|
||||
You can lock roles in two contexts:
|
||||
|
||||
- When you're [adding a custom role]({{<baseurl>}}/rancher/v2.5/en/admin-settings/rbac/default-custom-roles/).
|
||||
- When you editing an existing role (see below).
|
||||
|
||||
1. From the **Global** view, select **Security** > **Roles**.
|
||||
|
||||
2. From the role that you want to lock (or unlock), select **⋮** > **Edit**.
|
||||
|
||||
3. From the **Locked** option, choose the **Yes** or **No** radio button. Then click **Save**.
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: Role-Based Access Control (RBAC)
|
||||
weight: 1120
|
||||
aliases:
|
||||
- /rancher/v2.5/en/concepts/global-configuration/users-permissions-roles/
|
||||
- /rancher/v2.x/en/admin-settings/rbac/
|
||||
---
|
||||
|
||||
Within Rancher, each person authenticates as a _user_, which is a login that grants you access to Rancher. As mentioned in [Authentication]({{<baseurl>}}/rancher/v2.5/en/admin-settings/authentication/), users can either be local or external.
|
||||
|
||||
After you configure external authentication, the users that display on the **Users** page changes.
|
||||
|
||||
- If you are logged in as a local user, only local users display.
|
||||
|
||||
- If you are logged in as an external user, both external and local users display.
|
||||
|
||||
## Users and Roles
|
||||
|
||||
Once the user logs in to Rancher, their _authorization_, or their access rights within the system, is determined by _global permissions_, and _cluster and project roles_.
|
||||
|
||||
- [Global Permissions]({{<baseurl>}}/rancher/v2.5/en/admin-settings/rbac/global-permissions/):
|
||||
|
||||
Define user authorization outside the scope of any particular cluster.
|
||||
|
||||
- [Cluster and Project Roles]({{<baseurl>}}/rancher/v2.5/en/admin-settings/rbac/cluster-project-roles/):
|
||||
|
||||
Define user authorization inside the specific cluster or project where they are assigned the role.
|
||||
|
||||
Both global permissions and cluster and project roles are implemented on top of [Kubernetes RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/). Therefore, enforcement of permissions and roles is performed by Kubernetes.
|
||||
Reference in New Issue
Block a user