diff --git a/content/rancher/v2.x/en/admin-settings/authentication/ad/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/ad/_index.md index 6725f47f482..fbe444f333c 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/ad/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/ad/_index.md @@ -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. diff --git a/content/rancher/v2.x/en/admin-settings/authentication/openldap/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/openldap/_index.md index 0ffa2607e3c..bce05911aac 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/openldap/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/openldap/_index.md @@ -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. diff --git a/content/rancher/v2.x/en/admin-settings/config-private-registry/_index.md b/content/rancher/v2.x/en/admin-settings/config-private-registry/_index.md index 8e5441f51d1..692802124aa 100644 --- a/content/rancher/v2.x/en/admin-settings/config-private-registry/_index.md +++ b/content/rancher/v2.x/en/admin-settings/config-private-registry/_index.md @@ -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. diff --git a/content/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/_index.md b/content/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/_index.md index 9872b85b113..92292af2ab0 100644 --- a/content/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/_index.md +++ b/content/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/_index.md @@ -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,31 +27,50 @@ _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 -The following table lists each built-in custom cluster role available in Rancher and whether it is also granted by the `Owner` or `Member` role. +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 | | ---------------------------------- | ------------- | --------------------------------- | +| Create Projects | ✓ | | +| Manage Cluster Backups             | ✓ | | +| Manage Cluster Catalogs | ✓ | | | Manage Cluster Members | ✓ | | -| Manage Cluster Catalogs | ✓ | | Manage Nodes | ✓ | | -| Manage Snapshots | ✓ || | Manage Storage | ✓ | | -| View All Projects | ✓ | | -| Create Project | ✓ | ✓ | -| View Cluster Members | ✓ | ✓ | +| View All Projects | ✓ | ✓ | | View Cluster Catalogs | ✓ | ✓ | +| View Cluster Members | ✓ | ✓ | | View Nodes | ✓ | ✓ | -| View Snapshots | ✓ | ✓ | -> **Notes:** -> ->- Each cluster role listed above, including `Owner` and `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. ->- 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 Cluster Members` role allows the user to manage any members of the cluster **and** grant them any cluster scoped role regardless of their access to the cluster resources. Be cautious when assigning this role out individually. +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,]({{}}/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. + +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 **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.** + +**Result:** The member has the assigned role. ### Project Roles @@ -76,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 @@ -108,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. @@ -117,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: @@ -132,7 +151,7 @@ There are two methods for changing default cluster/project roles: >- Although you can [lock]({{< baseurl >}}/rancher/v2.x/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 +### 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. @@ -156,9 +175,10 @@ 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. If you want to completely revoke a user's access within a cluster, revoke both their cluster and project memberships. + diff --git a/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md b/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md index 0300bf6d83a..bf1834b68ee 100644 --- a/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md +++ b/content/rancher/v2.x/en/admin-settings/rbac/global-permissions/_index.md @@ -3,6 +3,8 @@ title: Global Permissions weight: 1126 --- +_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 two default global permissions: `Administrator` and `Standard User`. - **Administrator:** @@ -15,7 +17,7 @@ Global Permissions define user authorization outside the scope of any particular >**Note:** You cannot create, update, or delete Global Permissions. -### Global Permission Assignment +# Global Permission Assignment Assignment of global permissions to a user depends on their authentication source: external or local. @@ -27,53 +29,88 @@ Assignment of global permissions to a user depends on their authentication sourc When you create a new local user, you assign them a global permission as you complete the **Add User** form. -### Custom Global Permissions +# Custom Global Permissions -Rather than assigning users the default global permissions of `Administrator` or `Standard User`, you can assign them a custom set of permissions. +Using custom permissions is convenient for providing users with narrow or specialized access to Rancher. -_Permissions_ are individual access rights that you can assign when selecting a custom permission for a user. +When a user from an [external authentication source]({{< baseurl >}}/rancher/v2.x/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 from 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. -Using custom permissions is convenient for providing users with narrow or specialized access to Rancher. See the [table below](#global-permissions-reference) for a list of individual permissions available. +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. -### Global Permissions Reference +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. -The following table lists each custom global permission available and whether it is assigned to the default global permissions, `Administrator` and `Standard User`. +Administrators can enforce custom global permissions in two ways: + +- Changing the [default permissions for new users](#configuring-default-global-permissions) + +- Editing the [permissions of an existing user](#configuring-global-permissions-for-individual-users) + +### Custom Global Permissions Reference + +The following table lists each custom global permission available and whether it is included in the default global permissions, `Administrator` and `Standard User`. | Custom Global Permission | Administrator | Standard User | | ---------------------------------- | ------------- | ------------- | +| Create Clusters | ✓ | ✓ | +| Create RKE Templates | ✓ | ✓ | | Manage Authentication | ✓ | | | Manage Catalogs | ✓ | | | Manage Cluster Drivers | ✓ | | | Manage Node Drivers | ✓ | | | Manage PodSecurityPolicy Templates | ✓ | | | Manage Roles | ✓ | | +| Manage Settings | ✓ | | | Manage Users | ✓ | | -| Create Clusters | ✓ | ✓ | -| Create RKE Templates | ✓ | ✓ | | Use Catalog Templates | ✓ | ✓ | -| Login Access | ✓ | ✓ | +| User Base* (Basic log-in access) | ✓ | ✓ | + +> *This role has two names: +> +> - When you go to the Users tab and edit a user's global role, this role is called Login Access in the custom global permissions list. +> - When you go to the Security tab and edit the roles from the roles page, this role is called User Base. + +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 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. -When a user from an [external authentication source]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/) signs into Rancher for the first time, they're automatically assigned a set of global permissions (hereafter, permissions). By default, new users are assigned the [user](#user) permissions. However, in some organizations, these permissions may extend too much access. In this use case, you can change the default permissions to something more restrictive, such as a set of individual permissions. +### Configuring Default Global Permissions -You can assign one or more default permissions. For example, the `user` permission assigns new users a [set of individual global permissions](#global-permissions-reference). 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. +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. -### Configuring Default Global Permissions - -You can change the default global permissions that are assigned to external users upon their first log in. +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 use as default. Then edit the permission by selecting **Ellipsis > Edit**. +1. Find the permissions set that you want to add or remove as a default. Then edit the permission by selecting **Ellipsis > Edit**. -1. Select **Yes: Default role for new users** and then click **Save**. +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. \ No newline at end of file +<<<<<<< HEAD +**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. +======= +**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 **Ellipsis (...) > 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. + +>>>>>>> Update and clarify docs on global and cluster permissions diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/provisioning-vsphere-clusters/_index.md b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/provisioning-vsphere-clusters/_index.md index d84c6c6ab25..3efc9d140d6 100644 --- a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/provisioning-vsphere-clusters/_index.md +++ b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/provisioning-vsphere-clusters/_index.md @@ -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.** diff --git a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/provisioning-vsphere-clusters/enabling-uuids/_index.md b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/provisioning-vsphere-clusters/enabling-uuids/_index.md index 4cb5a130602..55e8c2a2ae0 100644 --- a/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/provisioning-vsphere-clusters/enabling-uuids/_index.md +++ b/content/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/provisioning-vsphere-clusters/enabling-uuids/_index.md @@ -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. diff --git a/content/rancher/v2.x/en/faq/technical/_index.md b/content/rancher/v2.x/en/faq/technical/_index.md index da0b2063fbc..0902e31456c 100644 --- a/content/rancher/v2.x/en/faq/technical/_index.md +++ b/content/rancher/v2.x/en/faq/technical/_index.md @@ -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 reset-password -New password for default admin user (user-xxxxx): +New password for default administrator (user-xxxxx): ``` @@ -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): ``` @@ -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): ``` @@ -33,8 +33,8 @@ New password for default admin user (user-xxxxx): Single node install: ``` $ docker exec -ti 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): ``` @@ -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): ``` diff --git a/content/rancher/v2.x/en/faq/telemetry/_index.md b/content/rancher/v2.x/en/faq/telemetry/_index.md index c8b04b9e05d..6ab582667e1 100644 --- a/content/rancher/v2.x/en/faq/telemetry/_index.md +++ b/content/rancher/v2.x/en/faq/telemetry/_index.md @@ -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`. diff --git a/content/rancher/v2.x/en/project-admin/resource-quotas/_index.md b/content/rancher/v2.x/en/project-admin/resource-quotas/_index.md index 150463f4a8c..b253dfb0fd4 100644 --- a/content/rancher/v2.x/en/project-admin/resource-quotas/_index.md +++ b/content/rancher/v2.x/en/project-admin/resource-quotas/_index.md @@ -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. Base Kubernetes: Unique Resource Quotas Being Applied to Each Namespace ![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`). Rancher: Resource Quotas Propagating to Each Namespace ![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. Namespace Default Limit Override ![Namespace Default Limit Override]({{< baseurl >}}/img/rancher/rancher-resource-quota-override.svg) diff --git a/content/rancher/v2.x/en/security/_index.md b/content/rancher/v2.x/en/security/_index.md index 0264aa61c58..c39ed1fca68 100644 --- a/content/rancher/v2.x/en/security/_index.md +++ b/content/rancher/v2.x/en/security/_index.md @@ -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) | diff --git a/content/rancher/v2.x/en/security/hardening-2.1/_index.md b/content/rancher/v2.x/en/security/hardening-2.1/_index.md index e525794f055..565a9c2789d 100644 --- a/content/rancher/v2.x/en/security/hardening-2.1/_index.md +++ b/content/rancher/v2.x/en/security/hardening-2.1/_index.md @@ -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** diff --git a/content/rancher/v2.x/en/security/hardening-2.2/_index.md b/content/rancher/v2.x/en/security/hardening-2.2/_index.md index f6d24831f25..c699289667c 100644 --- a/content/rancher/v2.x/en/security/hardening-2.2/_index.md +++ b/content/rancher/v2.x/en/security/hardening-2.2/_index.md @@ -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** diff --git a/content/rancher/v2.x/en/security/hardening-2.3/_index.md b/content/rancher/v2.x/en/security/hardening-2.3/_index.md index ac8f578efcd..ab0ebdf9feb 100644 --- a/content/rancher/v2.x/en/security/hardening-2.3/_index.md +++ b/content/rancher/v2.x/en/security/hardening-2.3/_index.md @@ -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**