mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-04-27 08:45:38 +00:00
Merge pull request #1708 from btat/2.11-restricted-admin-refs
Remove restricted admin references
This commit is contained in:
Billy Tat
GitHub
@@ -18,8 +18,6 @@ In this section,
|
||||
- **K3s (Lightweight Kubernetes)** is also a fully compliant Kubernetes distribution. It is newer than RKE, easier to use, and more lightweight, with a binary size of less than 100 MB.
|
||||
- **RKE2** is a fully conformant Kubernetes distribution that focuses on security and compliance within the U.S. Federal Government sector.
|
||||
|
||||
Note the `restrictedAdmin` Helm chart option available for **the Rancher Server**. When this option is set to true, the initial Rancher user has restricted access to the local Kubernetes cluster to prevent privilege escalation. For more information, see the section about the [restricted-admin role.](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md#restricted-admin)
|
||||
|
||||
## Overview of Installation Options
|
||||
|
||||
Rancher can be installed on these main architectures:
|
||||
|
||||
-1
@@ -59,7 +59,6 @@ For information on enabling experimental features, refer to [this page.](../../.
|
||||
| `rancherImageTag` | same as chart version | `string` - rancher/rancher image tag |
|
||||
| `replicas` | 3 | `int` - Number of Rancher server replicas. Setting to -1 will dynamically choose 1, 2, or 3 based on the number of available nodes in the cluster. |
|
||||
| `resources` | {} | `map` - rancher pod resource requests & limits |
|
||||
| `restrictedAdmin` | `false` | `bool` - When this option is set to `true`, the initial Rancher user has restricted access to the local Kubernetes cluster to prevent privilege escalation. For more information, see the section about the [restricted-admin role](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md#restricted-admin). |
|
||||
| `systemDefaultRegistry` | "" | `string` - private registry to be used for all system container images, e.g., http://registry.example.com/ |
|
||||
| `tls` | "ingress" | `string` - See [External TLS Termination](#external-tls-termination) for details. - "ingress, external" |
|
||||
| `useBundledSystemChart` | `false` | `bool` - select to use the system-charts packaged with Rancher server. This option is used for air gapped installations. |
|
||||
|
||||
+1
-79
@@ -8,12 +8,10 @@ title: Global Permissions
|
||||
|
||||
_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 four default global permissions: `Administrator`, `Restricted Admin`,`Standard User` and `User-base`.
|
||||
Global Permissions define user authorization outside the scope of any particular cluster. Out-of-the-box, there are four 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.
|
||||
|
||||
- **Restricted Admin (Deprecated) :** These users have full control over downstream clusters, but cannot alter the local Kubernetes cluster.
|
||||
|
||||
- **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.
|
||||
@@ -286,79 +284,3 @@ To refresh group memberships,
|
||||
1. Click **Refresh Group Memberships**.
|
||||
|
||||
**Result:** Any changes to the group members' permissions will take effect.
|
||||
|
||||
## Restricted Admin
|
||||
|
||||
:::warning Deprecated
|
||||
|
||||
The Restricted Admin role is deprecated, and will be removed in a future version of Rancher (2.10 or higher). You should make a custom role with the desired permissions instead of relying on this built-in role.
|
||||
|
||||
:::
|
||||
|
||||
A new `restricted-admin` role was created in Rancher v2.5 in order to prevent privilege escalation on 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 following table lists the permissions and actions that a `restricted-admin` should have in comparison with the `Administrator` and `Standard User` roles:
|
||||
|
||||
| Category | Action | Global Admin | Standard User | Restricted Admin | Notes for Restricted Admin role |
|
||||
| -------- | ------ | ------------ | ------------- | ---------------- | ------------------------------- |
|
||||
| Local Cluster functions | Manage Local Cluster (List, Edit, Import Host) | Yes | No | No | |
|
||||
| | Create Projects/namespaces | Yes | No | No | |
|
||||
| | Add cluster/project members | Yes | No | No | |
|
||||
| | Global DNS | Yes | No | No | |
|
||||
| | Access to management cluster for CRDs and CRs | Yes | No | Yes | |
|
||||
| | Save as RKE Template | Yes | No | No | |
|
||||
| Security | | | | | |
|
||||
| Enable auth | Configure Authentication | Yes | No | Yes | |
|
||||
| Roles | Create/Assign GlobalRoles | Yes | No (Can list) | Yes | Auth webhook allows creating globalrole for perms already present |
|
||||
| | Create/Assign ClusterRoles | Yes | No (Can list) | Yes | Not in local cluster |
|
||||
| | Create/Assign ProjectRoles | Yes | No (Can list) | Yes | Not in local cluster |
|
||||
| Users | Add User/Edit/Delete/Deactivate User | Yes | No | Yes | |
|
||||
| Groups | Assign Global role to groups | Yes | No | Yes | As allowed by the webhook |
|
||||
| | Refresh Groups | Yes | No | Yes | |
|
||||
| PSP's | Manage PSP templates | Yes | No (Can list) | Yes | Same privileges as Global Admin for PSPs |
|
||||
| Tools | | | | | |
|
||||
| | Manage RKE Templates | Yes | No | Yes | |
|
||||
| | Manage Global Catalogs | Yes | No | Yes | Cannot edit/delete built-in system catalog. Can manage Helm library |
|
||||
| | Cluster Drivers | Yes | No | Yes | |
|
||||
| | Node Drivers | Yes | No | Yes | |
|
||||
| | GlobalDNS Providers | Yes | Yes (Self) | Yes | |
|
||||
| | GlobalDNS Entries | Yes | Yes (Self) | Yes | |
|
||||
| Settings | | | | | |
|
||||
| | Manage Settings | Yes | No (Can list) | No (Can list) | |
|
||||
| User | | | | | |
|
||||
| | Manage API Keys | Yes (Manage all) | Yes (Manage self) | Yes (Manage self) | |
|
||||
| | Manage Node Templates | Yes | Yes (Manage self) | Yes (Manage self) | Can only manage their own node templates and not those created by other users |
|
||||
| | Manage Cloud Credentials | Yes | Yes (Manage self) | Yes (Manage self) | Can only manage their own cloud credentials and not those created by other users |
|
||||
| Downstream Cluster | Create Cluster | Yes | Yes | Yes | |
|
||||
| | Edit Cluster | Yes | Yes | Yes | |
|
||||
| | Rotate Certificates | Yes | | Yes | |
|
||||
| | Snapshot Now | Yes | | Yes | |
|
||||
| | Restore Snapshot | Yes | | Yes | |
|
||||
| | Save as RKE Template | Yes | No | Yes | |
|
||||
| | Run CIS Scan | Yes | Yes | Yes | |
|
||||
| | Add Members | Yes | Yes | Yes | |
|
||||
| | Create Projects | Yes | Yes | Yes | |
|
||||
| Feature Charts since v2.5 | | | | | |
|
||||
| | Install Fleet | Yes | | Yes | Should not be able to run Fleet in local cluster |
|
||||
| | Deploy EKS cluster | Yes | Yes | Yes | |
|
||||
| | Deploy GKE cluster | Yes | Yes | Yes | |
|
||||
| | Deploy AKS cluster | Yes | Yes | Yes | |
|
||||
|
||||
### Changing Global Administrators to Restricted Admins
|
||||
|
||||
In previous version, the docs recommended that all users should be changed over to Restricted Admin if the role was in use. Users are now encouraged to use a custom-built role using the cluster permissions feature, and migrate any current restricted admins to use that approach.
|
||||
|
||||
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.
|
||||
|
||||
@@ -52,12 +52,6 @@ In this section, you'll learn how to add the cluster template to the `local` clu
|
||||
|
||||
**Result:** The cluster template available from the **Apps** in Rancher's `local` cluster. It can now be used to deploy clusters.
|
||||
|
||||
:::note Restricted Admin access:
|
||||
|
||||
If you are a restricted admin and don’t have access to the `local` cluster, you may still add new RKE2 templates and manage cluster repositories. To navigate to the chart repository, go to the left navigation bar and click **☰ > Cluster Management > Advanced > Repositories**. You will bypass steps 1 - 6 above, then proceed to follow steps 7 - 12 to create the cluster template.
|
||||
|
||||
:::
|
||||
|
||||
## Creating a Cluster from a Cluster Template
|
||||
|
||||
:::note Prerequisites:
|
||||
|
||||
-2
@@ -48,7 +48,6 @@ Etcd is the backing database for Kubernetes and for Rancher. The database may ev
|
||||
This is typical in Rancher, as many operations create new `RoleBinding` objects in the upstream cluster as a side effect.
|
||||
|
||||
You can reduce the number of `RoleBindings` in the upstream cluster in the following ways:
|
||||
* Limit the use of the [Restricted Admin](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md#restricted-admin) role. Apply other roles wherever possible.
|
||||
* Only add users to clusters and projects when necessary.
|
||||
* Remove clusters and projects when they are no longer needed.
|
||||
* Only use custom roles if necessary.
|
||||
@@ -73,7 +72,6 @@ Predicting how many `RoleBinding` objects a given configuration will create is c
|
||||
* `Ua` is the average number of users with a membership on a cluster.
|
||||
* `P` is the total number of projects.
|
||||
* `Pa` is the average number of users with a membership on a project.
|
||||
* The Restricted Admin role follows a different formula, as every user with this role results in at least `7C + 2P + 2` additional `RoleBinding` objects.
|
||||
* The number of `RoleBindings` increases linearly with the number of clusters, projects, and users.
|
||||
|
||||
### Using New Apps Over Legacy Apps
|
||||
|
||||
-2
@@ -18,8 +18,6 @@ In this section,
|
||||
- **K3s (Lightweight Kubernetes)** is also a fully compliant Kubernetes distribution. It is newer than RKE, easier to use, and more lightweight, with a binary size of less than 100 MB.
|
||||
- **RKE2** is a fully conformant Kubernetes distribution that focuses on security and compliance within the U.S. Federal Government sector.
|
||||
|
||||
Note the `restrictedAdmin` Helm chart option available for **the Rancher Server**. When this option is set to true, the initial Rancher user has restricted access to the local Kubernetes cluster to prevent privilege escalation. For more information, see the section about the [restricted-admin role.](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md#restricted-admin)
|
||||
|
||||
## Overview of Installation Options
|
||||
|
||||
Rancher can be installed on these main architectures:
|
||||
|
||||
-1
@@ -59,7 +59,6 @@ For information on enabling experimental features, refer to [this page.](../../.
|
||||
| `rancherImageTag` | same as chart version | `string` - rancher/rancher image tag |
|
||||
| `replicas` | 3 | `int` - Number of Rancher server replicas. Setting to -1 will dynamically choose 1, 2, or 3 based on the number of available nodes in the cluster. |
|
||||
| `resources` | {} | `map` - rancher pod resource requests & limits |
|
||||
| `restrictedAdmin` | `false` | `bool` - When this option is set to `true`, the initial Rancher user has restricted access to the local Kubernetes cluster to prevent privilege escalation. For more information, see the section about the [restricted-admin role](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md#restricted-admin). |
|
||||
| `systemDefaultRegistry` | "" | `string` - private registry to be used for all system container images, e.g., http://registry.example.com/ |
|
||||
| `tls` | "ingress" | `string` - See [External TLS Termination](#external-tls-termination) for details. - "ingress, external" |
|
||||
| `useBundledSystemChart` | `false` | `bool` - select to use the system-charts packaged with Rancher server. This option is used for air gapped installations. |
|
||||
|
||||
+1
-79
@@ -8,12 +8,10 @@ title: Global Permissions
|
||||
|
||||
_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 four default global permissions: `Administrator`, `Restricted Admin`,`Standard User` and `User-base`.
|
||||
Global Permissions define user authorization outside the scope of any particular cluster. Out-of-the-box, there are four 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.
|
||||
|
||||
- **Restricted Admin (Deprecated) :** These users have full control over downstream clusters, but cannot alter the local Kubernetes cluster.
|
||||
|
||||
- **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.
|
||||
@@ -286,79 +284,3 @@ To refresh group memberships,
|
||||
1. Click **Refresh Group Memberships**.
|
||||
|
||||
**Result:** Any changes to the group members' permissions will take effect.
|
||||
|
||||
## Restricted Admin
|
||||
|
||||
:::warning Deprecated
|
||||
|
||||
The Restricted Admin role is deprecated, and will be removed in a future version of Rancher (2.10 or higher). You should make a custom role with the desired permissions instead of relying on this built-in role.
|
||||
|
||||
:::
|
||||
|
||||
A new `restricted-admin` role was created in Rancher v2.5 in order to prevent privilege escalation on 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 following table lists the permissions and actions that a `restricted-admin` should have in comparison with the `Administrator` and `Standard User` roles:
|
||||
|
||||
| Category | Action | Global Admin | Standard User | Restricted Admin | Notes for Restricted Admin role |
|
||||
| -------- | ------ | ------------ | ------------- | ---------------- | ------------------------------- |
|
||||
| Local Cluster functions | Manage Local Cluster (List, Edit, Import Host) | Yes | No | No | |
|
||||
| | Create Projects/namespaces | Yes | No | No | |
|
||||
| | Add cluster/project members | Yes | No | No | |
|
||||
| | Global DNS | Yes | No | No | |
|
||||
| | Access to management cluster for CRDs and CRs | Yes | No | Yes | |
|
||||
| | Save as RKE Template | Yes | No | No | |
|
||||
| Security | | | | | |
|
||||
| Enable auth | Configure Authentication | Yes | No | Yes | |
|
||||
| Roles | Create/Assign GlobalRoles | Yes | No (Can list) | Yes | Auth webhook allows creating globalrole for perms already present |
|
||||
| | Create/Assign ClusterRoles | Yes | No (Can list) | Yes | Not in local cluster |
|
||||
| | Create/Assign ProjectRoles | Yes | No (Can list) | Yes | Not in local cluster |
|
||||
| Users | Add User/Edit/Delete/Deactivate User | Yes | No | Yes | |
|
||||
| Groups | Assign Global role to groups | Yes | No | Yes | As allowed by the webhook |
|
||||
| | Refresh Groups | Yes | No | Yes | |
|
||||
| PSP's | Manage PSP templates | Yes | No (Can list) | Yes | Same privileges as Global Admin for PSPs |
|
||||
| Tools | | | | | |
|
||||
| | Manage RKE Templates | Yes | No | Yes | |
|
||||
| | Manage Global Catalogs | Yes | No | Yes | Cannot edit/delete built-in system catalog. Can manage Helm library |
|
||||
| | Cluster Drivers | Yes | No | Yes | |
|
||||
| | Node Drivers | Yes | No | Yes | |
|
||||
| | GlobalDNS Providers | Yes | Yes (Self) | Yes | |
|
||||
| | GlobalDNS Entries | Yes | Yes (Self) | Yes | |
|
||||
| Settings | | | | | |
|
||||
| | Manage Settings | Yes | No (Can list) | No (Can list) | |
|
||||
| User | | | | | |
|
||||
| | Manage API Keys | Yes (Manage all) | Yes (Manage self) | Yes (Manage self) | |
|
||||
| | Manage Node Templates | Yes | Yes (Manage self) | Yes (Manage self) | Can only manage their own node templates and not those created by other users |
|
||||
| | Manage Cloud Credentials | Yes | Yes (Manage self) | Yes (Manage self) | Can only manage their own cloud credentials and not those created by other users |
|
||||
| Downstream Cluster | Create Cluster | Yes | Yes | Yes | |
|
||||
| | Edit Cluster | Yes | Yes | Yes | |
|
||||
| | Rotate Certificates | Yes | | Yes | |
|
||||
| | Snapshot Now | Yes | | Yes | |
|
||||
| | Restore Snapshot | Yes | | Yes | |
|
||||
| | Save as RKE Template | Yes | No | Yes | |
|
||||
| | Run CIS Scan | Yes | Yes | Yes | |
|
||||
| | Add Members | Yes | Yes | Yes | |
|
||||
| | Create Projects | Yes | Yes | Yes | |
|
||||
| Feature Charts since v2.5 | | | | | |
|
||||
| | Install Fleet | Yes | | Yes | Should not be able to run Fleet in local cluster |
|
||||
| | Deploy EKS cluster | Yes | Yes | Yes | |
|
||||
| | Deploy GKE cluster | Yes | Yes | Yes | |
|
||||
| | Deploy AKS cluster | Yes | Yes | Yes | |
|
||||
|
||||
### Changing Global Administrators to Restricted Admins
|
||||
|
||||
In previous version, the docs recommended that all users should be changed over to Restricted Admin if the role was in use. Users are now encouraged to use a custom-built role using the cluster permissions feature, and migrate any current restricted admins to use that approach.
|
||||
|
||||
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.
|
||||
|
||||
-6
@@ -52,12 +52,6 @@ In this section, you'll learn how to add the cluster template to the `local` clu
|
||||
|
||||
**Result:** The cluster template available from the **Apps** in Rancher's `local` cluster. It can now be used to deploy clusters.
|
||||
|
||||
:::note Restricted Admin access:
|
||||
|
||||
If you are a restricted admin and don’t have access to the `local` cluster, you may still add new RKE2 templates and manage cluster repositories. To navigate to the chart repository, go to the left navigation bar and click **☰ > Cluster Management > Advanced > Repositories**. You will bypass steps 1 - 6 above, then proceed to follow steps 7 - 12 to create the cluster template.
|
||||
|
||||
:::
|
||||
|
||||
## Creating a Cluster from a Cluster Template
|
||||
|
||||
:::note Prerequisites:
|
||||
|
||||
-2
@@ -48,7 +48,6 @@ Etcd is the backing database for Kubernetes and for Rancher. The database may ev
|
||||
This is typical in Rancher, as many operations create new `RoleBinding` objects in the upstream cluster as a side effect.
|
||||
|
||||
You can reduce the number of `RoleBindings` in the upstream cluster in the following ways:
|
||||
* Limit the use of the [Restricted Admin](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md#restricted-admin) role. Apply other roles wherever possible.
|
||||
* Only add users to clusters and projects when necessary.
|
||||
* Remove clusters and projects when they are no longer needed.
|
||||
* Only use custom roles if necessary.
|
||||
@@ -73,7 +72,6 @@ Predicting how many `RoleBinding` objects a given configuration will create is c
|
||||
* `Ua` is the average number of users with a membership on a cluster.
|
||||
* `P` is the total number of projects.
|
||||
* `Pa` is the average number of users with a membership on a project.
|
||||
* The Restricted Admin role follows a different formula, as every user with this role results in at least `7C + 2P + 2` additional `RoleBinding` objects.
|
||||
* The number of `RoleBindings` increases linearly with the number of clusters, projects, and users.
|
||||
|
||||
### Using New Apps Over Legacy Apps
|
||||
|
||||
Reference in New Issue
Block a user