mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-05-19 11:25:15 +00:00
Merge pull request #3567 from rancher/revert-3566-merge-master-to-staging
Revert "Merge master to staging"
This commit is contained in:
Billy Tat
GitHub
@@ -16,6 +16,7 @@ This section describes the expectations for RBAC for Rancher Monitoring.
|
||||
- [Users with Kubernetes View Permissions](#users-with-kubernetes-view-permissions)
|
||||
- [Additional Monitoring Roles](#additional-monitoring-roles)
|
||||
- [Additional Monitoring ClusterRoles](#additional-monitoring-clusterroles)
|
||||
- [Additional Monitoring Roles](#additional-monitoring-roles)
|
||||
- [Users with Rancher Cluster Manager Based Permissions](#users-with-rancher-cluster-manager-based-permissions)
|
||||
- [Differences in 2.5.x](#differences-in-2-5-x)
|
||||
- [Assigning Additional Access](#assigning-additional-access)
|
||||
@@ -69,7 +70,7 @@ Only those with who have some Kubernetes `ClusterRole` should be able to:
|
||||
|
||||
### Additional Monitoring Roles
|
||||
|
||||
Monitoring also creates additional `Roles` that are not assigned to users by default but are created within the cluster. They can be bound to a namespace by deploying a `RoleBinding` that references it. To define a `RoleBinding` with `kubectl` instead of through Rancher, click [here](#assigning-roles-and-clusterroles-with-kubectl).
|
||||
Monitoring also creates additional `Roles` that are not assigned to users by default but are created within the cluster. They can be bound to a namespace by deploying a RoleBinding that references it.
|
||||
|
||||
Admins should use these roles to provide more fine-grained access to users:
|
||||
|
||||
@@ -84,40 +85,12 @@ Admins should use these roles to provide more fine-grained access to users:
|
||||
|
||||
### Additional Monitoring ClusterRoles
|
||||
|
||||
Monitoring also creates additional `ClusterRoles` that are not assigned to users by default but are created within the cluster. They are not aggregated by default but can be bound to a namespace by deploying a `RoleBinding` or `ClusterRoleBinding` that references it. To define a `RoleBinding` with `kubectl` instead of through Rancher, click [here](#assigning-roles-and-clusterroles-with-kubectl).
|
||||
Monitoring also creates additional `ClusterRoles` that are not assigned to users by default but are created within the cluster. They are not aggregated by default but can be bound to a namespace by deploying a RoleBinding that references it.
|
||||
|
||||
| Role | Purpose |
|
||||
| ------------------------------| ---------------------------|
|
||||
| monitoring-ui-view | <a id="monitoring-ui-view"></a>_Available as of Monitoring v2 14.5.100+_ Provides read-only access to external Monitoring UIs by giving a user permission to list the Prometheus, Alertmanager, and Grafana endpoints and make GET requests to Prometheus, Grafana, and Alertmanager UIs through the Rancher proxy. |
|
||||
|
||||
### Assigning Roles and ClusterRoles with kubectl
|
||||
|
||||
An alternative method to using Rancher to attach a `Role` or `ClusterRole` to a user or group is by defining bindings in YAML files that you create. You must first configure the `RoleBinding` with the YAML file, then you apply the config changes by running the `kubectl apply` command.
|
||||
|
||||
|
||||
* **Roles**: Below is an example of a YAML file to help you configure `RoleBindings` in Kubernetes to attach to a user. You will need to fill in the name below, and name is case-sensitive.
|
||||
|
||||
```
|
||||
# monitoring-config-view-role-binding.yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: RoleBinding
|
||||
metadata:
|
||||
name: monitoring-config-view
|
||||
namespace: cattle-monitoring-system
|
||||
roleRef:
|
||||
kind: Role
|
||||
name: monitoring-config-view
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
subjects:
|
||||
- kind: User
|
||||
name: u-b4qkhsnliz # this can be found via `kubectl get users -A`
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
```
|
||||
|
||||
* **kubectl**: Below is an example of a `kubectl` command used to apply the binding you've created in the YAML file. As noted, you will need to fill in your YAML filename accordingly.
|
||||
|
||||
* **`kubectl apply -f monitoring-config-view-role-binding.yaml`
|
||||
|
||||
# Users with Rancher Cluster Manager Based Permissions
|
||||
|
||||
The relationship between the default roles deployed by Rancher Cluster Manager (i.e. cluster-owner, cluster-member, project-owner, project-member), the default k8s roles, and the roles deployed by the rancher-monitoring chart are detailed in the table below:
|
||||
|
||||
@@ -56,8 +56,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 & Marketplace** in Rancher's `local` cluster. It can now be used to deploy clusters.
|
||||
|
||||
> * **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
|
||||
|
||||
> **Prerequisites:**
|
||||
|
||||
+1
-1
@@ -91,7 +91,7 @@ Option to set environment variables for [Rancher agents](https://rancher.com/doc
|
||||
|
||||
#### Automatic Snapshots
|
||||
|
||||
Option to enable or disable recurring etcd snapshots. If enabled, users have the option to configure the frequency of snapshots. For details, refer to the [RKE2 documentation](https://docs.rke2.io/backup_restore/#creating-snapshots). Note that with RKE2, snapshots are stored on each etcd node. This varies from RKE1 which only stores one snapshot per cluster.
|
||||
Option to enable or disable recurring etcd snapshots. If enabled, users have the option to configure the frequency of snapshots. For details, refer to the [RKE2 documentation](https://docs.rke2.io/backup_restore/#creating-snapshots).
|
||||
|
||||
#### Metrics
|
||||
|
||||
|
||||
+1
-3
@@ -34,9 +34,7 @@ _Tech Preview_
|
||||
|
||||
Rancher v2.6 introduces provisioning for [RKE2](https://docs.rke2.io/) clusters directly from the Rancher UI. RKE2, also known as RKE Government, is a fully conformant Kubernetes distribution that focuses on security and compliance within the U.S. Federal Government sector.
|
||||
|
||||
The RKE2 provisioning tech preview also includes installing RKE2 on Windows clusters. When provisioning a new Windows cluster, users can select "Windows" and then choose the appropriate options to configure the custom cluster under the Cluster Management page. Only Windows worker nodes may be registered.
|
||||
|
||||
Windows features for RKE2 include:
|
||||
The RKE2 provisioning tech preview also includes installing RKE2 on Windows clusters. Windows features for RKE2 include:
|
||||
|
||||
- Windows Containers with RKE2 powered by containerd
|
||||
- Added provisioning of Windows RKE2 custom clusters directly from the Rancher UI
|
||||
|
||||
@@ -25,8 +25,6 @@ For example, if you install Rancher, then set a feature flag to true with the Ra
|
||||
|
||||
The following is a list of the feature flags available in Rancher:
|
||||
|
||||
- `harvester`: This feature flag is available starting in v2.6.1. It is used to manage access to the Virtualization Management page where users can navigate directly to Harvester clusters and access the Harvester UI.
|
||||
- `rke2`: We have introduced the ability to provision RKE2 clusters as tech preview. By default, this feature flag is enabled, which allows users to attempt to provision these type of clusters.
|
||||
- `fleet`: The previous `fleet` feature flag is now required to be enabled as the Fleet capabilities are leveraged within the new provisioning framework. If you had this feature flag disabled in earlier versions, upon upgrading to Rancher v2.6, the flag will automatically be enabled. See this [page]({{<baseurl>}}/rancher/v2.6/en/deploy-across-clusters/fleet) for more information.
|
||||
- `continuous-delivery`: In Rancher v2.5.x, Fleet came with a GitOps feature that could not be disabled separately from Fleet. In Rancher v2.6, the `continuous-delivery` feature flag was introduced to allow the GitOps feature of Fleet to be disabled. For more information, see [this page.](./continuous-delivery).
|
||||
- `legacy`: There are a set of features from previous versions that are slowly being phased out of Rancher for newer iterations of the feature. This is a mix of deprecated features as well as features that will eventually be moved to newer variations in Rancher. By default, this feature flag is disabled for new installations. If you are upgrading from a previous version, this feature flag would be enabled.
|
||||
@@ -48,8 +46,6 @@ The below table shows the availability and default value for feature flags in Ra
|
||||
| `token-hashing` | `false` for new installs, `true` for upgrades | GA* | v2.6.0 | |
|
||||
| `legacy` | `false` for new installs, `true` for upgrades | GA* | v2.6.0 | |
|
||||
| `multi-cluster-management` | `false` | GA* | v2.5.0 | |
|
||||
| `harvester` | `true` | Experimental | v2.6.1 | |
|
||||
| `rke2` | `true` | Experimental | v2.6.0 | |
|
||||
|
||||
\* Generally Available. This feature is included in Rancher and it is not experimental.
|
||||
|
||||
|
||||
@@ -11,6 +11,7 @@ This section describes the expectations for RBAC for Rancher Monitoring.
|
||||
- [Users with Kubernetes View Permissions](#users-with-kubernetes-view-permissions)
|
||||
- [Additional Monitoring Roles](#additional-monitoring-roles)
|
||||
- [Additional Monitoring ClusterRoles](#additional-monitoring-clusterroles)
|
||||
- [Additional Monitoring Roles](#additional-monitoring-roles)
|
||||
- [Users with Rancher Based Permissions](#users-with-rancher-based-permissions)
|
||||
- [Differences in 2.5.x](#differences-in-2-5-x)
|
||||
- [Assigning Additional Access](#assigning-additional-access)
|
||||
@@ -64,7 +65,7 @@ Only those with who have some Kubernetes `ClusterRole` should be able to:
|
||||
|
||||
### Additional Monitoring Roles
|
||||
|
||||
Monitoring also creates additional `Roles` that are not assigned to users by default but are created within the cluster. They can be bound to a namespace by deploying a `RoleBinding` that references it. To define a `RoleBinding` with `kubectl` instead of through Rancher, click [here](#assigning-roles-and-clusterroles-with-kubectl).
|
||||
Monitoring also creates additional `Roles` that are not assigned to users by default but are created within the cluster. They can be bound to a namespace by deploying a RoleBinding that references it.
|
||||
|
||||
Admins should use these roles to provide more fine-grained access to users:
|
||||
|
||||
@@ -79,41 +80,12 @@ Admins should use these roles to provide more fine-grained access to users:
|
||||
|
||||
### Additional Monitoring ClusterRoles
|
||||
|
||||
Monitoring also creates additional `ClusterRoles` that are not assigned to users by default but are created within the cluster. They are not aggregated by default but can be bound to a namespace by deploying a `RoleBinding` or `ClusterRoleBinding` that references it. To define a `RoleBinding` with `kubectl` instead of through Rancher, click [here](#assigning-roles-and-clusterroles-with-kubectl).
|
||||
Monitoring also creates additional `ClusterRoles` that are not assigned to users by default but are created within the cluster. They are not aggregated by default but can be bound to a namespace by deploying a RoleBinding that references it.
|
||||
|
||||
| Role | Purpose |
|
||||
| ------------------------------| ---------------------------|
|
||||
| monitoring-ui-view | <a id="monitoring-ui-view"></a>_Available as of Monitoring v2 14.5.100+_ Provides read-only access to external Monitoring UIs by giving a user permission to list the Prometheus, Alertmanager, and Grafana endpoints and make GET requests to Prometheus, Grafana, and Alertmanager UIs through the Rancher proxy. |
|
||||
|
||||
### Assigning Roles and ClusterRoles with kubectl
|
||||
|
||||
An alternative method to using Rancher to attach a `Role` or `ClusterRole` to a user or group is by defining bindings in YAML files that you create. You must first configure the `RoleBinding` with the YAML file, then you apply the config changes by running the `kubectl apply` command.
|
||||
|
||||
|
||||
* **Roles**: Below is an example of a YAML file to help you configure `RoleBindings` in Kubernetes. You will need to fill in the name below, and name is case-sensitive.
|
||||
|
||||
```
|
||||
# monitoring-config-view-role-binding.yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: RoleBinding
|
||||
metadata:
|
||||
name: monitoring-config-view
|
||||
namespace: cattle-monitoring-system
|
||||
roleRef:
|
||||
kind: Role
|
||||
name: monitoring-config-view
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
subjects:
|
||||
- kind: User
|
||||
name: u-b4qkhsnliz # this can be found via `kubectl get users -A`
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
```
|
||||
|
||||
* **kubectl**: Below is an example of a `kubectl` command used to apply the binding you've created in the YAML file. As noted, you will need to fill in your YAML filename accordingly.
|
||||
|
||||
* **`kubectl apply -f monitoring-config-view-role-binding.yaml`
|
||||
|
||||
|
||||
# Users with Rancher Based Permissions
|
||||
|
||||
The relationship between the default roles deployed by Rancher (i.e. cluster-owner, cluster-member, project-owner, project-member), the default Kubernetes roles, and the roles deployed by the rancher-monitoring chart are detailed in the table below:
|
||||
|
||||
Reference in New Issue
Block a user