Edit RBAC docs

2026-05-16 10:03:28 +00:00 · 2019-12-02 17:46:03 -07:00
parent e563e3f977
commit e6cf88d2ef
14 changed files with 43 additions and 51 deletions
@@ -110,7 +110,7 @@ Once you have completed the configuration, proceed by testing  the connection to

 > **Note:**
 >
-> The AD user pertaining to the credentials entered in this step will be mapped to the local principal account and assigned admin privileges in Rancher. You should therefore make a conscious decision on which AD account you use to perform this step.
+> The AD user pertaining to the credentials entered in this step will be mapped to the local principal account and assigned administrator privileges in Rancher. You should therefore make a conscious decision on which AD account you use to perform this step.

 1. Enter the **username** and **password** for the AD account that should be mapped to the local principal account.
 2. Click **Authenticate with Active Directory** to finalise the setup.
@@ -22,7 +22,7 @@ If your organization uses LDAP for user authentication, you can configure Ranche

 ## Prerequisites

-Rancher must be configured with a LDAP bind account (aka service account) to search and retrieve LDAP entries pertaining to users and groups that should have access. It is recommended to not use an admin account or personal account for this purpose and instead create a dedicated account in OpenLDAP with read-only access to users and groups under the configured search base (see below).
+Rancher must be configured with a LDAP bind account (aka service account) to search and retrieve LDAP entries pertaining to users and groups that should have access. It is recommended to not use an administrator account or personal account for this purpose and instead create a dedicated account in OpenLDAP with read-only access to users and groups under the configured search base (see below).

 > **Using TLS?**
 >
@@ -109,7 +109,7 @@ Once you have completed the configuration, proceed by testing  the connection to

 > **Note:**
 >
-> The OpenLDAP user pertaining to the credentials entered in this step will be mapped to the local principal account and assigned admin privileges in Rancher. You should therefore make a conscious decision on which LDAP account you use to perform this step.
+> The OpenLDAP user pertaining to the credentials entered in this step will be mapped to the local principal account and assigned administrator privileges in Rancher. You should therefore make a conscious decision on which LDAP account you use to perform this step.

 1. Enter the **username** and **password** for the OpenLDAP account that should be mapped to the local principal account.
 2. Click **Authenticate With OpenLDAP** to test the OpenLDAP connection and finalise the setup.
@@ -19,7 +19,7 @@ If your private registry requires credentials, it cannot be used as the default

 # Setting a Private Registry with No Credentials as the Default Registry

-1. Log into Rancher and configure the default admin password.
+1. Log into Rancher and configure the default administrator password.

 1. Go into the **Settings** view.

@@ -11,7 +11,7 @@ The projects and clusters accessible to non-administrative users is determined b

 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.
+> **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

@@ -27,7 +27,7 @@ _Cluster roles_ are roles that you can assign to users, granting them access to

 #### Custom Cluster Roles

-Rancher lets you assign _custom cluster roles_ to a 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 user within a cluster. See the table below for a list of built-in 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

@@ -53,32 +53,24 @@ For details on how each cluster role can access Kubernetes resources, you can go

 ### Giving a Custom Cluster Role to a Cluster Member

-Admins can set up custom cluster roles that can be assigned to cluster owners and members.
+After an administrator [sets up a custom cluster role,]({{<baseurl>}}/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/#adding-a-custom-role) cluster owners and admins can then assign those roles to cluster members.

-Cluster owners and admins can then assign those roles to cluster members.
-
-To create a custom cluster role,
-
-1. In the **Global** view under **Security > Roles,** click **Add Cluster Role.**
-
-1. In the **Grant Resources** section, choose any combination of operations on Kubernetes resources that will be allowed by the new role. Give the new cluster role a name and click **Create.**
-
-Then, from the **Cluster** view, go to the **Members** tab. From this tab, you can give the cluster role to members in two ways:
-
- You can assign the role to a new member with the Rancher UI.
- You can assign the role to an existing member with the Rancher API view.
+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. Click **Add Member.** Then in the **Cluster Permissions** section, you can choose your custom cluster role. 
+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.**

-1. When you click **Create**, the member should have the assigned role.
+**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 **Ellipsis (...) > 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.**

-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.** After that, the member's role should be updated.
+**Result:** The member has the assigned role.

 ### Project Roles

@@ -103,7 +95,7 @@ _Project roles_ are roles that can be used to grant users access to a project. T

 #### Custom Project Roles

-Rancher lets you assign _custom project roles_ to a 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 user within a project. See the table below for a list of built-in 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

@@ -135,7 +127,7 @@ The following table lists each built-in custom project role available in Rancher
 >
 >- 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 Kuberenetes 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 user 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.
+>- 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.
@@ -144,7 +136,7 @@ When defining a custom role, you can grant access to specific resources or speci

 ### 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](#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.
+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:

@@ -183,7 +175,7 @@ You can change the cluster or project role(s) that are automatically assigned to

 ### 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](#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 user can still:
+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.
@@ -37,7 +37,7 @@ When a user from an [external authentication source]({{< baseurl >}}/rancher/v2.

 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, Admin and User, each come with multiple global permissions built into them. The Admin 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.
+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 two ways:

@@ -65,7 +65,7 @@ After you create a node template, it is saved, and you can re-use it whenever yo

 To create a node template,

-1. Log in with an admin account to the Rancher UI.
+1. Log in with an administrator account to the Rancher UI.

 1. From the user settings menu, select **Node Templates.**

@@ -249,7 +249,7 @@ To create the cluster and enable the vSphere provider for cluster, follow these

 ### A. Set up the Cluster Name and Member Roles

-1. Log in to the Rancher UI as an admin user.
+1. Log in to the Rancher UI as an administrator.
 2. Navigate to **Clusters** in the **Global** view.
 3. Click **Add Cluster** and select the **vSphere** infrastructure provider.
 4. Assign a **Cluster Name.**
@@ -9,7 +9,7 @@ For Rancher prior to v2.0.4, we recommend configuring a vSphere node template to

 To enable disk UUIDs for all VMs created for a cluster,

-1. Navigate to the **Node Templates** in the Rancher UI while logged in as admin user.
+1. Navigate to the **Node Templates** in the Rancher UI while logged in as an administrator.

 2. Add or edit an existing vSphere node template.

@@ -3,12 +3,12 @@ title: Technical
 weight: 8006
 ---

-### How can I reset the admin password?
+### How can I reset the administrator password?

 Single node install:
 ```
 $ docker exec -ti <container_id> reset-password
-New password for default admin user (user-xxxxx):
+New password for default administrator (user-xxxxx):
 <new_password>
 ```

@@ -16,7 +16,7 @@ High Availability install (Helm):
 ```
 $ KUBECONFIG=./kube_config_rancher-cluster.yml
 $ kubectl --kubeconfig $KUBECONFIG -n cattle-system exec $(kubectl --kubeconfig $KUBECONFIG -n cattle-system get pods -l app=rancher | grep '1/1' | head -1 | awk '{ print $1 }') -- reset-password
-New password for default admin user (user-xxxxx):
+New password for default administrator (user-xxxxx):
 <new_password>
 ```

@@ -24,7 +24,7 @@ High Availability install (RKE add-on):
 ```
 $ KUBECONFIG=./kube_config_rancher-cluster.yml
 $ kubectl --kubeconfig $KUBECONFIG exec -n cattle-system $(kubectl --kubeconfig $KUBECONFIG get pods -n cattle-system -o json | jq -r '.items[] | select(.spec.containers[].name=="cattle-server") | .metadata.name') -- reset-password
-New password for default admin user (user-xxxxx):
+New password for default administrator (user-xxxxx):
 <new_password>
 ```

@@ -33,8 +33,8 @@ New password for default admin user (user-xxxxx):
 Single node install:
 ```
 $ docker exec -ti <container_id> ensure-default-admin
-New default admin user (user-xxxxx)
-New password for default admin user (user-xxxxx):
+New default administrator (user-xxxxx)
+New password for default administrator (user-xxxxx):
 <new_password>
 ```

@@ -42,7 +42,7 @@ High Availability install (Helm):
 ```
 $ KUBECONFIG=./kube_config_rancher-cluster.yml
 $ kubectl --kubeconfig $KUBECONFIG -n cattle-system exec $(kubectl --kubeconfig $KUBECONFIG -n cattle-system get pods -l app=rancher | grep '1/1' | head -1 | awk '{ print $1 }') -- ensure-default-admin
-New password for default admin user (user-xxxxx):
+New password for default administrator (user-xxxxx):
 <new_password>
 ```

@@ -29,4 +29,4 @@ If Telemetry is not enabled, the process that collects the data is not running,

 ### How do I turn it on or off?

-After initial setup, an admin user can go to the `Settings` page in the `Global` section of the UI and click Edit to change the `telemetry-opt` setting to either `in` or `out`.
+After initial setup, an administrator can go to the `Settings` page in the `Global` section of the UI and click Edit to change the `telemetry-opt` setting to either `in` or `out`.
@@ -15,7 +15,7 @@ Resource quotas in Rancher include the same functionality as the [native version

 In a standard Kubernetes deployment, resource quotas are applied to individual namespaces. However, you cannot apply the quota to your namespaces simultaneously with a single action. Instead, the resource quota must be applied multiple times.

-In the following diagram, a Kubernetes admin is trying to enforce a resource quota without Rancher. The admin wants to apply a resource quota that sets the same CPU and memory limit to every namespace in his cluster (`Namespace 1-4`) . However, in the base version of Kubernetes, each namespace requires a unique resource quota. The admin has to create four different resource quotas that have the same specs configured (`Resource Quota 1-4`) and apply them individually.
+In the following diagram, a Kubernetes administrator is trying to enforce a resource quota without Rancher. The administrator wants to apply a resource quota that sets the same CPU and memory limit to every namespace in his cluster (`Namespace 1-4`) . However, in the base version of Kubernetes, each namespace requires a unique resource quota. The administrator has to create four different resource quotas that have the same specs configured (`Resource Quota 1-4`) and apply them individually.

 <sup>Base Kubernetes: Unique Resource Quotas Being Applied to Each Namespace</sup>
 ![Native Kubernetes Resource Quota Implementation]({{< baseurl >}}/img/rancher/kubernetes-resource-quota.svg)
@@ -33,7 +33,7 @@ The resource quota includes two limits, which you set while creating or editing

    This value is the default resource limit available for each namespace. When the resource quota is set on the project level, this limit is automatically propagated to each namespace in the project. Each namespace is bound to this default limit unless you [override it](#namespace-default-limit-overrides).

-In the following diagram, a Rancher admin wants to apply a resource quota that sets the same CPU and memory limit for every namespace in their project (`Namespace 1-4`). However, in Rancher, the admin can set a resource quota for the project (`Project Resource Quota`) rather than individual namespaces. This quota includes resource limits for both the entire project (`Project Limit`) and individual namespaces (`Namespace Default Limit`). Rancher then propagates the `Namespace Default Limit` quotas to each namespace (`Namespace Resource Quota`).
+In the following diagram, a Rancher administrator wants to apply a resource quota that sets the same CPU and memory limit for every namespace in their project (`Namespace 1-4`). However, in Rancher, the administrator can set a resource quota for the project (`Project Resource Quota`) rather than individual namespaces. This quota includes resource limits for both the entire project (`Project Limit`) and individual namespaces (`Namespace Default Limit`). Rancher then propagates the `Namespace Default Limit` quotas to each namespace (`Namespace Resource Quota`).

 <sup>Rancher: Resource Quotas Propagating to Each Namespace</sup>
 ![Rancher Resource Quota Implementation]({{< baseurl >}}/img/rancher/rancher-resource-quota.svg)
@@ -80,7 +80,7 @@ When you create a resource quota, you are configuring the pool of resources avai

 Although the **Namespace Default Limit** propagates from the project to each namespace, in some cases, you may need to increase (or decrease) the performance for a specific namespace. In this situation, you can override the default limits by editing the namespace.

-In the diagram below, the Rancher admin has a resource quota in effect for their project. However, the admin wants to override the namespace limits for `Namespace 3` so that it performs better. Therefore, the admin [raises the namespace limits]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#editing-namespace-resource-quotas) for `Namespace 3` so that the namespace can access more resources.
+In the diagram below, the Rancher administrator has a resource quota in effect for their project. However, the administrator wants to override the namespace limits for `Namespace 3` so that it performs better. Therefore, the administrator [raises the namespace limits]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#editing-namespace-resource-quotas) for `Namespace 3` so that the namespace can access more resources.

 <sup>Namespace Default Limit Override</sup>
 ![Namespace Default Limit Override]({{< baseurl >}}/img/rancher/rancher-resource-quota-override.svg)
@@ -51,5 +51,5 @@ Rancher is committed to informing the community of security issues in our produc
 | [CVE-2019-12274](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12274) | Nodes using the built-in node drivers using a file path option allows the machine to read arbitrary files including sensitive ones from inside the Rancher server container. | 5 Jun 2019  |  [Rancher v2.2.4](https://github.com/rancher/rancher/releases/tag/v2.2.4), [Rancher v2.1.10](https://github.com/rancher/rancher/releases/tag/v2.1.10) and [Rancher v2.0.15](https://github.com/rancher/rancher/releases/tag/v2.0.15)  |
 | [CVE-2019-12303](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12303) |  Project owners can inject extra fluentd logging configurations that makes it possible to read files or execute arbitrary commands inside the fluentd container. Reported by Tyler Welton from Untamed Theory. | 5 Jun 2019  |  [Rancher v2.2.4](https://github.com/rancher/rancher/releases/tag/v2.2.4), [Rancher v2.1.10](https://github.com/rancher/rancher/releases/tag/v2.1.10) and [Rancher v2.0.15](https://github.com/rancher/rancher/releases/tag/v2.0.15)   |
 | [CVE-2019-13209](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13209) |  The vulnerability is known as a [Cross-Site Websocket Hijacking attack](https://www.christian-schneider.net/CrossSiteWebSocketHijacking.html). This attack allows an exploiter to gain access to clusters managed by Rancher with the roles/permissions of a victim. It requires that a victim to be logged into a Rancher server and then access a third-party site hosted by the exploiter. Once that is accomplished, the exploiter is able to execute commands against the Kubernetes API with the permissions and identity of the victim. Reported by Matt Belisle and Alex Stevenson from Workiva. | 15 Jul 2019  |   [Rancher v2.2.5](https://github.com/rancher/rancher/releases/tag/v2.2.5), [Rancher v2.1.11](https://github.com/rancher/rancher/releases/tag/v2.1.11) and [Rancher v2.0.16](https://github.com/rancher/rancher/releases/tag/v2.0.16) |
-| [CVE-2019-14436](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14436) |  The vulnerability allows a member of a project that has access to edit role bindings to be able to assign themselves or others a cluster level role granting them admin access to that cluster. The issue was found and reported by Michal Lipinski at Nokia. | 5 Aug 2019  | [Rancher v2.2.7](https://github.com/rancher/rancher/releases/tag/v2.2.7) and [Rancher v2.1.12](https://github.com/rancher/rancher/releases/tag/v2.1.12) |
+| [CVE-2019-14436](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14436) |  The vulnerability allows a member of a project that has access to edit role bindings to be able to assign themselves or others a cluster level role granting them administrator access to that cluster. The issue was found and reported by Michal Lipinski at Nokia. | 5 Aug 2019  | [Rancher v2.2.7](https://github.com/rancher/rancher/releases/tag/v2.2.7) and [Rancher v2.1.12](https://github.com/rancher/rancher/releases/tag/v2.1.12) |
 | [CVE-2019-14435](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14435) |  This vulnerability allows authenticated users to potentially extract otherwise private data out of IPs reachable from system service containers used by Rancher. This can include but not only limited to services such as cloud provider metadata services. Although Rancher allow users to configure whitelisted domains for system service access, this flaw can still be exploited by a carefully crafted HTTP request. The issue was found and reported by Matt Belisle and Alex Stevenson at Workiva. | 5 Aug 2019  | [Rancher v2.2.7](https://github.com/rancher/rancher/releases/tag/v2.2.7) and [Rancher v2.1.12](https://github.com/rancher/rancher/releases/tag/v2.1.12) |
@@ -870,7 +870,7 @@ Upgrade the Rancher server installation using Helm, and configure the audit log

 ## 3.2 - Rancher Management Control Plane Authentication

-### 3.2.1 - Change the local admin password from the default value
+### 3.2.1 - Change the local administrator password from the default value

 **Profile Applicability**

@@ -878,11 +878,11 @@ Upgrade the Rancher server installation using Helm, and configure the audit log

 **Description**

-The local admin password should be changed from the default.
+The local administrator password should be changed from the default.

 **Rationale**

-The default admin password is common across all Rancher installations and should be changed immediately upon startup.
+The default administrator password is common across all Rancher installations and should be changed immediately upon startup.

 **Audit**

@@ -913,7 +913,7 @@ Upgrade the Rancher server installation using Helm, and configure the audit log

 ## 3.2 - Rancher Management Control Plane Authentication

-### 3.2.1 - Change the local admin password from the default value
+### 3.2.1 - Change the local administrator password from the default value

 **Profile Applicability**

@@ -921,11 +921,11 @@ Upgrade the Rancher server installation using Helm, and configure the audit log

 **Description**

-The local admin password should be changed from the default.
+The local administrator password should be changed from the default.

 **Rationale**

-The default admin password is common across all Rancher installations and should be changed immediately upon startup.
+The default administrator password is common across all Rancher installations and should be changed immediately upon startup.

 **Audit**

@@ -1001,7 +1001,7 @@ Upgrade the Rancher server installation using Helm, and configure the audit log

 ## 3.2 - Rancher Management Control Plane Authentication

-### 3.2.1 - Change the local admin password from the default value
+### 3.2.1 - Change the local administrator password from the default value

 **Profile Applicability**

@@ -1009,11 +1009,11 @@ Upgrade the Rancher server installation using Helm, and configure the audit log

 **Description**

-The local admin password should be changed from the default.
+The local administrator password should be changed from the default.

 **Rationale**

-The default admin password is common across all Rancher installations and should be changed immediately upon startup.
+The default administrator password is common across all Rancher installations and should be changed immediately upon startup.

 **Audit**