mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-29 14:38:50 +00:00
Compare commits
75
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
9cb79db3db | ||
|
|
3d868453d3 | ||
|
|
07741dfc48 | ||
|
|
04d996984f | ||
|
|
a025bee29f | ||
|
|
5608d3a7e9 | ||
|
|
bd3447eec5 | ||
|
|
c4802f036d | ||
|
|
dadc85b0f4 | ||
|
|
34a3c15409 | ||
|
|
ac40bb0ea1 | ||
|
|
1b61165bfd | ||
|
|
589363b3bf | ||
|
|
6b5c953747 | ||
|
|
1ce86b0926 | ||
|
|
a2d2a88054 | ||
|
|
e317ba5076 | ||
|
|
d46b6efe22 | ||
|
|
7df7b91fc4 | ||
|
|
ea245e3f5b | ||
|
|
db25cc87a5 | ||
|
|
a7e5e2b9cd | ||
|
|
8040234882 | ||
|
|
8a7de06bb8 | ||
|
|
93a4f79512 | ||
|
|
7d51fdb720 | ||
|
|
16a44f3fab | ||
|
|
382447e1e1 | ||
|
|
8d50cb4cb8 | ||
|
|
304fbc7944 | ||
|
|
bf382897c9 | ||
|
|
9b7d9595f8 | ||
|
|
5afadf201c | ||
|
|
7f02d2bca2 | ||
|
|
3ab49d575a | ||
|
|
60e77489ca | ||
|
|
cd6b09a947 | ||
|
|
94ce568974 | ||
|
|
fd780d0cfb | ||
|
|
c72420642a | ||
|
|
0c56e643ad | ||
|
|
632569305c | ||
|
|
dd6193ab30 | ||
|
|
1ac9342705 | ||
|
|
c9e51f3940 | ||
|
|
0b50813ef4 | ||
|
|
02c1192494 | ||
|
|
c81ab8ad1b | ||
|
|
c2f2645af9 | ||
|
|
25450ce3f0 | ||
|
|
58d5735ea5 | ||
|
|
ceba62a306 | ||
|
|
52d6c14efb | ||
|
|
df9d7ab0a8 | ||
|
|
cfe40b0a86 | ||
|
|
bb75ae1765 | ||
|
|
7400482b35 | ||
|
|
28617e4be1 | ||
|
|
7370fefe3c | ||
|
|
a0f600a998 | ||
|
|
6b36d00b9b | ||
|
|
3fde374c30 | ||
|
|
b737561d7b | ||
|
|
65d21cfc40 | ||
|
|
011085ac2d | ||
|
|
6fd409221d | ||
|
|
1e93509c84 | ||
|
|
0ca00b121d | ||
|
|
9ae6f022fc | ||
|
|
ee9876f04a | ||
|
|
45bf343dba | ||
|
|
38a442100c | ||
|
|
6112a7b128 | ||
|
|
bee7f2e892 | ||
|
|
bd87f0973b |
@@ -0,0 +1,8 @@
|
||||
version: 2
|
||||
|
||||
updates:
|
||||
- package-ecosystem: gitsubmodule
|
||||
schedule:
|
||||
interval: "daily"
|
||||
directory: /
|
||||
|
||||
Submodule .github/styles/suse-vale-styleguide updated: 06f144fdfc...1701ad82d0
@@ -4,6 +4,8 @@ on:
|
||||
push:
|
||||
branches:
|
||||
- main
|
||||
paths-ignore:
|
||||
- '**/README.md'
|
||||
|
||||
jobs:
|
||||
build:
|
||||
|
||||
@@ -2,8 +2,8 @@ name: Test deployment
|
||||
|
||||
on:
|
||||
pull_request:
|
||||
branches:
|
||||
- main
|
||||
paths-ignore:
|
||||
- '**/README.md'
|
||||
|
||||
jobs:
|
||||
test-deploy:
|
||||
|
||||
@@ -5,7 +5,10 @@
|
||||
# It uses Vale (https://vale.sh/docs/vale-cli/installation/) to provide feedback base off the SUSE Style Guide / OpenSUSE style rules (https://github.com/openSUSE/suse-vale-styleguide)
|
||||
|
||||
name: Style check
|
||||
on: [pull_request]
|
||||
on:
|
||||
pull_request:
|
||||
paths-ignore:
|
||||
- '**/README.md'
|
||||
|
||||
jobs:
|
||||
vale-lint:
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
StylesPath = .github/styles
|
||||
StylesPath = .github/styles/suse-vale-styleguide
|
||||
|
||||
[formtats]
|
||||
mdx = md
|
||||
|
||||
[*.md]
|
||||
BasedOnStyles = suse-vale-styleguide
|
||||
BasedOnStyles = common
|
||||
@@ -15,9 +15,9 @@ To get started, [fork](https://github.com/rancher/rancher-docs/fork) and clone t
|
||||
|
||||
Our repository doesn't allow you to make changes directly to the `main` branch. Create a working branch and make pull requests from your fork to [rancher/rancher-docs](https://github.com/rancher/rancher-docs).
|
||||
|
||||
For most updates, you'll need to edit a file in the `/docs` directory, which represents the ["Latest"](https://ranchermanager.docs.rancher.com/) version of our published documentation. The "Latest" version is a mirror of the most recently released version of Rancher. As of December 2023, the most recently released version of Rancher is 2.8.
|
||||
For most updates, you'll need to edit a file in the `/docs` directory, which represents the ["Latest"](https://ranchermanager.docs.rancher.com/) version of our published documentation. The "Latest" version is a mirror of the most recently released version of Rancher. As of August 2024, the most recently released version of Rancher is 2.9.
|
||||
|
||||
Whenever an update is made to `/docs`, you should apply the same change to the corresponding file in `/versioned_docs/version-2.8`. If a change only affects older versions, you don't need to mirror it to the `/docs` directory.
|
||||
Whenever an update is made to `/docs`, you should apply the same change to the corresponding file in `/versioned_docs/version-2.9`. If a change only affects older versions, you don't need to mirror it to the `/docs` directory.
|
||||
|
||||
If a file is moved or renamed, you'll also need to edit the `sidebars.js` files for each affected version, as well as the list of redirects in `docusaurus.config.js`. See [Moving or Renaming Docs](./moving-or-renaming-docs.md).
|
||||
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
---
|
||||
title: API Reference
|
||||
hide_table_of_contents: true
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
@@ -16,7 +16,8 @@ Rancher will publish deprecated features as part of the [release notes](https://
|
||||
|
||||
| Patch Version | Release Date |
|
||||
|---------------|---------------|
|
||||
| [2.9.0](https://github.com/rancher/rancher/releases/tag/v2.9.0) | July 31, 2024 |
|
||||
| [2.9.1](https://github.com/rancher/rancher/releases/tag/v2.9.1) | Aug 26, 2024 |
|
||||
| [2.9.0](https://github.com/rancher/rancher/releases/tag/v2.9.0) | Jul 31, 2024 |
|
||||
|
||||
### What can I expect when a feature is marked for deprecation?
|
||||
|
||||
|
||||
+2
-2
@@ -148,7 +148,7 @@ To see options on how to customize the cert-manager install (including for cases
|
||||
:::
|
||||
|
||||
```
|
||||
# If you have installed the CRDs manually instead of with the `--set installCRDs=true` option added to your Helm install command, you should upgrade your CRD resources before upgrading the Helm chart:
|
||||
# If you have installed the CRDs manually, instead of setting `installCRDs` or `crds.enabled` to `true` in your Helm install command, you should upgrade your CRD resources before upgrading the Helm chart:
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/<VERSION>/cert-manager.crds.yaml
|
||||
|
||||
# Add the Jetstack Helm repository
|
||||
@@ -161,7 +161,7 @@ helm repo update
|
||||
helm install cert-manager jetstack/cert-manager \
|
||||
--namespace cert-manager \
|
||||
--create-namespace \
|
||||
--set installCRDs=true
|
||||
--set crds.enabled=true
|
||||
```
|
||||
|
||||
Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the cert-manager namespace for running pods:
|
||||
|
||||
+1
-1
@@ -46,6 +46,6 @@ A: You can use a runtime like containerd with Kubernetes that does not require D
|
||||
|
||||
Q: If I am already using RKE1 and want to switch to RKE2, what are my migration options?
|
||||
|
||||
A: Today, you can stand up a new cluster and migrate workloads to a new RKE2 cluster that uses containerd. Rancher is exploring the possibility of an in-place upgrade path.
|
||||
A: Today, you can stand up a new cluster and migrate workloads to a new RKE2 cluster that uses containerd. For details, see the [RKE to RKE2 Replatforming Guide](https://links.imagerelay.com/cdn/3404/ql/5606a3da2365422ab2250d348aa07112/rke_to_rke2_replatforming_guide.pdf).
|
||||
|
||||
<br/>
|
||||
|
||||
+2
-2
@@ -27,7 +27,7 @@ First configure the HTTP proxy settings on the K3s systemd service, so that K3s'
|
||||
```
|
||||
cat <<'EOF' | sudo tee /etc/default/k3s > /dev/null
|
||||
HTTP_PROXY=http://${proxy_host}
|
||||
HTTPS_PROXY=http://${proxy_host}"
|
||||
HTTPS_PROXY=http://${proxy_host}
|
||||
NO_PROXY=127.0.0.0/8,10.0.0.0/8,cattle-system.svc,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local
|
||||
EOF
|
||||
```
|
||||
@@ -71,7 +71,7 @@ Then you have to configure the HTTP proxy settings on the RKE2 systemd service,
|
||||
```
|
||||
cat <<'EOF' | sudo tee /etc/default/rke2-server > /dev/null
|
||||
HTTP_PROXY=http://${proxy_host}
|
||||
HTTPS_PROXY=http://${proxy_host}"
|
||||
HTTPS_PROXY=http://${proxy_host}
|
||||
NO_PROXY=127.0.0.0/8,10.0.0.0/8,cattle-system.svc,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local
|
||||
EOF
|
||||
```
|
||||
|
||||
+14
-2
@@ -54,8 +54,20 @@ Since the private registry cannot be configured after the cluster is created, yo
|
||||
1. Select **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, click **Create**.
|
||||
1. Choose a cluster type.
|
||||
1. In the **Cluster Configuration** go to the **Registries** tab and select **Pull images for Rancher from a private registry**.
|
||||
1. Enter the registry hostname and credentials.
|
||||
1. In the **Cluster Configuration** go to the **Registries** tab.
|
||||
1. Check the box next to **Enable cluster scoped container registry for Rancher system container images**.
|
||||
1. Enter the registry hostname.
|
||||
1. Under **Authentication** select **Create a HTTP Basic Auth Secret** and fill in the credential fields.
|
||||
1. Click **Create**.
|
||||
|
||||
**Result:** The new cluster pulls images from the private registry.
|
||||
|
||||
### Working with Private Registry Credentials
|
||||
|
||||
When working with private registries, it is important to ensure that any secrets created for these registries are properly backed up. When you add a private registry credential secret through the Rancher GUI and select **Create a HTTP Basic Auth Secret**, the secret is included in backup operations using Rancher Backups.
|
||||
|
||||
However, if you create a credential secret outside of the Rancher GUI, such as by using kubectl or Terraform, you must add the `fleet.cattle.io/managed=true` label to indicate that the secret should be included in backups created by Rancher Backups.
|
||||
|
||||
For example, if you have a custom private registry named "my-private-registry" and create a secret called "my-reg-creds" for it, apply the `fleet.cattle.io/managed=true` label to this secret. This ensures that your backup process captures the secret, providing easy restoration if needed.
|
||||
|
||||
By following this guidance, you can ensure that all of your private registry credentials are backed up and easily accessible in the event of a restore or migration.
|
||||
|
||||
+2
-2
@@ -19,7 +19,7 @@ These nodes must be in the same region. You may place these servers in separate
|
||||
To install the Rancher management server on a high-availability RKE2 cluster, we recommend setting up the following infrastructure:
|
||||
|
||||
- **Three Linux nodes,** typically virtual machines, in the infrastructure provider of your choice.
|
||||
- **A load balancer** to direct traffic to the two nodes.
|
||||
- **A load balancer** to direct traffic to the nodes.
|
||||
- **A DNS record** to map a URL to the load balancer. This will become the Rancher server URL, and downstream Kubernetes clusters will need to reach it.
|
||||
|
||||
### 1. Set up Linux Nodes
|
||||
@@ -59,4 +59,4 @@ Depending on your environment, this may be an A record pointing to the load bala
|
||||
|
||||
You will need to specify this hostname in a later step when you install Rancher, and it is not possible to change it later. Make sure that your decision is a final one.
|
||||
|
||||
For a how-to guide for setting up a DNS record to route domain traffic to an Amazon ELB load balancer, refer to the [official AWS documentation.](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer)
|
||||
For a how-to guide for setting up a DNS record to route domain traffic to an Amazon ELB load balancer, refer to the [official AWS documentation.](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer)
|
||||
|
||||
+2
-1
@@ -19,7 +19,8 @@ In order to deploy and run the adapter successfully, you need to ensure its vers
|
||||
|
||||
| Rancher Version | Adapter Version |
|
||||
|-----------------|:----------------:|
|
||||
| v2.9.0 | v104.0.0+up4.0.0 |
|
||||
| v2.9.1 | v104.0.0+up4.0.0 |
|
||||
| v2.9.0 | v104.0.0+up4.0.0 |
|
||||
|
||||
### 1. Gain Access to the Local Cluster
|
||||
|
||||
|
||||
+6
@@ -89,6 +89,12 @@ We recommend exporting the kubeconfig file so that if Rancher goes down, you can
|
||||
|
||||
## Impersonation
|
||||
|
||||
:::caution Known Issue
|
||||
|
||||
Service account impersonation (`--as`) used by lower privileged user accounts to remove privileges is not implemented and is a [feature](https://github.com/rancher/rancher/issues/41988) being tracked.
|
||||
|
||||
:::
|
||||
|
||||
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).
|
||||
|
||||
@@ -20,6 +20,7 @@ Each Rancher version is designed to be compatible with a single version of the w
|
||||
|
||||
| Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
|
||||
|-----------------|-----------------|-----------------------|---------------------------|
|
||||
| v2.9.1 | v0.5.1 | ✓ | ✓ |
|
||||
| v2.9.0 | v0.5.0 | ✗ | ✓ |
|
||||
|
||||
## Why Do We Need It?
|
||||
|
||||
@@ -185,9 +185,9 @@ module.exports = {
|
||||
label: 'Latest',
|
||||
},
|
||||
2.9: {
|
||||
label: 'v2.9 (Preview)',
|
||||
label: 'v2.9',
|
||||
path: 'v2.9',
|
||||
banner: 'unreleased'
|
||||
banner: 'none'
|
||||
},
|
||||
2.8: {
|
||||
label: 'v2.8',
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
<!-- releaseTask -->
|
||||
The following table summarizes different GitHub metrics to give you an idea of each project's popularity and activity levels. This data was collected in March 2024.
|
||||
The following table summarizes different GitHub metrics to give you an idea of each project's popularity and activity levels. This data was collected in August 2024.
|
||||
|
||||
| Provider | Project | Stars | Forks | Contributors |
|
||||
| ---- | ---- | ---- | ---- | ---- |
|
||||
| Canal | https://github.com/projectcalico/canal | 714 | 100 | 20 |
|
||||
| Canal | https://github.com/projectcalico/canal | 715 | 100 | 20 |
|
||||
| Flannel | https://github.com/flannel-io/flannel | 8.7k | 2.9k | 235 |
|
||||
| Calico | https://github.com/projectcalico/calico | 5.8k | 1.3k | 353 |
|
||||
| Weave | https://github.com/weaveworks/weave/ | 6.6k | 668 | 87 |
|
||||
| Cilium | https://github.com/cilium/cilium | 19.4k | 2.8k | 775 |
|
||||
| Calico | https://github.com/projectcalico/calico | 5.8k | 1.3k | 354 |
|
||||
| Weave | https://github.com/weaveworks/weave/ | 6.6k | 667 | 87 |
|
||||
| Cilium | https://github.com/cilium/cilium | 19.4k | 2.9k | 796 |
|
||||
|
||||
+37
-5
@@ -18,12 +18,12 @@ Here you can find links to supporting documentation for the current released ver
|
||||
<th>Community</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.9.0</b></td>
|
||||
<td><b>v2.9.1</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.9">Documentation</a></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.9.0">Release Notes</a></td>
|
||||
<td><center>N/A</center></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.9.1">Release Notes</a></td>
|
||||
<td><center>N/A</center></td>
|
||||
<td><center>✓</center></td>
|
||||
<td><center>✓</center></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
@@ -39,9 +39,9 @@ Here you can find links to supporting documentation for the current released ver
|
||||
<th>Community</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.8.6</b></td>
|
||||
<td><b>v2.8.7</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.8">Documentation</a></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.8.6">Release Notes</a></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.8.7">Release Notes</a></td>
|
||||
<td><center>N/A</center></td>
|
||||
<td><center>✓</center></td>
|
||||
<td><center>N/A</center></td>
|
||||
@@ -88,6 +88,30 @@ Here you can find links to supporting documentation for the current released ver
|
||||
|
||||
### Past Versions
|
||||
|
||||
Here you can find links to supporting documentation for previous versions of Rancher v2.9, and their availability for [Rancher Prime](/v2.9/getting-started/quick-start-guides/deploy-rancher-manager/prime) and the Community version of Rancher:
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th>Version</th>
|
||||
<th>Documentation</th>
|
||||
<th>Release Notes</th>
|
||||
<th>Support Matrix</th>
|
||||
<th>Prime</th>
|
||||
<th>Community</th>
|
||||
</tr>
|
||||
|
||||
<tr>
|
||||
<td><b>v2.9.0</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.9">Documentation</a></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.9.0">Release Notes</a></td>
|
||||
<td><center>N/A</center></td>
|
||||
<td><center>N/A</center></td>
|
||||
<td><center>✓</center></td>
|
||||
</tr>
|
||||
<tr>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
Here you can find links to supporting documentation for previous versions of Rancher v2.8, and their availability for [Rancher Prime](/v2.8/getting-started/quick-start-guides/deploy-rancher-manager/prime) and the Community version of Rancher:
|
||||
|
||||
<table>
|
||||
@@ -98,6 +122,14 @@ Here you can find links to supporting documentation for previous versions of Ran
|
||||
<th>Support Matrix</th>
|
||||
<th>Prime</th>
|
||||
<th>Community</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.8.6</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.8">Documentation</a></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.8.6">Release Notes</a></td>
|
||||
<td><center>N/A</center></td>
|
||||
<td><center>✓</center></td>
|
||||
<td><center>N/A</center></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.8.5</b></td>
|
||||
|
||||
+2
-2
@@ -15,7 +15,7 @@ The recommended infrastructure for the Rancher-only Kubernetes cluster differs d
|
||||
To install the Rancher management server on a high-availability RKE2 cluster, we recommend setting up the following infrastructure:
|
||||
|
||||
- **Three Linux nodes,** typically virtual machines, in the infrastructure provider of your choice.
|
||||
- **A load balancer** to direct traffic to the two nodes.
|
||||
- **A load balancer** to direct traffic to the nodes.
|
||||
- **A DNS record** to map a URL to the load balancer. This will become the Rancher server URL, and downstream Kubernetes clusters will need to reach it.
|
||||
|
||||
### 1. Set up Linux Nodes
|
||||
@@ -52,4 +52,4 @@ Depending on your environment, this may be an A record pointing to the load bala
|
||||
|
||||
You will need to specify this hostname in a later step when you install Rancher, and it is not possible to change it later. Make sure that your decision is a final one.
|
||||
|
||||
For a how-to guide for setting up a DNS record to route domain traffic to an Amazon ELB load balancer, refer to the [official AWS documentation.](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer)
|
||||
For a how-to guide for setting up a DNS record to route domain traffic to an Amazon ELB load balancer, refer to the [official AWS documentation.](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer)
|
||||
|
||||
+1
-1
@@ -46,6 +46,6 @@ A: You can use a runtime like containerd with Kubernetes that does not require D
|
||||
|
||||
Q: If I am already using RKE1 and want to switch to RKE2, what are my migration options?
|
||||
|
||||
A: Today, you can stand up a new cluster and migrate workloads to a new RKE2 cluster that uses containerd. Rancher is exploring the possibility of an in-place upgrade path.
|
||||
A: Today, you can stand up a new cluster and migrate workloads to a new RKE2 cluster that uses containerd. For details, see the [RKE to RKE2 Replatforming Guide](https://links.imagerelay.com/cdn/3404/ql/5606a3da2365422ab2250d348aa07112/rke_to_rke2_replatforming_guide.pdf).
|
||||
|
||||
<br/>
|
||||
|
||||
+2
-2
@@ -19,7 +19,7 @@ These nodes must be in the same region. You may place these servers in separate
|
||||
To install the Rancher management server on a high-availability RKE2 cluster, we recommend setting up the following infrastructure:
|
||||
|
||||
- **Three Linux nodes,** typically virtual machines, in the infrastructure provider of your choice.
|
||||
- **A load balancer** to direct traffic to the two nodes.
|
||||
- **A load balancer** to direct traffic to the nodes.
|
||||
- **A DNS record** to map a URL to the load balancer. This will become the Rancher server URL, and downstream Kubernetes clusters will need to reach it.
|
||||
|
||||
### 1. Set up Linux Nodes
|
||||
@@ -59,4 +59,4 @@ Depending on your environment, this may be an A record pointing to the load bala
|
||||
|
||||
You will need to specify this hostname in a later step when you install Rancher, and it is not possible to change it later. Make sure that your decision is a final one.
|
||||
|
||||
For a how-to guide for setting up a DNS record to route domain traffic to an Amazon ELB load balancer, refer to the [official AWS documentation.](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer)
|
||||
For a how-to guide for setting up a DNS record to route domain traffic to an Amazon ELB load balancer, refer to the [official AWS documentation.](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer)
|
||||
|
||||
+6
@@ -82,6 +82,12 @@ You will need to use a context defined in this kubeconfig file to access the clu
|
||||
|
||||
## Impersonation
|
||||
|
||||
:::caution Known Issue
|
||||
|
||||
Service account impersonation (`--as`) used by lower privileged user accounts to remove privileges is not implemented and is a [feature](https://github.com/rancher/rancher/issues/41988) being tracked.
|
||||
|
||||
:::
|
||||
|
||||
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).
|
||||
|
||||
+2
-2
@@ -148,7 +148,7 @@ To see options on how to customize the cert-manager install (including for cases
|
||||
:::
|
||||
|
||||
```
|
||||
# If you have installed the CRDs manually instead of with the `--set installCRDs=true` option added to your Helm install command, you should upgrade your CRD resources before upgrading the Helm chart:
|
||||
# If you have installed the CRDs manually, instead of setting `installCRDs` or `crds.enabled` to `true` in your Helm install command, you should upgrade your CRD resources before upgrading the Helm chart:
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/<VERSION>/cert-manager.crds.yaml
|
||||
|
||||
# Add the Jetstack Helm repository
|
||||
@@ -161,7 +161,7 @@ helm repo update
|
||||
helm install cert-manager jetstack/cert-manager \
|
||||
--namespace cert-manager \
|
||||
--create-namespace \
|
||||
--set installCRDs=true
|
||||
--set crds.enabled=true
|
||||
```
|
||||
|
||||
Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the cert-manager namespace for running pods:
|
||||
|
||||
+1
-1
@@ -46,6 +46,6 @@ A: You can use a runtime like containerd with Kubernetes that does not require D
|
||||
|
||||
Q: If I am already using RKE1 and want to switch to RKE2, what are my migration options?
|
||||
|
||||
A: Today, you can stand up a new cluster and migrate workloads to a new RKE2 cluster that uses containerd. Rancher is exploring the possibility of an in-place upgrade path.
|
||||
A: Today, you can stand up a new cluster and migrate workloads to a new RKE2 cluster that uses containerd. For details, see the [RKE to RKE2 Replatforming Guide](https://links.imagerelay.com/cdn/3404/ql/5606a3da2365422ab2250d348aa07112/rke_to_rke2_replatforming_guide.pdf).
|
||||
|
||||
<br/>
|
||||
|
||||
+2
-2
@@ -27,7 +27,7 @@ First configure the HTTP proxy settings on the K3s systemd service, so that K3s'
|
||||
```
|
||||
cat <<'EOF' | sudo tee /etc/default/k3s > /dev/null
|
||||
HTTP_PROXY=http://${proxy_host}
|
||||
HTTPS_PROXY=http://${proxy_host}"
|
||||
HTTPS_PROXY=http://${proxy_host}
|
||||
NO_PROXY=127.0.0.0/8,10.0.0.0/8,cattle-system.svc,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local
|
||||
EOF
|
||||
```
|
||||
@@ -71,7 +71,7 @@ Then you have to configure the HTTP proxy settings on the RKE2 systemd service,
|
||||
```
|
||||
cat <<'EOF' | sudo tee /etc/default/rke2-server > /dev/null
|
||||
HTTP_PROXY=http://${proxy_host}
|
||||
HTTPS_PROXY=http://${proxy_host}"
|
||||
HTTPS_PROXY=http://${proxy_host}
|
||||
NO_PROXY=127.0.0.0/8,10.0.0.0/8,cattle-system.svc,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local
|
||||
EOF
|
||||
```
|
||||
|
||||
+2
-2
@@ -19,7 +19,7 @@ These nodes must be in the same region. You may place these servers in separate
|
||||
To install the Rancher management server on a high-availability RKE2 cluster, we recommend setting up the following infrastructure:
|
||||
|
||||
- **Three Linux nodes,** typically virtual machines, in the infrastructure provider of your choice.
|
||||
- **A load balancer** to direct traffic to the two nodes.
|
||||
- **A load balancer** to direct traffic to the nodes.
|
||||
- **A DNS record** to map a URL to the load balancer. This will become the Rancher server URL, and downstream Kubernetes clusters will need to reach it.
|
||||
|
||||
### 1. Set up Linux Nodes
|
||||
@@ -59,4 +59,4 @@ Depending on your environment, this may be an A record pointing to the load bala
|
||||
|
||||
You will need to specify this hostname in a later step when you install Rancher, and it is not possible to change it later. Make sure that your decision is a final one.
|
||||
|
||||
For a how-to guide for setting up a DNS record to route domain traffic to an Amazon ELB load balancer, refer to the [official AWS documentation.](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer)
|
||||
For a how-to guide for setting up a DNS record to route domain traffic to an Amazon ELB load balancer, refer to the [official AWS documentation.](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer)
|
||||
|
||||
+6
@@ -81,6 +81,12 @@ You will need to use a context defined in this kubeconfig file to access the clu
|
||||
|
||||
## Impersonation
|
||||
|
||||
:::caution Known Issue
|
||||
|
||||
Service account impersonation (`--as`) used by lower privileged user accounts to remove privileges is not implemented and is a [feature](https://github.com/rancher/rancher/issues/41988) being tracked.
|
||||
|
||||
:::
|
||||
|
||||
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).
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
---
|
||||
title: API Reference
|
||||
hide_table_of_contents: true
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
@@ -16,8 +16,9 @@ Rancher will publish deprecated features as part of the [release notes](https://
|
||||
|
||||
| Patch Version | Release Date |
|
||||
|---------------|---------------|
|
||||
| [2.8.6](https://github.com/rancher/rancher/releases/tag/v2.8.6) | July 31, 2024 |
|
||||
| [2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) | June 17, 2024 |
|
||||
| [2.8.7](https://github.com/rancher/rancher/releases/tag/v2.8.7) | Aug 26, 2024 |
|
||||
| [2.8.6](https://github.com/rancher/rancher/releases/tag/v2.8.6) | Jul 31, 2024 |
|
||||
| [2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) | Jun 17, 2024 |
|
||||
| [2.8.4](https://github.com/rancher/rancher/releases/tag/v2.8.4) | May 16, 2024 |
|
||||
| [2.8.3](https://github.com/rancher/rancher/releases/tag/v2.8.3) | Mar 28, 2024 |
|
||||
| [2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2) | Feb 8, 2024 |
|
||||
|
||||
+2
-2
@@ -148,7 +148,7 @@ To see options on how to customize the cert-manager install (including for cases
|
||||
:::
|
||||
|
||||
```
|
||||
# If you have installed the CRDs manually instead of with the `--set installCRDs=true` option added to your Helm install command, you should upgrade your CRD resources before upgrading the Helm chart:
|
||||
# If you have installed the CRDs manually, instead of setting `installCRDs` or `crds.enabled` to `true` in your Helm install command, you should upgrade your CRD resources before upgrading the Helm chart:
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/<VERSION>/cert-manager.crds.yaml
|
||||
|
||||
# Add the Jetstack Helm repository
|
||||
@@ -161,7 +161,7 @@ helm repo update
|
||||
helm install cert-manager jetstack/cert-manager \
|
||||
--namespace cert-manager \
|
||||
--create-namespace \
|
||||
--set installCRDs=true
|
||||
--set crds.enabled=true
|
||||
```
|
||||
|
||||
Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the cert-manager namespace for running pods:
|
||||
|
||||
+1
-1
@@ -46,6 +46,6 @@ A: You can use a runtime like containerd with Kubernetes that does not require D
|
||||
|
||||
Q: If I am already using RKE1 and want to switch to RKE2, what are my migration options?
|
||||
|
||||
A: Today, you can stand up a new cluster and migrate workloads to a new RKE2 cluster that uses containerd. Rancher is exploring the possibility of an in-place upgrade path.
|
||||
A: Today, you can stand up a new cluster and migrate workloads to a new RKE2 cluster that uses containerd. For details, see the [RKE to RKE2 Replatforming Guide](https://links.imagerelay.com/cdn/3404/ql/5606a3da2365422ab2250d348aa07112/rke_to_rke2_replatforming_guide.pdf).
|
||||
|
||||
<br/>
|
||||
|
||||
+2
-2
@@ -27,7 +27,7 @@ First configure the HTTP proxy settings on the K3s systemd service, so that K3s'
|
||||
```
|
||||
cat <<'EOF' | sudo tee /etc/default/k3s > /dev/null
|
||||
HTTP_PROXY=http://${proxy_host}
|
||||
HTTPS_PROXY=http://${proxy_host}"
|
||||
HTTPS_PROXY=http://${proxy_host}
|
||||
NO_PROXY=127.0.0.0/8,10.0.0.0/8,cattle-system.svc,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local
|
||||
EOF
|
||||
```
|
||||
@@ -71,7 +71,7 @@ Then you have to configure the HTTP proxy settings on the RKE2 systemd service,
|
||||
```
|
||||
cat <<'EOF' | sudo tee /etc/default/rke2-server > /dev/null
|
||||
HTTP_PROXY=http://${proxy_host}
|
||||
HTTPS_PROXY=http://${proxy_host}"
|
||||
HTTPS_PROXY=http://${proxy_host}
|
||||
NO_PROXY=127.0.0.0/8,10.0.0.0/8,cattle-system.svc,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local
|
||||
EOF
|
||||
```
|
||||
|
||||
+14
-2
@@ -54,8 +54,20 @@ Since the private registry cannot be configured after the cluster is created, yo
|
||||
1. Select **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, click **Create**.
|
||||
1. Choose a cluster type.
|
||||
1. In the **Cluster Configuration** go to the **Registries** tab and select **Pull images for Rancher from a private registry**.
|
||||
1. Enter the registry hostname and credentials.
|
||||
1. In the **Cluster Configuration** go to the **Registries** tab.
|
||||
1. Check the box next to **Enable cluster scoped container registry for Rancher system container images**.
|
||||
1. Enter the registry hostname.
|
||||
1. Under **Authentication** select **Create a HTTP Basic Auth Secret** and fill in the credential fields.
|
||||
1. Click **Create**.
|
||||
|
||||
**Result:** The new cluster pulls images from the private registry.
|
||||
|
||||
### Working with Private Registry Credentials
|
||||
|
||||
When working with private registries, it is important to ensure that any secrets created for these registries are properly backed up. When you add a private registry credential secret through the Rancher GUI and select **Create a HTTP Basic Auth Secret**, the secret is included in backup operations using Rancher Backups.
|
||||
|
||||
However, if you create a credential secret outside of the Rancher GUI, such as by using kubectl or Terraform, you must add the `fleet.cattle.io/managed=true` label to indicate that the secret should be included in backups created by Rancher Backups.
|
||||
|
||||
For example, if you have a custom private registry named "my-private-registry" and create a secret called "my-reg-creds" for it, apply the `fleet.cattle.io/managed=true` label to this secret. This ensures that your backup process captures the secret, providing easy restoration if needed.
|
||||
|
||||
By following this guidance, you can ensure that all of your private registry credentials are backed up and easily accessible in the event of a restore or migration.
|
||||
|
||||
+2
-2
@@ -19,7 +19,7 @@ These nodes must be in the same region. You may place these servers in separate
|
||||
To install the Rancher management server on a high-availability RKE2 cluster, we recommend setting up the following infrastructure:
|
||||
|
||||
- **Three Linux nodes,** typically virtual machines, in the infrastructure provider of your choice.
|
||||
- **A load balancer** to direct traffic to the two nodes.
|
||||
- **A load balancer** to direct traffic to the nodes.
|
||||
- **A DNS record** to map a URL to the load balancer. This will become the Rancher server URL, and downstream Kubernetes clusters will need to reach it.
|
||||
|
||||
### 1. Set up Linux Nodes
|
||||
@@ -59,4 +59,4 @@ Depending on your environment, this may be an A record pointing to the load bala
|
||||
|
||||
You will need to specify this hostname in a later step when you install Rancher, and it is not possible to change it later. Make sure that your decision is a final one.
|
||||
|
||||
For a how-to guide for setting up a DNS record to route domain traffic to an Amazon ELB load balancer, refer to the [official AWS documentation.](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer)
|
||||
For a how-to guide for setting up a DNS record to route domain traffic to an Amazon ELB load balancer, refer to the [official AWS documentation.](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer)
|
||||
|
||||
+1
@@ -19,6 +19,7 @@ In order to deploy and run the adapter successfully, you need to ensure its vers
|
||||
|
||||
| Rancher Version | Adapter Version |
|
||||
|-----------------|:----------------:|
|
||||
| v2.8.7 | v103.0.1+up3.0.1 |
|
||||
| v2.8.6 | v103.0.1+up3.0.1 |
|
||||
| v2.8.5 | v103.0.1+up3.0.1 |
|
||||
| v2.8.4 | v103.0.1+up3.0.1 |
|
||||
|
||||
+6
@@ -90,6 +90,12 @@ We recommend exporting the kubeconfig file so that if Rancher goes down, you can
|
||||
|
||||
## Impersonation
|
||||
|
||||
:::caution Known Issue
|
||||
|
||||
Service account impersonation (`--as`) used by lower privileged user accounts to remove privileges is not implemented and is a [feature](https://github.com/rancher/rancher/issues/41988) being tracked.
|
||||
|
||||
:::
|
||||
|
||||
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).
|
||||
|
||||
@@ -20,6 +20,7 @@ Each Rancher version is designed to be compatible with a single version of the w
|
||||
|
||||
| Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
|
||||
|-----------------|-----------------|-----------------------|---------------------------|
|
||||
| v2.8.7 | v0.4.10 | ✓ | ✗ |
|
||||
| v2.8.6 | v0.4.9 | ✓ | ✗ |
|
||||
| v2.8.5 | v0.4.7 | ✓ | ✓ |
|
||||
| v2.8.4 | v0.4.5 | ✓ | ✓ |
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
---
|
||||
title: API Reference
|
||||
hide_table_of_contents: true
|
||||
---
|
||||
|
||||
<head>
|
||||
|
||||
@@ -16,7 +16,8 @@ Rancher will publish deprecated features as part of the [release notes](https://
|
||||
|
||||
| Patch Version | Release Date |
|
||||
|---------------|---------------|
|
||||
| [2.9.0](https://github.com/rancher/rancher/releases/tag/v2.9.0) | July 31, 2024 |
|
||||
| [2.9.1](https://github.com/rancher/rancher/releases/tag/v2.9.1) | Aug 26, 2024 |
|
||||
| [2.9.0](https://github.com/rancher/rancher/releases/tag/v2.9.0) | Jul 31, 2024 |
|
||||
|
||||
### What can I expect when a feature is marked for deprecation?
|
||||
|
||||
|
||||
+2
-2
@@ -148,7 +148,7 @@ To see options on how to customize the cert-manager install (including for cases
|
||||
:::
|
||||
|
||||
```
|
||||
# If you have installed the CRDs manually instead of with the `--set installCRDs=true` option added to your Helm install command, you should upgrade your CRD resources before upgrading the Helm chart:
|
||||
# If you have installed the CRDs manually, instead of setting `installCRDs` or `crds.enabled` to `true` in your Helm install command, you should upgrade your CRD resources before upgrading the Helm chart:
|
||||
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/<VERSION>/cert-manager.crds.yaml
|
||||
|
||||
# Add the Jetstack Helm repository
|
||||
@@ -161,7 +161,7 @@ helm repo update
|
||||
helm install cert-manager jetstack/cert-manager \
|
||||
--namespace cert-manager \
|
||||
--create-namespace \
|
||||
--set installCRDs=true
|
||||
--set crds.enabled=true
|
||||
```
|
||||
|
||||
Once you’ve installed cert-manager, you can verify it is deployed correctly by checking the cert-manager namespace for running pods:
|
||||
|
||||
+1
-1
@@ -46,6 +46,6 @@ A: You can use a runtime like containerd with Kubernetes that does not require D
|
||||
|
||||
Q: If I am already using RKE1 and want to switch to RKE2, what are my migration options?
|
||||
|
||||
A: Today, you can stand up a new cluster and migrate workloads to a new RKE2 cluster that uses containerd. Rancher is exploring the possibility of an in-place upgrade path.
|
||||
A: Today, you can stand up a new cluster and migrate workloads to a new RKE2 cluster that uses containerd. For details, see the [RKE to RKE2 Replatforming Guide](https://links.imagerelay.com/cdn/3404/ql/5606a3da2365422ab2250d348aa07112/rke_to_rke2_replatforming_guide.pdf).
|
||||
|
||||
<br/>
|
||||
|
||||
+2
-2
@@ -27,7 +27,7 @@ First configure the HTTP proxy settings on the K3s systemd service, so that K3s'
|
||||
```
|
||||
cat <<'EOF' | sudo tee /etc/default/k3s > /dev/null
|
||||
HTTP_PROXY=http://${proxy_host}
|
||||
HTTPS_PROXY=http://${proxy_host}"
|
||||
HTTPS_PROXY=http://${proxy_host}
|
||||
NO_PROXY=127.0.0.0/8,10.0.0.0/8,cattle-system.svc,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local
|
||||
EOF
|
||||
```
|
||||
@@ -71,7 +71,7 @@ Then you have to configure the HTTP proxy settings on the RKE2 systemd service,
|
||||
```
|
||||
cat <<'EOF' | sudo tee /etc/default/rke2-server > /dev/null
|
||||
HTTP_PROXY=http://${proxy_host}
|
||||
HTTPS_PROXY=http://${proxy_host}"
|
||||
HTTPS_PROXY=http://${proxy_host}
|
||||
NO_PROXY=127.0.0.0/8,10.0.0.0/8,cattle-system.svc,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local
|
||||
EOF
|
||||
```
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: Glossary
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/glossary"/>
|
||||
</head>
|
||||
|
||||
This page covers Rancher-specific terminology and symbols which might be unfamiliar, or which differ between Rancher versions.
|
||||
|
||||
```mdx-code-block
|
||||
import Glossary, {toc as GlossaryTOC} from "/shared-files/_glossary.md"
|
||||
|
||||
<Glossary />
|
||||
|
||||
export const toc = GlossaryTOC;
|
||||
```
|
||||
+14
-17
@@ -39,23 +39,20 @@ However, you'll need to do some additional steps if you're trying to set a names
|
||||
|
||||
1. Select **☰ > Cluster Management**.
|
||||
1. Find the RKE2 cluster in the list and click **⋮ >Edit Config**.
|
||||
1. From the **Cluster config** menu, select **Registries**.
|
||||
1. In the **Registries** pane, select the **Configure advanced containerd mirroring and registry authentication options** option.
|
||||
1. In the text fields under **Mirrors**, enter the **Registry Hostname** and **Mirror Endpoints**.
|
||||
1. Click **Save**.
|
||||
1. Repeat as necessary for each downstream RKE2 cluster.
|
||||
|
||||
## Configure a Private Registry with Credentials when Creating a Cluster
|
||||
|
||||
There is no global way to set up a private registry with authorization for every Rancher-provisioned cluster. Therefore, if you want a Rancher-provisioned cluster to pull images from a private registry that requires credentials, you'll have to pass the registry credentials through the advanced cluster options every time you create a new cluster.
|
||||
|
||||
Since the private registry cannot be configured after the cluster is created, you'll need to perform these steps during initial cluster setup.
|
||||
|
||||
1. Select **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, click **Create**.
|
||||
1. Choose a cluster type.
|
||||
1. In the **Cluster Configuration** go to the **Registries** tab and select **Pull images for Rancher from a private registry**.
|
||||
1. Enter the registry hostname and credentials.
|
||||
1. In the **Cluster Configuration** go to the **Registries** tab.
|
||||
1. Check the box next to **Enable cluster scoped container registry for Rancher system container images**.
|
||||
1. Enter the registry hostname.
|
||||
1. Under **Authentication** select **Create a HTTP Basic Auth Secret** and fill in the credential fields.
|
||||
1. Click **Create**.
|
||||
|
||||
**Result:** The new cluster pulls images from the private registry.
|
||||
|
||||
### Working with Private Registry Credentials
|
||||
|
||||
When working with private registries, it is important to ensure that any secrets created for these registries are properly backed up. When you add a private registry credential secret through the Rancher GUI and select **Create a HTTP Basic Auth Secret**, the secret is included in backup operations using Rancher Backups.
|
||||
|
||||
However, if you create a credential secret outside of the Rancher GUI, such as by using kubectl or Terraform, you must add the `fleet.cattle.io/managed=true` label to indicate that the secret should be included in backups created by Rancher Backups.
|
||||
|
||||
For example, if you have a custom private registry named "my-private-registry" and create a secret called "my-reg-creds" for it, apply the `fleet.cattle.io/managed=true` label to this secret. This ensures that your backup process captures the secret, providing easy restoration if needed.
|
||||
|
||||
By following this guidance, you can ensure that all of your private registry credentials are backed up and easily accessible in the event of a restore or migration.
|
||||
|
||||
+2
-2
@@ -19,7 +19,7 @@ These nodes must be in the same region. You may place these servers in separate
|
||||
To install the Rancher management server on a high-availability RKE2 cluster, we recommend setting up the following infrastructure:
|
||||
|
||||
- **Three Linux nodes,** typically virtual machines, in the infrastructure provider of your choice.
|
||||
- **A load balancer** to direct traffic to the two nodes.
|
||||
- **A load balancer** to direct traffic to the nodes.
|
||||
- **A DNS record** to map a URL to the load balancer. This will become the Rancher server URL, and downstream Kubernetes clusters will need to reach it.
|
||||
|
||||
### 1. Set up Linux Nodes
|
||||
@@ -59,4 +59,4 @@ Depending on your environment, this may be an A record pointing to the load bala
|
||||
|
||||
You will need to specify this hostname in a later step when you install Rancher, and it is not possible to change it later. Make sure that your decision is a final one.
|
||||
|
||||
For a how-to guide for setting up a DNS record to route domain traffic to an Amazon ELB load balancer, refer to the [official AWS documentation.](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer)
|
||||
For a how-to guide for setting up a DNS record to route domain traffic to an Amazon ELB load balancer, refer to the [official AWS documentation.](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer)
|
||||
|
||||
+2
-1
@@ -19,7 +19,8 @@ In order to deploy and run the adapter successfully, you need to ensure its vers
|
||||
|
||||
| Rancher Version | Adapter Version |
|
||||
|-----------------|:----------------:|
|
||||
| v2.9.0 | v104.0.0+up4.0.0 |
|
||||
| v2.9.1 | v104.0.0+up4.0.0 |
|
||||
| v2.9.0 | v104.0.0+up4.0.0 |
|
||||
|
||||
### 1. Gain Access to the Local Cluster
|
||||
|
||||
|
||||
+6
@@ -89,6 +89,12 @@ We recommend exporting the kubeconfig file so that if Rancher goes down, you can
|
||||
|
||||
## Impersonation
|
||||
|
||||
:::caution Known Issue
|
||||
|
||||
Service account impersonation (`--as`) used by lower privileged user accounts to remove privileges is not implemented and is a [feature](https://github.com/rancher/rancher/issues/41988) being tracked.
|
||||
|
||||
:::
|
||||
|
||||
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).
|
||||
|
||||
@@ -20,6 +20,7 @@ Each Rancher version is designed to be compatible with a single version of the w
|
||||
|
||||
| Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
|
||||
|-----------------|-----------------|-----------------------|---------------------------|
|
||||
| v2.9.1 | v0.5.1 | ✓ | ✓ |
|
||||
| v2.9.0 | v0.5.0 | ✗ | ✓ |
|
||||
|
||||
## Why Do We Need It?
|
||||
|
||||
@@ -1315,6 +1315,7 @@
|
||||
}
|
||||
]
|
||||
},
|
||||
"contribute-to-rancher"
|
||||
"contribute-to-rancher",
|
||||
"glossary"
|
||||
]
|
||||
}
|
||||
|
||||
@@ -1249,6 +1249,7 @@
|
||||
}
|
||||
]
|
||||
},
|
||||
"contribute-to-rancher"
|
||||
"contribute-to-rancher",
|
||||
"glossary"
|
||||
]
|
||||
}
|
||||
|
||||
@@ -1238,6 +1238,7 @@
|
||||
}
|
||||
]
|
||||
},
|
||||
"contribute-to-rancher"
|
||||
"contribute-to-rancher",
|
||||
"glossary"
|
||||
]
|
||||
}
|
||||
|
||||
@@ -1311,6 +1311,7 @@
|
||||
}
|
||||
]
|
||||
},
|
||||
"contribute-to-rancher"
|
||||
"contribute-to-rancher",
|
||||
"glossary"
|
||||
]
|
||||
}
|
||||
|
||||
@@ -1318,6 +1318,7 @@
|
||||
"api/v3-rancher-api-guide"
|
||||
]
|
||||
},
|
||||
"contribute-to-rancher"
|
||||
"contribute-to-rancher",
|
||||
"glossary"
|
||||
]
|
||||
}
|
||||
|
||||
@@ -1322,6 +1322,7 @@
|
||||
"api/v3-rancher-api-guide"
|
||||
]
|
||||
},
|
||||
"contribute-to-rancher"
|
||||
"contribute-to-rancher",
|
||||
"glossary"
|
||||
]
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user