mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 20:48:11 +00:00
Merge branch 'main' into 2023-Q4-2.8x
This commit is contained in:
Billy Tat
@@ -3,7 +3,7 @@ title: API Tokens
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/about-the-api/api-tokens"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/about-the-api/api-tokens"/>
|
||||
</head>
|
||||
|
||||
By default, some cluster-level API tokens are generated with infinite time-to-live (`ttl=0`). In other words, API tokens with `ttl=0` never expire unless you invalidate them. Tokens are not invalidated by changing a password.
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Backup Configuration
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/backup-restore-configuration/backup-configuration"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/backup-restore-configuration/backup-configuration"/>
|
||||
</head>
|
||||
|
||||
The **Backup: Create** page lets you configure a schedule, enable encryption and specify the storage location for your backups.
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Examples
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/backup-restore-configuration/examples"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/backup-restore-configuration/examples"/>
|
||||
</head>
|
||||
|
||||
This section contains examples of Backup and Restore custom resources.
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Restore Configuration
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/backup-restore-configuration/restore-configuration"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/backup-restore-configuration/restore-configuration"/>
|
||||
</head>
|
||||
|
||||
The Restore Create page lets you provide details of the backup to restore from
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Backup Storage Location Configuration
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/backup-restore-configuration/storage-configuration"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/backup-restore-configuration/storage-configuration"/>
|
||||
</head>
|
||||
|
||||
Configure a storage location where all backups are saved by default. You will have the option to override this with each backup, but will be limited to using an S3-compatible object store.
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Logging Best Practices
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/best-practices/rancher-managed-clusters/logging-best-practices"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/best-practices/rancher-managed-clusters/logging-best-practices"/>
|
||||
</head>
|
||||
|
||||
In this guide, we recommend best practices for cluster-level logging and application logging.
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Monitoring Best Practices
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/best-practices/rancher-managed-clusters/monitoring-best-practices"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/best-practices/rancher-managed-clusters/monitoring-best-practices"/>
|
||||
</head>
|
||||
|
||||
Configuring sensible monitoring and alerting rules is vital for running any production workloads securely and reliably. This is not different when using Kubernetes and Rancher. Fortunately the integrated monitoring and alerting functionality makes this whole process a lot easier.
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Best Practices for Rancher Managed vSphere Clusters
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/best-practices/rancher-managed-clusters/rancher-managed-clusters-in-vsphere"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/best-practices/rancher-managed-clusters/rancher-managed-clusters-in-vsphere"/>
|
||||
</head>
|
||||
|
||||
This guide outlines a reference architecture for provisioning downstream Rancher clusters in a vSphere environment, in addition to standard vSphere best practices as documented by VMware.
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Tips for Setting Up Containers
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/best-practices/rancher-managed-clusters/tips-to-set-up-containers"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/best-practices/rancher-managed-clusters/tips-to-set-up-containers"/>
|
||||
</head>
|
||||
|
||||
Running well-built containers can greatly impact the overall performance and security of your environment.
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Installing Rancher in a vSphere Environment
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/best-practices/rancher-server/on-premises-rancher-in-vsphere"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/best-practices/rancher-server/on-premises-rancher-in-vsphere"/>
|
||||
</head>
|
||||
|
||||
This guide outlines a reference architecture for installing Rancher on an RKE Kubernetes cluster in a vSphere environment, in addition to standard vSphere best practices as documented by VMware.
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Rancher Deployment Strategy
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/best-practices/rancher-server/rancher-deployment-strategy"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/best-practices/rancher-server/rancher-deployment-strategy"/>
|
||||
</head>
|
||||
|
||||
There are two recommended deployment strategies for a Rancher instance that manages downstream Kubernetes clusters. Each one has its own pros and cons. Read more about which one would fit best for your use case.
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Tips for Running Rancher
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/best-practices/rancher-server/tips-for-running-rancher"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/best-practices/rancher-server/tips-for-running-rancher"/>
|
||||
</head>
|
||||
|
||||
This guide is geared toward use cases where Rancher is used to manage downstream Kubernetes clusters. The high-availability setup is intended to prevent losing access to downstream clusters if the Rancher server is not available.
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Tips for Scaling Rancher
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/best-practices/rancher-server/tips-for-scaling-rancher"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/best-practices/rancher-server/tips-for-scaling-rancher"/>
|
||||
</head>
|
||||
|
||||
This guide aims to introduce the approaches that should be considered to scale Rancher setups, and associated challenges with doing so. As systems grow performance will naturally reduce, but there are steps we can take to minimize the load put on Rancher, as well as optimize Rancher's ability to handle these larger setups.
|
||||
|
||||
@@ -3,7 +3,7 @@ title: kubectl Utility
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cli-with-rancher/kubectl-utility"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cli-with-rancher/kubectl-utility"/>
|
||||
</head>
|
||||
|
||||
## kubectl
|
||||
|
||||
@@ -4,7 +4,7 @@ description: Interact with Rancher using command line interface (CLI) tools from
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cli-with-rancher/rancher-cli"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cli-with-rancher/rancher-cli"/>
|
||||
</head>
|
||||
|
||||
The Rancher CLI (Command Line Interface) is a unified tool that you can use to interact with Rancher. With this tool, you can operate Rancher using a command line rather than the GUI.
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: EC2 Machine Configuration Reference
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/downstream-cluster-configuration/machine-configuration/amazon-ec2"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/downstream-cluster-configuration/machine-configuration/amazon-ec2"/>
|
||||
</head>
|
||||
|
||||
For more details about EC2 nodes, refer to the official documentation for the [EC2 Management Console](https://aws.amazon.com/ec2).
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Azure Machine Configuration
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/downstream-cluster-configuration/machine-configuration/azure"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/downstream-cluster-configuration/machine-configuration/azure"/>
|
||||
</head>
|
||||
|
||||
For more information about Azure, refer to the official [Azure documentation.](https://docs.microsoft.com/en-us/azure/?product=featured)
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: DigitalOcean Machine Configuration
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/downstream-cluster-configuration/machine-configuration/digitalocean"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/downstream-cluster-configuration/machine-configuration/digitalocean"/>
|
||||
</head>
|
||||
|
||||
For more details about DigitalOcean, Droplets, refer to the [official documentation](https://docs.digitalocean.com/products/compute/).
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: EC2 Node Template Configuration
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/amazon-ec2"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/amazon-ec2"/>
|
||||
</head>
|
||||
|
||||
For more details about EC2, nodes, refer to the official documentation for the [EC2 Management Console](https://aws.amazon.com/ec2).
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Azure Node Template Configuration
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/azure"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/azure"/>
|
||||
</head>
|
||||
|
||||
For more information about Azure, refer to the official [Azure documentation.](https://docs.microsoft.com/en-us/azure/?product=featured)
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: DigitalOcean Node Template Configuration
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/digitalocean"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/digitalocean"/>
|
||||
</head>
|
||||
|
||||
Account access information is stored as a cloud credential. Cloud credentials are stored as Kubernetes secrets. Multiple node templates can use the same cloud credential. You can use an existing cloud credential or create a new one.
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Nutanix Node Template Configuration
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/nutanix"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/nutanix"/>
|
||||
</head>
|
||||
|
||||
## Account Access
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: VSphere Node Template Configuration
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere"/>
|
||||
</head>
|
||||
|
||||
## Account Access
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: AKS Cluster Configuration Reference
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/rancher-server-configuration/aks-cluster-configuration"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/rancher-server-configuration/aks-cluster-configuration"/>
|
||||
</head>
|
||||
|
||||
## Changes in Rancher v2.6
|
||||
|
||||
+7
-5
@@ -3,7 +3,7 @@ title: EKS Cluster Configuration Reference
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/rancher-server-configuration/eks-cluster-configuration"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/rancher-server-configuration/eks-cluster-configuration"/>
|
||||
</head>
|
||||
|
||||
### Account Access
|
||||
@@ -86,9 +86,11 @@ Amazon EKS managed node groups automate the provisioning and lifecycle managemen
|
||||
|
||||
For more information about how node groups work and how they are configured, refer to the [EKS documentation.](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html)
|
||||
|
||||
#### Bring your own launch template
|
||||
#### User-provided Launch Templates
|
||||
|
||||
A launch template ID and version can be provided in order to easily configure the EC2 instances in a node group. If a launch template is provided, then none of the settings below will be configurable in Rancher. Therefore, using a launch template would require that all the necessary and desired settings from the list below would need to be specified in the launch template. Also note that if a launch template ID and version is provided, then only the template version can be updated. Using a new template ID would require creating a new managed node group.
|
||||
You can provide your own launch template ID and version to configure the EC2 instances in a node group. If you provide the launch template, none of the template settings will be configurable from Rancher. You must set all of the required options listed below in your launch template.
|
||||
|
||||
Also, if you provide the launch template, you can only update the template version, not the template ID. To use a new template ID, create a new managed node group.
|
||||
|
||||
| Option | Description | Required/Optional |
|
||||
| ------ | ----------- | ----------------- |
|
||||
@@ -97,9 +99,9 @@ A launch template ID and version can be provided in order to easily configure th
|
||||
| Node Volume Size | The launch template must specify an EBS volume with the desired size | Required |
|
||||
| SSH Key | A key to be added to the instances to provide SSH access to the nodes | Optional |
|
||||
| User Data | Cloud init script in [MIME multi-part format](https://docs.aws.amazon.com/eks/latest/userguide/launch-templates.html#launch-template-user-data) | Optional |
|
||||
| Instance Resource Tags | Tag each EC2 instance in the node group | Optional |
|
||||
| Instance Resource Tags | Tag each EC2 instance and its volumes in the node group | Optional |
|
||||
|
||||
#### Rancher-managed launch templates
|
||||
#### Rancher-managed Launch Templates
|
||||
|
||||
If you do not specify a launch template, then you will be able to configure the above options in the Rancher UI and all of them can be updated after creation. In order to take advantage of all of these options, Rancher will create and manage a launch template for you. Each cluster in Rancher will have one Rancher-managed launch template and each managed node group that does not have a specified launch template will have one version of the managed launch template. The name of this launch template will have the prefix "rancher-managed-lt-" followed by the display name of the cluster. In addition, the Rancher-managed launch template will be tagged with the key "rancher-managed-template" and value "do-not-modify-or-delete" to help identify it as Rancher-managed. It is important that this launch template and its versions not be modified, deleted, or used with any other clusters or managed node groups. Doing so could result in your node groups being "degraded" and needing to be destroyed and recreated.
|
||||
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Private Clusters
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/rancher-server-configuration/gke-cluster-configuration/gke-private-clusters"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/rancher-server-configuration/gke-cluster-configuration/gke-private-clusters"/>
|
||||
</head>
|
||||
|
||||
In GKE, [private clusters](https://cloud.google.com/kubernetes-engine/docs/concepts/private-cluster-concept) are clusters whose nodes are isolated from inbound and outbound traffic by assigning them internal IP addresses only. Private clusters in GKE have the option of exposing the control plane endpoint as a publicly accessible address or as a private address. This is different from other Kubernetes providers, which may refer to clusters with private control plane endpoints as "private clusters" but still allow traffic to and from nodes. You may want to create a cluster with private nodes, with or without a public control plane endpoint, depending on your organization's networking and security requirements. A GKE cluster provisioned from Rancher can use isolated nodes by selecting "Private Cluster" in the Cluster Options (under "Show advanced options"). The control plane endpoint can optionally be made private by selecting "Enable Private Endpoint".
|
||||
|
||||
+1
-1
@@ -127,7 +127,7 @@ ACE is available on RKE, RKE2, and K3s clusters that are provisioned or register
|
||||
|
||||
:::
|
||||
|
||||
ACE must be set up [manually](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters#authorized-cluster-endpoint-support-for-rke2-and-k3s-clusters.md) on RKE2 and K3s clusters. In RKE, ACE is enabled by default in Rancher-launched Kubernetes clusters, using the IP of the node with the `controlplane` role and the default Kubernetes self-signed certificates.
|
||||
ACE must be set up [manually](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md#authorized-cluster-endpoint-support-for-rke2-and-k3s-clusters) on RKE2 and K3s clusters. In RKE, ACE is enabled by default in Rancher-launched Kubernetes clusters, using the IP of the node with the `controlplane` role and the default Kubernetes self-signed certificates.
|
||||
|
||||
For more detail on how an authorized cluster endpoint works and why it is used, refer to the [architecture section.](../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint)
|
||||
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Syncing
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/rancher-server-configuration/sync-clusters"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/rancher-server-configuration/sync-clusters"/>
|
||||
</head>
|
||||
|
||||
Syncing allows Rancher to update cluster values so that they're up to date with the corresponding cluster object hosted in AKS, EKS or GKE. This enables sources other than Rancher to own a hosted cluster’s state.
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: Rancher Agent Options
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/rancher-agent-options"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes/rancher-agent-options"/>
|
||||
</head>
|
||||
|
||||
Rancher deploys an agent on each node to communicate with the node. This pages describes the options that can be passed to the agent. To use these options, you will need to [create a cluster with custom nodes](../../../../pages-for-subheaders/use-existing-nodes.md) and add the options to the generated `docker run` command when adding a node.
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Examples
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/monitoring-v2-configuration/examples"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/monitoring-v2-configuration/examples"/>
|
||||
</head>
|
||||
|
||||
### ServiceMonitor
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Helm Chart Options
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/monitoring-v2-configuration/helm-chart-options"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/monitoring-v2-configuration/helm-chart-options"/>
|
||||
</head>
|
||||
|
||||
## Configuring Resource Limits and Requests
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Receiver Configuration
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/monitoring-v2-configuration/receivers"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/monitoring-v2-configuration/receivers"/>
|
||||
</head>
|
||||
|
||||
The [Alertmanager Config](https://prometheus.io/docs/alerting/latest/configuration/#configuration-file) Secret contains the configuration of an Alertmanager instance that sends out notifications based on alerts it receives from Prometheus.
|
||||
|
||||
@@ -3,7 +3,7 @@ title: Route Configuration
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/monitoring-v2-configuration/routes"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/monitoring-v2-configuration/routes"/>
|
||||
</head>
|
||||
|
||||
The route configuration is the section of the Alertmanager custom resource that controls how the alerts fired by Prometheus are grouped and filtered before they reach the receiver.
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ title: ServiceMonitor and PodMonitor Configuration
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com//reference-guides/monitoring-v2-configuration/servicemonitors-and-podmonitors"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/monitoring-v2-configuration/servicemonitors-and-podmonitors"/>
|
||||
</head>
|
||||
|
||||
ServiceMonitors and PodMonitors are both pseudo-CRDs that map the scrape configuration of the Prometheus custom resource.
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Role-Based Access Control
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/prometheus-federator/rbac"/>
|
||||
</head>
|
||||
|
||||
This section describes the expectations for Role-Based Access Control (RBAC) for Prometheus Federator.
|
||||
|
||||
As described in the section on [namespaces](../../pages-for-subheaders/prometheus-federator.md#namespaces), Prometheus Federator expects that Project Owners, Project Members, and other users in the cluster with Project-level permissions (e.g. permissions in a certain set of namespaces identified by a single label selector) have minimal permissions in any namespaces except the Project Registration Namespace (which is imported into the project by default) and those that already comprise their projects. Therefore, in order to allow Project Owners to assign specific chart permissions to other users in their Project namespaces, the Helm Project Operator will automatically watch the following bindings:
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Architecture Recommendations
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-manager-architecture/architecture-recommendations"/>
|
||||
</head>
|
||||
|
||||
If you are installing Rancher on a single node, the main architecture recommendation that applies to your installation is that the node running Rancher should be [separate from downstream clusters.](#separation-of-rancher-and-user-clusters)
|
||||
|
||||
## Separation of Rancher and User Clusters
|
||||
|
||||
+86
-1
@@ -2,6 +2,10 @@
|
||||
title: Communicating with Downstream User Clusters
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters"/>
|
||||
</head>
|
||||
|
||||
This section describes how Rancher provisions and manages the downstream user clusters that run your apps and services.
|
||||
|
||||
The below diagram shows how the cluster controllers, cluster agents, and node agents allow Rancher to control downstream clusters.
|
||||
@@ -24,7 +28,7 @@ the pods. Bob is authenticated through Rancher's authentication proxy.
|
||||
|
||||
The authentication proxy forwards all Kubernetes API calls to downstream clusters. It integrates with authentication services like local authentication, Active Directory, and GitHub. On every Kubernetes API call, the authentication proxy authenticates the caller and sets the proper Kubernetes impersonation headers before forwarding the call to Kubernetes masters.
|
||||
|
||||
Rancher communicates with Kubernetes clusters using a [service account,](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) which provides an identity for processes that run in a pod.
|
||||
Rancher communicates with Kubernetes clusters using a [service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/). Each user account in Rancher correlates with an equivalent service account in the downstream cluster. Rancher uses the service account to [impersonate](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) the user, which provides all the permissions the user is intended to have.
|
||||
|
||||
By default, Rancher generates a [kubeconfig file](../../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md) that contains credentials for proxying through the Rancher server to connect to the Kubernetes API server on a downstream user cluster. The kubeconfig file (`kube_config_rancher-cluster.yml`) contains full access to the cluster.
|
||||
|
||||
@@ -76,6 +80,87 @@ With this endpoint enabled for the downstream cluster, Rancher generates an extr
|
||||
|
||||
You will need to use a context defined in this kubeconfig file to access the cluster if Rancher goes down. Therefore, we recommend exporting the kubeconfig file so that if Rancher goes down, you can still use the credentials in the file to access your cluster. For more information, refer to the section on accessing your cluster with [kubectl and the kubeconfig file.](../../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md)
|
||||
|
||||
## Impersonation
|
||||
|
||||
Users technically exist only on the upstream cluster. Rancher creates [RoleBindings and ClusterRoleBindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) that refer to Rancher users, even though there is [no actual User resource](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#users-in-kubernetes) on the downstream cluster.
|
||||
|
||||
When users interact with a downstream cluster through the authentication proxy, there needs to be some entity downstream to serve as the actor for those requests. Rancher creates service accounts to be that entity. Each service account is only granted one permission, which is to **impersonate** the user they belong to. If there was only one service account that could impersonate any user, then it would be possible for a malicious user to corrupt that account and escalate their privileges by impersonating another user. This issue was the basis for a [CVE](https://github.com/rancher/rancher/security/advisories/GHSA-pvxj-25m6-7vqr).
|
||||
|
||||
### Impersonation Troubleshooting
|
||||
|
||||
On the downstream cluster, five resources handle impersonation:
|
||||
|
||||
- namespace: `cattle-impersonation-system`
|
||||
- service account: `cattle-impersonation-system/cattle-impersonation-<user ID>`
|
||||
- account token secret: `cattle-impersonation-system/cattle-impersonation-<user ID>-token-<hash>`
|
||||
- cluster role: `cattle-impersonation-<user ID>`
|
||||
- cluster role binding: `cattle-impersonation-<user ID>`
|
||||
|
||||
In this example of a typical impersonation cluster role, the system is configured to use `github` as the auth provider:
|
||||
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
creationTimestamp: "2021-10-06T18:20:13Z"
|
||||
labels:
|
||||
authz.cluster.cattle.io/impersonator: "true"
|
||||
cattle.io/creator: norman
|
||||
name: cattle-impersonation-user-abcde
|
||||
resourceVersion: "3528"
|
||||
uid: a7478731-72a0-4343-b09f-c3bf12552d77
|
||||
rules:
|
||||
# allowed to impersonate user user-abcde
|
||||
- apiGroups:
|
||||
- ""
|
||||
resourceNames:
|
||||
- user-abcde
|
||||
resources:
|
||||
- users
|
||||
verbs:
|
||||
- impersonate
|
||||
# allowed to impersonate listed groups
|
||||
- apiGroups:
|
||||
- ""
|
||||
resourceNames:
|
||||
- github_team://123 # group from GitHub auth provider
|
||||
- system:authenticated # automatic group from Kubernetes
|
||||
- system:cattle:authenticated # automatic group from Rancher
|
||||
resources:
|
||||
- groups
|
||||
verbs:
|
||||
- impersonate
|
||||
# allowed to impersonate principal ID github_user://098
|
||||
- apiGroups:
|
||||
- authentication.k8s.io
|
||||
resourceNames:
|
||||
- github_user://098 # principal ID from GitHub auth provider
|
||||
resources:
|
||||
- userextras/principalid
|
||||
verbs:
|
||||
- impersonate
|
||||
# allowed to impersonate username example
|
||||
- apiGroups:
|
||||
- authentication.k8s.io
|
||||
resourceNames:
|
||||
- example # username from GitHub auth provider
|
||||
resources:
|
||||
- userextras/username
|
||||
verbs:
|
||||
- impersonate
|
||||
```
|
||||
|
||||
When you troubleshoot impersonation issues, check whether these resources exist for the user, and whether the rules in the cluster role look similar to the above. For example:
|
||||
|
||||
```bash
|
||||
kubectl --namespace cattle-impersonation-system get serviceaccount cattle-impersonation-<user ID>
|
||||
kubectl --namespace cattle-impersonation-system get secret cattle-impersonation-<user ID>-token-<hash>
|
||||
kubectl get clusterrole cattle-impersonation-<user ID> --output yaml
|
||||
kubectl get clusterrolebinding cattle-impersonation-<user ID>
|
||||
```
|
||||
|
||||
If you see an error related to "impersonation" in the UI, pay close attention to the *end* of the error message, which should indicate the real reason that the request failed.
|
||||
|
||||
## Important Files
|
||||
|
||||
The files mentioned below are needed to maintain, troubleshoot and upgrade your cluster:
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Rancher Server and Components
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-manager-architecture/rancher-server-and-components"/>
|
||||
</head>
|
||||
|
||||
The majority of Rancher 2.x software runs on the Rancher Server. Rancher Server includes all the software components used to manage the entire Rancher deployment.
|
||||
|
||||
The figure below illustrates the high-level architecture of Rancher 2.x. The figure depicts a Rancher Server installation that manages two downstream Kubernetes clusters: one created by RKE and another created by Amazon EKS (Elastic Kubernetes Service).
|
||||
|
||||
+4
@@ -2,6 +2,10 @@
|
||||
title: K3s Self-Assessment Guide - CIS Benchmark v1.23 - K8s v1.23
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/hardening-guides/k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.23-k8s-v1.23"/>
|
||||
</head>
|
||||
|
||||
This document is a companion to the [K3s Hardening Guide](../../../../pages-for-subheaders/k3s-hardening-guide.md), which provides prescriptive guidance on how to harden K3s clusters that are running in production and managed by Rancher. This benchmark guide helps you evaluate the security of a hardened cluster against each control in the CIS Kubernetes Benchmark.
|
||||
|
||||
This guide corresponds to the following versions of Rancher, CIS Benchmarks, and Kubernetes:
|
||||
|
||||
-3148
File diff suppressed because it is too large
Load Diff
+3208
File diff suppressed because it is too large
Load Diff
+3215
File diff suppressed because it is too large
Load Diff
-3148
File diff suppressed because it is too large
Load Diff
+4
@@ -2,6 +2,10 @@
|
||||
title: RKE Self-Assessment Guide - CIS Benchmark v1.23 - K8s v1.23
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.23-k8s-v1.23"/>
|
||||
</head>
|
||||
|
||||
This document is a companion to the [RKE Hardening Guide](../../../../pages-for-subheaders/rke1-hardening-guide.md), which provides prescriptive guidance on how to harden RKE clusters that are running in production and managed by Rancher. This benchmark guide helps you evaluate the security of a hardened cluster against each control in the CIS Kubernetes Benchmark.
|
||||
|
||||
This guide corresponds to the following versions of Rancher, CIS Benchmarks, and Kubernetes:
|
||||
|
||||
-3084
File diff suppressed because one or more lines are too long
+3047
File diff suppressed because it is too large
Load Diff
+2863
File diff suppressed because it is too large
Load Diff
-3085
File diff suppressed because one or more lines are too long
+4
@@ -2,6 +2,10 @@
|
||||
title: RKE2 Self-Assessment Guide - CIS Benchmark v1.23 - K8s v1.23
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/hardening-guides/rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.23-k8s-v1.23"/>
|
||||
</head>
|
||||
|
||||
This document is a companion to the [RKE2 Hardening Guide](../../../../pages-for-subheaders/rke2-hardening-guide.md), which provides prescriptive guidance on how to harden RKE2 clusters that are running in production and managed by Rancher. This benchmark guide helps you evaluate the security of a hardened cluster against each control in the CIS Kubernetes Benchmark.
|
||||
|
||||
This guide corresponds to the following versions of Rancher, CIS Benchmarks, and Kubernetes:
|
||||
|
||||
-3196
File diff suppressed because one or more lines are too long
+3202
File diff suppressed because one or more lines are too long
+2967
File diff suppressed because it is too large
Load Diff
-3196
File diff suppressed because one or more lines are too long
@@ -2,6 +2,10 @@
|
||||
title: Kubernetes Security Best Practices
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/kubernetes-security-best-practices"/>
|
||||
</head>
|
||||
|
||||
### Restricting cloud metadata API access
|
||||
|
||||
Cloud providers such as AWS, Azure, DigitalOcean or GCP often expose metadata services locally to instances. By default, this endpoint is accessible by pods running on a cloud instance, including pods in hosted Kubernetes providers such as EKS, AKS, DigitalOcean Kubernetes or GKE, and can contain cloud credentials for that node, provisioning data such as kubelet credentials, or other sensitive data. To mitigate this risk when running on a cloud platform, follow the [Kubernetes security recommendations](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/#restricting-cloud-metadata-api-access): limit permissions given to instance credentials, use network policies to restrict pod access to the metadata API, and avoid using provisioning data to deliver secrets.
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Sample PodSecurityConfiguration
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/psa-restricted-exemptions"/>
|
||||
</head>
|
||||
|
||||
The following PodSecurityConfiguration contains the required Rancher namespace exemptions for a `rancher-restricted` cluster to run properly.
|
||||
|
||||
```yaml
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: Security Advisories and CVEs
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/security-advisories-and-cves"/>
|
||||
</head>
|
||||
|
||||
Rancher is committed to informing the community of security issues in our products. Rancher will publish security advisories and CVEs (Common Vulnerabilities and Exposures) for issues we have resolved. New security advisories are also published in Rancher's GitHub [security page](https://github.com/rancher/rancher/security/advisories).
|
||||
|
||||
| ID | Description | Date | Resolution |
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: About rancher-selinux
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/selinux-rpm/about-rancher-selinux"/>
|
||||
</head>
|
||||
|
||||
To allow Rancher to work with SELinux, some functionality has to be manually enabled for the SELinux nodes. To help with that, Rancher provides a SELinux RPM.
|
||||
|
||||
The `rancher-selinux` RPM only contains policies for the [rancher-logging application.](https://github.com/rancher/charts/tree/dev-v2.5/charts/rancher-logging)
|
||||
|
||||
@@ -2,6 +2,10 @@
|
||||
title: About rke2-selinux
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/rancher-security/selinux-rpm/about-rke2-selinux"/>
|
||||
</head>
|
||||
|
||||
`rke2-selinux` provides policies for RKE2. It is installed automatically when the RKE2 installer script detects that it is running on an RPM-based distro.
|
||||
|
||||
The `rke2-selinux` GitHub repository is [here.](https://github.com/rancher/rke2-selinux)
|
||||
|
||||
Reference in New Issue
Block a user