mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-29 14:38:50 +00:00
Compare commits
140
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
e154a1b781 | ||
|
|
df9bd80404 | ||
|
|
cb230aa06d | ||
|
|
77c45a161a | ||
|
|
3aced93c29 | ||
|
|
8062af1828 | ||
|
|
6b4730f9b5 | ||
|
|
daf32e255f | ||
|
|
67c2b385cc | ||
|
|
7cc5f27bc5 | ||
|
|
2026d15d3a | ||
|
|
2287ae56ae | ||
|
|
e5a5bdba31 | ||
|
|
b5badc2ab5 | ||
|
|
6135f491af | ||
|
|
2efc8cf6e1 | ||
|
|
e5176e033b | ||
|
|
4dd65ee2a2 | ||
|
|
f2201cd170 | ||
|
|
f31109dce1 | ||
|
|
f95bf2749b | ||
|
|
7a6a765696 | ||
|
|
db7fbb65ff | ||
|
|
c6dc249821 | ||
|
|
645a4ca96d | ||
|
|
a192d4c204 | ||
|
|
c0bb462495 | ||
|
|
b0d5bf7f17 | ||
|
|
ff9e2a1102 | ||
|
|
b9a23c4350 | ||
|
|
9fd94c4750 | ||
|
|
2a02e2bc0c | ||
|
|
278e55bc61 | ||
|
|
d935632f57 | ||
|
|
d23d6f0cb7 | ||
|
|
61f5a02048 | ||
|
|
ca3001912d | ||
|
|
e363836980 | ||
|
|
db108776a3 | ||
|
|
34c873ece2 | ||
|
|
56d09d63f1 | ||
|
|
6abbf96143 | ||
|
|
80dd010452 | ||
|
|
83aa9da938 | ||
|
|
b34027c28a | ||
|
|
17486fb91f | ||
|
|
bdd6116c6b | ||
|
|
92216252ef | ||
|
|
4878cf5a9c | ||
|
|
124b0d1823 | ||
|
|
d853433d1d | ||
|
|
29ae56f5b7 | ||
|
|
1d696bac8e | ||
|
|
0272c007cb | ||
|
|
ccfe370188 | ||
|
|
b641c16125 | ||
|
|
44b2c26f4f | ||
|
|
b9602b9af2 | ||
|
|
6b44b6f9c5 | ||
|
|
08282ef9a4 | ||
|
|
ca818e70af | ||
|
|
eeddf866f7 | ||
|
|
f0ae84ea56 | ||
|
|
690a8ceab6 | ||
|
|
21de5f1f58 | ||
|
|
2ce9276086 | ||
|
|
50ccf01498 | ||
|
|
595dd80222 | ||
|
|
07b47e82d8 | ||
|
|
d12531819a | ||
|
|
38204c2ae5 | ||
|
|
8e10fcd952 | ||
|
|
91d9e2b81d | ||
|
|
57d019e486 | ||
|
|
48c191e1b6 | ||
|
|
7838a690ed | ||
|
|
5f0c5857f8 | ||
|
|
0ab15d2315 | ||
|
|
834cd145ab | ||
|
|
f21edef534 | ||
|
|
8bf8fef3ba | ||
|
|
0b1a9b0d35 | ||
|
|
61aa8da9ec | ||
|
|
a0b9b9cc95 | ||
|
|
72f6a4835c | ||
|
|
6d0ac485c7 | ||
|
|
b993ccbe46 | ||
|
|
412270ab5b | ||
|
|
b2891f2d6f | ||
|
|
e964777689 | ||
|
|
ba2657cf70 | ||
|
|
d9e530323c | ||
|
|
6f4e731d29 | ||
|
|
8c34fe3b8d | ||
|
|
a387de4bfa | ||
|
|
6eed0e9140 | ||
|
|
407e7a674a | ||
|
|
c7d0bc872f | ||
|
|
f63efb5f6f | ||
|
|
862c65400a | ||
|
|
81dc8e87b6 | ||
|
|
1e6107d8b7 | ||
|
|
08fa1d32db | ||
|
|
3b9a7be360 | ||
|
|
8a0c297a24 | ||
|
|
6e6318cfa3 | ||
|
|
d3463104ea | ||
|
|
14e81eb634 | ||
|
|
575183982b | ||
|
|
1584fa9cfc | ||
|
|
3b847a904f | ||
|
|
b9edf0d6ff | ||
|
|
8aa0eeab27 | ||
|
|
6d0622b975 | ||
|
|
63776904db | ||
|
|
007e5c07a7 | ||
|
|
766d605335 | ||
|
|
4174a58070 | ||
|
|
da8d7eb95a | ||
|
|
ddaef63077 | ||
|
|
a6bb9108e3 | ||
|
|
6a47218c15 | ||
|
|
40dbb58d5a | ||
|
|
b7725314c2 | ||
|
|
e9ccd164b1 | ||
|
|
ed2973599c | ||
|
|
a6ff6695ea | ||
|
|
d3f4a7dd0c | ||
|
|
3362b6aa60 | ||
|
|
acd235ea23 | ||
|
|
770c5bfed2 | ||
|
|
dbd4dfa688 | ||
|
|
e12d7b2f11 | ||
|
|
9c3755a73a | ||
|
|
4ccbbdf8b6 | ||
|
|
954b9fe73e | ||
|
|
f8ce43ffa6 | ||
|
|
fbf440f0fd | ||
|
|
0d14c4af90 | ||
|
|
a7195c38b4 |
Submodule .github/styles/suse-vale-styleguide updated: fba9687e7d...064650076d
+1
-1
@@ -1 +1 @@
|
||||
* @btat @LucasSaintarbor @martyav @sunilarjun
|
||||
* @btat @LucasSaintarbor @sunilarjun
|
||||
-2
@@ -23,7 +23,5 @@ For information on how Rancher works, regardless of the installation method, ref
|
||||
- The Ingress controller will redirect HTTP to HTTPS and terminate SSL/TLS on port TCP/443.
|
||||
- The Ingress controller will forward traffic to port TCP/80 on the pod in the Rancher deployment.
|
||||
|
||||
<figcaption>Kubernetes Rancher install with layer 4 load balancer, depicting SSL termination at ingress controllers</figcaption>
|
||||
|
||||

|
||||
<sup>Kubernetes Rancher install with Layer 4 load balancer (TCP), depicting SSL termination at ingress controllers</sup>
|
||||
|
||||
@@ -30,7 +30,6 @@ The following is a complete list of tokens generated with `ttl=0`:
|
||||
| `agent-*` | Token for agent deployment |
|
||||
| `compose-token-*` | Token for compose |
|
||||
| `helm-token-*` | Token for Helm chart deployment |
|
||||
| `telemetry-*` | Telemetry token |
|
||||
| `drain-node-*` | Token for drain (Rancher uses `kubectl` for drain because there is no native Kubernetes API). |
|
||||
|
||||
## Setting TTL on Kubeconfig Tokens
|
||||
|
||||
@@ -49,6 +49,10 @@ EOF
|
||||
|
||||
Setting the `field.cattle.io/creatorId` field allows the cluster member account to see project resources with the `get` command and view the project in the Rancher UI. Cluster owner and admin accounts don't need to set this annotation to perform these tasks.
|
||||
|
||||
Setting the `field.cattle.io/creator-principal-name` annotation to the user's principal preserves it in a projectroletemplatebinding automatically created for the project owner.
|
||||
|
||||
If you don't want the creator to be added as the owner member (e.g. if the creator is a cluster administrator) to the project you may set the `field.cattle.io/no-creator-rbac` annotation to `true`, which will prevent the corresponding projectroletemplatebinding from being created.
|
||||
|
||||
### Creating a Project With a Resource Quota
|
||||
|
||||
Refer to [Kubernetes Resource Quota](https://kubernetes.io/docs/concepts/policy/resource-quotas/).
|
||||
@@ -91,6 +95,77 @@ spec:
|
||||
limitsMemory: 100Mi
|
||||
requestsCpu: 50m
|
||||
requestsMemory: 50Mi
|
||||
EOF
|
||||
```
|
||||
|
||||
## Adding a Member to a Project
|
||||
|
||||
Look up the project ID to specify the `metadata.namespace` field and `projectName` field values.
|
||||
|
||||
```bash
|
||||
kubectl --namespace c-m-abcde get projects
|
||||
```
|
||||
|
||||
Look up the role template ID to specify the `roleTemplateName` field value (e.g. `project-member` or `project-owner`).
|
||||
|
||||
```bash
|
||||
kubectl get roletemplates
|
||||
```
|
||||
|
||||
When adding a user member specify the `userPrincipalName` field:
|
||||
|
||||
```bash
|
||||
kubectl create -f - <<EOF
|
||||
apiVersion: management.cattle.io/v3
|
||||
kind: ProjectRoleTemplateBinding
|
||||
metadata:
|
||||
generateName: prtb-
|
||||
namespace: p-vwxyz
|
||||
projectName: c-m-abcde:p-vwxyz
|
||||
roleTemplateName: project-member
|
||||
userPrincipalName: keycloak_user://user
|
||||
EOF
|
||||
```
|
||||
|
||||
When adding a group member specify the `groupPrincipalName` field instead:
|
||||
|
||||
```bash
|
||||
kubectl create -f - <<EOF
|
||||
apiVersion: management.cattle.io/v3
|
||||
kind: ProjectRoleTemplateBinding
|
||||
metadata:
|
||||
generateName: prtb-
|
||||
namespace: p-vwxyz
|
||||
projectName: c-m-abcde:p-vwxyz
|
||||
roleTemplateName: project-member
|
||||
groupPrincipalName: keycloak_group://group
|
||||
EOF
|
||||
```
|
||||
|
||||
Create a projectroletemplatebinding for each role you want to assign to the project member.
|
||||
|
||||
## Listing Project Members
|
||||
|
||||
Look up the project ID:
|
||||
|
||||
```bash
|
||||
kubectl --namespace c-m-abcde get projects
|
||||
```
|
||||
|
||||
to list projectroletemplatebindings in the project's namespace:
|
||||
|
||||
```bash
|
||||
kubectl --namespace p-vwxyz get projectroletemplatebindings
|
||||
```
|
||||
|
||||
## Deleting a Member From a Project
|
||||
|
||||
Lookup the projectroletemplatebinding IDs containing the member in the project's namespace as decribed in the [Listing Project Members](#listing-project-members) section.
|
||||
|
||||
Delete the projectroletemplatebinding from the project's namespace:
|
||||
|
||||
```bash
|
||||
kubectl --namespace p-vwxyz delete projectroletemplatebindings prtb-qx874 prtb-7zw7s
|
||||
```
|
||||
|
||||
## Creating a Namespace in a Project
|
||||
@@ -132,4 +207,4 @@ Delete the project under the cluster namespace:
|
||||
kubectl --namespace c-m-abcde delete project p-vwxyz
|
||||
```
|
||||
|
||||
Note that this command doesn't delete the namespaces and resources that formerly belonged to the project.
|
||||
Note that this command doesn't delete the namespaces and resources that formerly belonged to the project.
|
||||
|
||||
@@ -42,7 +42,6 @@ kontainer-engine | https://github.com/rancher/kontainer-engine | This repository
|
||||
RKE repository | https://github.com/rancher/rke | This repository is the source of Rancher Kubernetes Engine, the tool to provision Kubernetes clusters on any machine.
|
||||
CLI | https://github.com/rancher/cli | This repository is the source code for the Rancher CLI used in Rancher 2.x.
|
||||
(Rancher) Helm repository | https://github.com/rancher/helm | This repository is the source of the packaged Helm binary. This is a fork of the `helm/helm` repository.
|
||||
Telemetry repository | https://github.com/rancher/telemetry | This repository is the source for the Telemetry binary.
|
||||
loglevel repository | https://github.com/rancher/loglevel | This repository is the source of the loglevel binary, used to dynamically change log levels.
|
||||
|
||||
To see all libraries/projects used in Rancher, see the [`go.mod` file](https://github.com/rancher/rancher/blob/master/go.mod) in the `rancher/rancher` repository.
|
||||
|
||||
@@ -16,10 +16,9 @@ Rancher will publish deprecated features as part of the [release notes](https://
|
||||
|
||||
| Patch Version | Release Date |
|
||||
|---------------|---------------|
|
||||
| [2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) | Oct 24, 2024 |
|
||||
| [2.9.2](https://github.com/rancher/rancher/releases/tag/v2.9.2) | Sep 19, 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 |
|
||||
| [2.10.2](https://github.com/rancher/rancher/releases/tag/v2.10.2) | Jan 29, 2025 |
|
||||
| [2.10.1](https://github.com/rancher/rancher/releases/tag/v2.10.1) | Dec 19, 2024 |
|
||||
| [2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) | Nov 18, 2024 |
|
||||
|
||||
## What can I expect when a feature is marked for deprecation?
|
||||
|
||||
|
||||
@@ -91,11 +91,11 @@ The UI consists of static files, and works based on responses of the API. That m
|
||||
|
||||
## The IP address of a node changed, how can I recover?
|
||||
|
||||
A node is required to have a static IP configured (or a reserved IP via DHCP). If the IP of a node has changed, you will have to remove it from the cluster and readd it. After it is removed, Rancher will update the cluster to the correct state. If the cluster is no longer in `Provisioning` state, the node is removed from the cluster.
|
||||
A node is required to have a static IP configured (or a reserved IP via DHCP). If the IP of a node has changed, you will have to remove it from the cluster and add it again. After it is removed, Rancher will update the cluster to the correct state. If the cluster is no longer in `Provisioning` state, the node is removed from the cluster.
|
||||
|
||||
When the IP address of the node changed, Rancher lost connection to the node, so it will be unable to clean the node properly. See [Cleaning cluster nodes](../how-to-guides/new-user-guides/manage-clusters/clean-cluster-nodes.md) to clean the node.
|
||||
|
||||
When the node is removed from the cluster, and the node is cleaned, you can readd the node to the cluster.
|
||||
When the node is removed from the cluster, and the node is cleaned, you can add the node to the cluster.
|
||||
|
||||
## How can I add more arguments/binds/environment variables to Kubernetes components in a Rancher Launched Kubernetes cluster?
|
||||
|
||||
|
||||
@@ -1,35 +0,0 @@
|
||||
---
|
||||
title: Telemetry FAQ
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/telemetry"/>
|
||||
</head>
|
||||
|
||||
## What is Telemetry?
|
||||
|
||||
Telemetry collects aggregate information about the size of Rancher installations, versions of components used, and which features are used. This information is used by Rancher Labs to help make the product better and is not shared with third-parties.
|
||||
|
||||
## What information is collected?
|
||||
|
||||
No specific identifying information like usernames, passwords, or the names or addresses of user resources will ever be collected.
|
||||
|
||||
The primary things collected include:
|
||||
|
||||
- Aggregate counts (smallest, average, largest, total) of nodes per-cluster and their size (e.g. CPU cores & RAM).
|
||||
- Aggregate counts of logical resources like Clusters, Projects, Namespaces, and Pods.
|
||||
- Counts of what driver was used to deploy clusters and nodes (e.g. GKE vs EC2 vs Imported vs Custom).
|
||||
- Versions of Kubernetes components, Operating Systems and Docker that are deployed on nodes.
|
||||
- Whether some optional components are enabled or not (e.g. which auth providers are used).
|
||||
- The image name & version of Rancher that is running.
|
||||
- A unique randomly-generated identifier for this installation.
|
||||
|
||||
## Can I see the information that is being sent?
|
||||
|
||||
If Telemetry is enabled, you can go to `https://<your rancher server>/v1-telemetry` in your installation to see the current data.
|
||||
|
||||
If Telemetry is not enabled, the process that collects the data is not running, so there is nothing being collected to look at.
|
||||
|
||||
## How do I turn it on or off?
|
||||
|
||||
After initial setup, an administrator can go to the `Settings` page in the `Global` section of the UI and click Edit to change the `telemetry-opt` setting to either `in` or `out`.
|
||||
+6
-2
@@ -18,11 +18,13 @@ Some feature flags require a restart of the Rancher container. Features that req
|
||||
|
||||
The following is a list of feature flags available in Rancher. If you've upgraded from a previous Rancher version, you may see additional flags in the Rancher UI, such as `proxy` or `dashboard` (both [discontinued](/versioned_docs/version-2.5/reference-guides/installation-references/feature-flags.md)):
|
||||
|
||||
- `clean-stale-secrets`: Removes stale secrets from the `cattle-impersonation-system` namespace. This slowly cleans up old secrets which are no longer being used by the impersonation system.
|
||||
- `continuous-delivery`: Allows Fleet GitOps to be disabled separately from Fleet. See [Continuous Delivery.](../../../how-to-guides/advanced-user-guides/enable-experimental-features/continuous-delivery.md) for more information.
|
||||
- `fleet`: The Rancher provisioning framework in v2.6 and later requires Fleet. The flag will be automatically enabled when you upgrade, even if you disabled this flag in an earlier version of Rancher. See [Continuous Delivery with Fleet](../../../integrations-in-rancher/fleet/fleet.md) for more information.
|
||||
- `harvester`: Manages access to the Virtualization Management page, where users can navigate directly to Harvester clusters and access the Harvester UI. See [Harvester Integration Overview](../../../integrations-in-rancher/harvester/overview.md) for more information.
|
||||
- `istio-virtual-service-ui`: Enables a [visual interface](../../../how-to-guides/advanced-user-guides/enable-experimental-features/istio-traffic-management-features.md) to create, read, update, and delete Istio virtual services and destination rules, which are Istio traffic management features.
|
||||
- `legacy`: Enables a set of features from 2.5.x and earlier, that are slowly being phased out in favor of newer implementations. These are a mix of deprecated features as well as features that will eventually be available to newer versions. This flag is disabled by default on new Rancher installations. If you're upgrading from a previous version of Rancher, this flag is enabled.
|
||||
- `managed-system-upgrade-controller`: Enables the installation of the system-upgrade-controller app in downstream RKE2/K3s clusters, currently limited to imported clusters and the local cluster, with plans to expand support to node-driver clusters.
|
||||
- `multi-cluster-management`: Allows multi-cluster provisioning and management of Kubernetes clusters. This flag can only be set at install time. It can't be enabled or disabled later.
|
||||
- `rke1-custom-node-cleanup`: Enables cleanup of deleted RKE1 custom nodes. We recommend that you keep this flag enabled, to prevent removed nodes from attempting to rejoin the cluster.
|
||||
- `rke2`: Enables provisioning RKE2 clusters. This flag is enabled by default.
|
||||
@@ -36,14 +38,16 @@ The following table shows the availability and default values for some feature f
|
||||
|
||||
| Feature Flag Name | Default Value | Status | Available As Of | Additional Information |
|
||||
| ----------------------------- | ------------- | ------------ | --------------- | ---------------------- |
|
||||
| `clean-stale-secrets` | `true` | GA | v2.10.2 | |
|
||||
| `continuous-delivery` | `true` | GA | v2.6.0 | |
|
||||
| `external-rules` | v2.7.14: `false`, v2.8.5: `true` | Removed | v2.7.14, v2.8.5 | This flag affected [external `RoleTemplate` behavior](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#external-roletemplate-behavior). It is removed in Rancher v2.9.0 and later as the behavior is enabled by default. |
|
||||
| `fleet` | `true` | Can no longer be disabled | v2.6.0 | |
|
||||
| `fleet` | `true` | GA | v2.5.0 | |
|
||||
| `harvester` | `true` | Experimental | v2.6.1 | |
|
||||
| `legacy` | `false` for new installs, `true` for upgrades | GA | v2.6.0 | |
|
||||
| `managed-system-upgrade-controller` | `true` | GA | v2.10.0 | |
|
||||
| `rke1-custom-node-cleanup`| `true` | GA | v2.6.0 | |
|
||||
| `rke2` | `true` | Experimental | v2.6.0 | |
|
||||
| `token-hashing` | `false` for new installs, `true` for upgrades | GA | v2.6.0 | |
|
||||
| `uiextension` | `true` | GA | v2.9.0 |
|
||||
| `ui-sql-cache` | `false` | Highly experimental | v2.9.0 |
|
||||
| `uiextension` | `true` | GA | v2.9.0 | |
|
||||
| `ui-sql-cache` | `false` | Highly experimental | v2.9.0 | |
|
||||
|
||||
-7
@@ -142,10 +142,3 @@ docker run -d --restart=unless-stopped \
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
:::note
|
||||
|
||||
If you don't intend to send telemetry data, opt out [telemetry](../../../../faq/telemetry.md) during the initial login.
|
||||
|
||||
:::
|
||||
|
||||
|
||||
-6
@@ -234,13 +234,7 @@ If you are using a Private CA signed cert, add `--set privateCA=true` following
|
||||
--set useBundledSystemChart=true # Use the packaged Rancher system charts
|
||||
```
|
||||
|
||||
|
||||
The installation is complete.
|
||||
:::caution
|
||||
|
||||
If you don't intend to send telemetry data, opt out [telemetry](../../../../faq/telemetry.md) during the initial login. Leaving this active in an air-gapped environment can cause issues if the sockets cannot be opened successfully.
|
||||
|
||||
:::
|
||||
|
||||
## Additional Resources
|
||||
|
||||
|
||||
-6
@@ -95,12 +95,6 @@ kubectl rollout status deployment -n cattle-system rancher
|
||||
|
||||
You can now navigate to `https://rancher.example.com` and start using Rancher.
|
||||
|
||||
:::caution
|
||||
|
||||
If you don't intend to send telemetry data, opt out [telemetry](../../../../faq/telemetry.md) during the initial login. Leaving this active in an air-gapped environment can cause issues if the sockets cannot be opened successfully.
|
||||
|
||||
:::
|
||||
|
||||
### Additional Resources
|
||||
|
||||
These resources could be helpful when installing Rancher:
|
||||
|
||||
@@ -13,4 +13,11 @@ To view the generated CIS scan reports,
|
||||
1. Click **CIS Benchmark > Scan**.
|
||||
1. The **Scans** page will show the generated reports. To see a detailed report, go to a scan report and click the name.
|
||||
|
||||
One can download the report from the Scans list or from the scan detail page.
|
||||
One can download the report from the Scans list or from the scan detail page.
|
||||
|
||||
To get the verbose version of the CIS scan results, run the following command on the cluster that was scanned. Note that the scan must be completed before this can be done.
|
||||
|
||||
```console
|
||||
export REPORT="scan-report-name"
|
||||
kubectl get clusterscanreport $REPORT -o json |jq ".spec.reportJSON | fromjson" | jq -r ".actual_value_map_data" | base64 -d | gunzip | jq .
|
||||
```
|
||||
|
||||
+4
@@ -192,3 +192,7 @@ Try configuring and saving keycloak as your SAML provider and then accessing the
|
||||
|
||||
* Check your Keycloak log.
|
||||
* If the log displays `request validation failed: org.keycloak.common.VerificationException: SigAlg was null`, set `Client Signature Required` to `OFF` in your Keycloak client.
|
||||
|
||||
## Configuring SAML Single Logout (SLO)
|
||||
|
||||
<ConfigureSLO />
|
||||
|
||||
+5
-1
@@ -107,4 +107,8 @@ The OpenLDAP service account is used for all searches. Rancher users will see us
|
||||
1. Click **Okta** or, if SAML is already configured, **Edit Config**
|
||||
1. Under **User and Group Search**, check **Configure an OpenLDAP server**
|
||||
|
||||
If you experience issues when you test the connection to the OpenLDAP server, ensure that you entered the credentials for the service account and configured the search base correctly. Inspecting the Rancher logs can help pinpoint the root cause. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging](../../../../faq/technical-items.md#how-can-i-enable-debug-logging) for more information.
|
||||
If you experience issues when you test the connection to the OpenLDAP server, ensure that you entered the credentials for the service account and configured the search base correctly. Inspecting the Rancher logs can help pinpoint the root cause. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging](../../../../faq/technical-items.md#how-can-i-enable-debug-logging) for more information.
|
||||
|
||||
## Configuring SAML Single Logout (SLO)
|
||||
|
||||
<ConfigureSLO />
|
||||
|
||||
+4
@@ -64,3 +64,7 @@ Note that these URLs will not return valid data until the authentication configu
|
||||
- The group drop-down shows only the groups that you are a member of. You will not be able to add groups that you are not a member of.
|
||||
|
||||
:::
|
||||
|
||||
## Configuring SAML Single Logout (SLO)
|
||||
|
||||
<ConfigureSLO />
|
||||
|
||||
+4
@@ -51,3 +51,7 @@ You can generate a certificate using an openssl command. For example:
|
||||
```
|
||||
openssl req -x509 -newkey rsa:2048 -keyout myservice.key -out myservice.cert -days 365 -nodes -subj "/CN=myservice.example.com"
|
||||
```
|
||||
|
||||
## Configuring SAML Single Logout (SLO)
|
||||
|
||||
<ConfigureSLO />
|
||||
|
||||
+4
@@ -77,6 +77,10 @@ If you configure Shibboleth without OpenLDAP, the following caveats apply due to
|
||||
|
||||
To enable searching for groups when assigning permissions in Rancher, you will need to configure a back end for the SAML provider that supports groups, such as OpenLDAP.
|
||||
|
||||
### Configuring SAML Single Logout (SLO)
|
||||
|
||||
<ConfigureSLO />
|
||||
|
||||
## Setting up OpenLDAP in Rancher
|
||||
|
||||
If you also configure OpenLDAP as the back end to Shibboleth, it will return a SAML assertion to Rancher with user attributes that include groups. Then authenticated users will be able to access resources in Rancher that their groups have permissions for.
|
||||
|
||||
+1
-1
@@ -13,7 +13,7 @@ PSS define security levels for workloads. PSAs describe requirements for pod sec
|
||||
|
||||
## Upgrade to Pod Security Standards (PSS)
|
||||
|
||||
Ensure that you migrate all PSPs to another workload security mechanism. This includes mapping your current PSPs to Pod Security Standards for enforcement with the [PSA controller](https://kubernetes.io/docs/concepts/security/pod-security-admission/). If the PSA controller won't meet all of your organization's needs, we recommend that you use a policy engine, such as [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper), [Kubewarden](https://www.kubewarden.io/), [Kyverno](https://kyverno.io/), or [NeuVector](https://neuvector.com/). Refer to the documentation of your policy engine of choice for more information on how to migrate from PSPs.
|
||||
Ensure that you migrate all PSPs to another workload security mechanism. This includes mapping your current PSPs to Pod Security Standards for enforcement with the [PSA controller](https://kubernetes.io/docs/concepts/security/pod-security-admission/). If the PSA controller won't meet all of your organization's needs, we recommend that you use a policy engine, such as [Kubewarden](https://www.kubewarden.io/), [Kyverno](https://kyverno.io/), or [NeuVector](https://neuvector.com/). Refer to the documentation of your policy engine of choice for more information on how to migrate from PSPs.
|
||||
|
||||
:::caution
|
||||
You must add your new policy enforcement mechanisms _before_ you remove the PodSecurityPolicy objects. If you don't, you may create an opportunity for privilege escalation attacks within the cluster.
|
||||
|
||||
+38
-3
@@ -53,8 +53,7 @@ To display prerelease versions:
|
||||
| rancher-alerting-drivers | 100.0.0 | 100.0.2 |
|
||||
| rancher-backup | 2.0.1 | 2.1.2 |
|
||||
| rancher-cis-benchmark | 2.0.1 | 2.0.4 |
|
||||
| rancher-gatekeeper | 100.0.0+up3.6.0 | 100.1.0+up3.7.1 |
|
||||
| rancher-istio | 100.0.0+up1.10.4 | 100.3.0+up1.13.3 |
|
||||
| rancher-istio | 105.0.0+up1.19.6 | 105.4.0+up1.23.2 |
|
||||
| rancher-logging | 100.0.0+up3.12.0 | 100.1.2+up3.17.4 |
|
||||
| rancher-longhorn | 100.0.0+up1.1.2 | 100.1.2+up1.2.4 |
|
||||
| rancher-monitoring | 100.0.0+up16.6.0 | 100.1.2+up19.0.3 |
|
||||
@@ -194,6 +193,42 @@ Non-Airgap Rancher installations upon refresh will reflect any chart repository
|
||||
|
||||
Airgap installations where Rancher is configured to use the packaged copy of Helm system charts ([`useBundledSystemChart=true`](../../../getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha.md#helm-chart-options-for-air-gap-installations)) will only refer to the [system-chart](https://github.com/rancher/system-charts) repository that comes bundled and will not be able to be refreshed or synced.
|
||||
|
||||
#### Refresh Interval
|
||||
|
||||
Rancher v2.10.0 adds the `refreshInterval` field to the `ClusterRepo` CRD. The default value is 3600 seconds, meaning that Rancher syncs each Helm repository every 3600 seconds.
|
||||
|
||||
To modify the refresh interval of a chart repository:
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
|
||||
1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.
|
||||
1. Find the repository you want to modify, and click **⋮ > Edit YAML**.
|
||||
1. Set the **refreshInterval** field under **Spec** to the desired value in seconds.
|
||||
1. Click **Save**.
|
||||
|
||||
### Enable/Disable Helm Chart Repositories
|
||||
|
||||
Rancher v2.10.0 adds the ability to enable and disable Helm repositories. Helm repositories are enabled by default.
|
||||
|
||||
To disable a chart repository:
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
|
||||
1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.
|
||||
1. Find the repository you want to disable, and click **⋮ > Edit YAML**.
|
||||
1. Set the **Enabled** field under **Spec** to **false**.
|
||||
1. Click **Save**.
|
||||
1. When you disable a repository, updates are disabled and new changes to the clusterRepo are not applied.
|
||||
|
||||
To enable a chart repository:
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
|
||||
1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.
|
||||
1. Find the repository you want to disable, and click **⋮ > Edit YAML**.
|
||||
1. Set the **Enabled** field under **Spec** to **true**.
|
||||
1. Click **Save**.
|
||||
|
||||
## Deploy and Upgrade Charts
|
||||
|
||||
To install and deploy a chart:
|
||||
@@ -201,7 +236,7 @@ To install and deploy a chart:
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
|
||||
1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Charts**.
|
||||
1. Select a chart, and click **Install**.
|
||||
1. Select a chart, and click **Install**.
|
||||
|
||||
Rancher and Partner charts may have extra configurations available through custom pages or questions.yaml files. However, all chart installations can modify the values.yaml and other basic settings. After you click **Install**, a Helm operation job is deployed, and the console for the job is displayed.
|
||||
|
||||
|
||||
-2
@@ -23,7 +23,5 @@ For information on how Rancher works, regardless of the installation method, ref
|
||||
- The Ingress controller will redirect HTTP to HTTPS and terminate SSL/TLS on port TCP/443.
|
||||
- The Ingress controller will forward traffic to port TCP/80 on the pod in the Rancher deployment.
|
||||
|
||||
<figcaption>Kubernetes Rancher install with layer 4 load balancer, depicting SSL termination at ingress controllers</figcaption>
|
||||
|
||||

|
||||
<sup>Kubernetes Rancher install with Layer 4 load balancer (TCP), depicting SSL termination at ingress controllers</sup>
|
||||
|
||||
+19
@@ -35,6 +35,8 @@ Since, by default, Google Kubernetes Engine (GKE) doesn't grant the `cluster-adm
|
||||
|
||||
To successfully import or provision EKS, AKS, and GKE clusters from Rancher, the cluster must have at least one managed node group.
|
||||
|
||||
AKS clusters can only be imported if local accounts are enabled. If a cluster is configured to use Microsoft Entra ID for authentication, Rancher will not be able to import the cluster and report an error.
|
||||
|
||||
EKS Anywhere clusters can be imported/registered into Rancher with an API address and credentials, as with any downstream cluster. EKS Anywhere clusters are treated as imported clusters and do not have full lifecycle support from Rancher.
|
||||
|
||||
GKE Autopilot clusters aren't supported. See [Compare GKE Autopilot and Standard](https://cloud.google.com/kubernetes-engine/docs/resources/autopilot-standard-feature-comparison) for more information about the differences between GKE modes.
|
||||
@@ -286,3 +288,20 @@ To annotate a registered cluster,
|
||||
6. Click **Save**.
|
||||
|
||||
**Result:** The annotation does not give the capabilities to the cluster, but it does indicate to Rancher that the cluster has those capabilities.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
This section lists some of the most common errors that may occur when importing a cluster and provides steps to troubleshoot them.
|
||||
|
||||
### AKS
|
||||
|
||||
- The following error may occur if local accounts are disabled in your cluster.
|
||||
```sh
|
||||
Error: Getting static credential is not allowed because this cluster is set to disable local accounts.
|
||||
```
|
||||
|
||||
To resolve this issue, enable local accounts before attempting to [import the cluster](#registering-a-cluster) again.
|
||||
|
||||
```sh
|
||||
az aks update --resource-group <resource-group> --name <cluster-name> --enable-local-accounts
|
||||
```
|
||||
+137
-187
@@ -93,7 +93,7 @@ This [tutorial](https://aws.amazon.com/blogs/opensource/managing-eks-clusters-ra
|
||||
|
||||
## Minimum EKS Permissions
|
||||
|
||||
These are the minimum set of permissions necessary to access the full functionality of Rancher's EKS driver. You'll need additional permissions for Rancher to provision the `Service Role` and `VPC` resources. If you create these resources **before** you create the cluster, they'll be available when you configure the cluster.
|
||||
These are the minimum set of permissions necessary to access the full functionality of Rancher's EKS driver. These permissions allow Rancher to create the Service Role and Virtual Private Cloud (VPC) resources on the users' behalf, if necessary.
|
||||
|
||||
:::note
|
||||
In EKS v1.23 and above, you must use the out-of-tree drivers for EBS-backed volumes. You need [specific permissions](#ebs-csi-driver-addon-permissions) to enable this add-on.
|
||||
@@ -101,133 +101,66 @@ In EKS v1.23 and above, you must use the out-of-tree drivers for EBS-backed volu
|
||||
|
||||
Resource | Description
|
||||
---------|------------
|
||||
Service Role | Provides permissions that allow Kubernetes to manage resources on your behalf. Rancher can create the service role with the following [Service Role Permissions](#service-role-permissions).
|
||||
VPC | Provides isolated network resources utilised by EKS and worker nodes. Rancher can create the VPC resources with the following [VPC Permissions](#vpc-permissions).
|
||||
EBS CSI Driver add-on | Provides permissions that allow Kubernetes to interact with EBS and configure the cluster to enable the add-on (required for EKS v1.23 and above). Rancher can install the add-on with the following [EBS CSI Driver addon Permissions](#ebs-csi-driver-addon-permissions).
|
||||
|
||||
|
||||
Resource targeting uses `*` as the ARN of many of the resources created cannot be known before creating the EKS cluster in Rancher.
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "EC2Permissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:RunInstances",
|
||||
"ec2:RevokeSecurityGroupIngress",
|
||||
"ec2:RevokeSecurityGroupEgress",
|
||||
"ec2:DescribeInstanceTypes",
|
||||
"ec2:DescribeRegions",
|
||||
"ec2:DescribeVpcs",
|
||||
"ec2:DescribeTags",
|
||||
"ec2:DescribeSubnets",
|
||||
"ec2:DescribeSecurityGroups",
|
||||
"ec2:DescribeRouteTables",
|
||||
"ec2:DescribeLaunchTemplateVersions",
|
||||
"ec2:DescribeLaunchTemplates",
|
||||
"ec2:DescribeKeyPairs",
|
||||
"ec2:DescribeInternetGateways",
|
||||
"ec2:DescribeImages",
|
||||
"ec2:DescribeAvailabilityZones",
|
||||
"ec2:DescribeAccountAttributes",
|
||||
"ec2:DeleteTags",
|
||||
"ec2:DeleteLaunchTemplateVersions",
|
||||
"ec2:DeleteLaunchTemplate",
|
||||
"ec2:DeleteSecurityGroup",
|
||||
"ec2:DeleteKeyPair",
|
||||
"ec2:CreateTags",
|
||||
"ec2:CreateSecurityGroup",
|
||||
"ec2:CreateLaunchTemplateVersion",
|
||||
"ec2:CreateLaunchTemplate",
|
||||
"ec2:CreateKeyPair",
|
||||
"ec2:AuthorizeSecurityGroupIngress",
|
||||
"ec2:AuthorizeSecurityGroupEgress"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "CloudFormationPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"cloudformation:ListStacks",
|
||||
"cloudformation:ListStackResources",
|
||||
"cloudformation:DescribeStacks",
|
||||
"cloudformation:DescribeStackResources",
|
||||
"cloudformation:DescribeStackResource",
|
||||
"cloudformation:DeleteStack",
|
||||
"cloudformation:CreateStackSet",
|
||||
"cloudformation:CreateStack"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "IAMPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"iam:PassRole",
|
||||
"iam:ListRoles",
|
||||
"iam:ListRoleTags",
|
||||
"iam:ListInstanceProfilesForRole",
|
||||
"iam:ListInstanceProfiles",
|
||||
"iam:ListAttachedRolePolicies",
|
||||
"iam:GetRole",
|
||||
"iam:GetInstanceProfile",
|
||||
"iam:DetachRolePolicy",
|
||||
"iam:DeleteRole",
|
||||
"iam:CreateRole",
|
||||
"iam:AttachRolePolicy"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "KMSPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": "kms:ListKeys",
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "EKSPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"eks:UpdateNodegroupVersion",
|
||||
"eks:UpdateNodegroupConfig",
|
||||
"eks:UpdateClusterVersion",
|
||||
"eks:UpdateClusterConfig",
|
||||
"eks:UntagResource",
|
||||
"eks:TagResource",
|
||||
"eks:ListUpdates",
|
||||
"eks:ListTagsForResource",
|
||||
"eks:ListNodegroups",
|
||||
"eks:ListFargateProfiles",
|
||||
"eks:ListClusters",
|
||||
"eks:DescribeUpdate",
|
||||
"eks:DescribeNodegroup",
|
||||
"eks:DescribeFargateProfile",
|
||||
"eks:DescribeCluster",
|
||||
"eks:DeleteNodegroup",
|
||||
"eks:DeleteFargateProfile",
|
||||
"eks:DeleteCluster",
|
||||
"eks:CreateNodegroup",
|
||||
"eks:CreateFargateProfile",
|
||||
"eks:CreateCluster"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Service Role Permissions
|
||||
|
||||
These are permissions that are needed during EKS cluster creation, so Rancher can create a service role on the users' behalf.
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "EC2Permissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:AuthorizeSecurityGroupEgress",
|
||||
"ec2:AuthorizeSecurityGroupIngress",
|
||||
"ec2:CreateKeyPair",
|
||||
"ec2:CreateLaunchTemplate",
|
||||
"ec2:CreateLaunchTemplateVersion",
|
||||
"ec2:CreateSecurityGroup",
|
||||
"ec2:CreateTags",
|
||||
"ec2:DeleteKeyPair",
|
||||
"ec2:DeleteLaunchTemplate",
|
||||
"ec2:DeleteLaunchTemplateVersions",
|
||||
"ec2:DeleteSecurityGroup",
|
||||
"ec2:DeleteTags",
|
||||
"ec2:DescribeAccountAttributes",
|
||||
"ec2:DescribeAvailabilityZones",
|
||||
"ec2:DescribeImages",
|
||||
"ec2:DescribeInternetGateways",
|
||||
"ec2:DescribeInstanceTypes",
|
||||
"ec2:DescribeKeyPairs",
|
||||
"ec2:DescribeLaunchTemplateVersions",
|
||||
"ec2:DescribeLaunchTemplates",
|
||||
"ec2:DescribeRegions",
|
||||
"ec2:DescribeRouteTables",
|
||||
"ec2:DescribeSecurityGroups",
|
||||
"ec2:DescribeSubnets",
|
||||
"ec2:DescribeTags",
|
||||
"ec2:DescribeVpcs",
|
||||
"ec2:RevokeSecurityGroupEgress",
|
||||
"ec2:RevokeSecurityGroupIngress",
|
||||
"ec2:RunInstances"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "CloudFormationPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"cloudformation:CreateStack",
|
||||
"cloudformation:CreateStackSet",
|
||||
"cloudformation:DeleteStack",
|
||||
"cloudformation:DescribeStackResource",
|
||||
"cloudformation:DescribeStackResources",
|
||||
"cloudformation:DescribeStacks",
|
||||
"cloudformation:ListStackResources",
|
||||
"cloudformation:ListStacks"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "IAMPermissions",
|
||||
"Effect": "Allow",
|
||||
@@ -248,7 +181,70 @@ These are permissions that are needed during EKS cluster creation, so Rancher ca
|
||||
"iam:ListRoles",
|
||||
"iam:ListRoleTags",
|
||||
"iam:PassRole",
|
||||
"iam:RemoveRoleFromInstanceProfile"
|
||||
"iam:RemoveRoleFromInstanceProfile",
|
||||
"iam:TagRole"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "KMSPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": "kms:ListKeys",
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "EKSPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"eks:CreateCluster",
|
||||
"eks:CreateFargateProfile",
|
||||
"eks:CreateNodegroup",
|
||||
"eks:DeleteCluster",
|
||||
"eks:DeleteFargateProfile",
|
||||
"eks:DeleteNodegroup",
|
||||
"eks:DescribeAddon",
|
||||
"eks:DescribeCluster",
|
||||
"eks:DescribeFargateProfile",
|
||||
"eks:DescribeNodegroup",
|
||||
"eks:DescribeUpdate",
|
||||
"eks:ListClusters",
|
||||
"eks:ListFargateProfiles",
|
||||
"eks:ListNodegroups",
|
||||
"eks:ListTagsForResource",
|
||||
"eks:ListUpdates",
|
||||
"eks:TagResource",
|
||||
"eks:UntagResource",
|
||||
"eks:UpdateClusterConfig",
|
||||
"eks:UpdateClusterVersion",
|
||||
"eks:UpdateNodegroupConfig",
|
||||
"eks:UpdateNodegroupVersion"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "VPCPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:AssociateRouteTable",
|
||||
"ec2:AttachInternetGateway",
|
||||
"ec2:CreateInternetGateway",
|
||||
"ec2:CreateRoute",
|
||||
"ec2:CreateRouteTable",
|
||||
"ec2:CreateSecurityGroup",
|
||||
"ec2:CreateSubnet",
|
||||
"ec2:CreateVpc",
|
||||
"ec2:DeleteInternetGateway",
|
||||
"ec2:DeleteRoute",
|
||||
"ec2:DeleteRouteTable",
|
||||
"ec2:DeleteSubnet",
|
||||
"ec2:DeleteTags",
|
||||
"ec2:DeleteVpc",
|
||||
"ec2:DescribeVpcs",
|
||||
"ec2:DetachInternetGateway",
|
||||
"ec2:DisassociateRouteTable",
|
||||
"ec2:ModifySubnetAttribute",
|
||||
"ec2:ModifyVpcAttribute",
|
||||
"ec2:ReplaceRoute"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
@@ -281,79 +277,33 @@ arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
|
||||
arn:aws:iam::aws:policy/AmazonEKSServicePolicy
|
||||
```
|
||||
|
||||
### VPC Permissions
|
||||
|
||||
These are permissions that are needed by Rancher to create a Virtual Private Cloud (VPC) and associated resources.
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "VPCPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:ReplaceRoute",
|
||||
"ec2:ModifyVpcAttribute",
|
||||
"ec2:ModifySubnetAttribute",
|
||||
"ec2:DisassociateRouteTable",
|
||||
"ec2:DetachInternetGateway",
|
||||
"ec2:DescribeVpcs",
|
||||
"ec2:DeleteVpc",
|
||||
"ec2:DeleteTags",
|
||||
"ec2:DeleteSubnet",
|
||||
"ec2:DeleteRouteTable",
|
||||
"ec2:DeleteRoute",
|
||||
"ec2:DeleteInternetGateway",
|
||||
"ec2:CreateVpc",
|
||||
"ec2:CreateSubnet",
|
||||
"ec2:CreateSecurityGroup",
|
||||
"ec2:CreateRouteTable",
|
||||
"ec2:CreateRoute",
|
||||
"ec2:CreateInternetGateway",
|
||||
"ec2:AttachInternetGateway",
|
||||
"ec2:AssociateRouteTable"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### EBS CSI Driver addon Permissions
|
||||
|
||||
The following are the required permissions for installing the Amazon EBS CSI Driver add-on.
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"iam:GetRole",
|
||||
"eks:DescribeAddonConfiguration",
|
||||
"eks:UpdateAddon",
|
||||
"eks:ListAddons",
|
||||
"iam:CreateRole",
|
||||
"iam:AttachRolePolicy",
|
||||
"eks:DescribeAddon",
|
||||
"iam:CreateOpenIDConnectProvider",
|
||||
"iam:PassRole",
|
||||
"eks:DescribeIdentityProviderConfig",
|
||||
"eks:DeleteAddon",
|
||||
"iam:ListOpenIDConnectProviders",
|
||||
"iam:ListAttachedRolePolicies",
|
||||
"eks:CreateAddon",
|
||||
"eks:DescribeCluster",
|
||||
"eks:DescribeAddonVersions",
|
||||
"sts:AssumeRoleWithWebIdentity",
|
||||
"eks:AssociateIdentityProviderConfig",
|
||||
"eks:ListIdentityProviderConfigs"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"eks:AssociateIdentityProviderConfig",
|
||||
"eks:CreateAddon",
|
||||
"eks:DeleteAddon",
|
||||
"eks:DescribeAddonConfiguration",
|
||||
"eks:DescribeAddonVersions",
|
||||
"eks:DescribeIdentityProviderConfig",
|
||||
"eks:ListAddons",
|
||||
"eks:ListIdentityProviderConfigs",
|
||||
"eks:UpdateAddon",
|
||||
"iam:CreateOpenIDConnectProvider",
|
||||
"iam:ListOpenIDConnectProviders",
|
||||
"sts:AssumeRoleWithWebIdentity"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
@@ -31,6 +31,5 @@ Rancher contains a variety of tools that aren't included in Kubernetes to assist
|
||||
- Logging
|
||||
- Monitoring
|
||||
- Istio Service Mesh
|
||||
- OPA Gatekeeper
|
||||
|
||||
Tools can be installed through **Apps.**
|
||||
|
||||
+3
-4
@@ -19,10 +19,9 @@ In order to deploy and run the adapter successfully, you need to ensure its vers
|
||||
|
||||
| Rancher Version | Adapter Version |
|
||||
|-----------------|------------------|
|
||||
| v2.9.3 | v104.0.0+up4.0.0 |
|
||||
| v2.9.2 | v104.0.0+up4.0.0 |
|
||||
| v2.9.1 | v104.0.0+up4.0.0 |
|
||||
| v2.9.0 | v104.0.0+up4.0.0 |
|
||||
| v2.10.2 | v105.0.0+up5.0.1 |
|
||||
| v2.10.1 | v105.0.0+up5.0.1 |
|
||||
| v2.10.0 | v105.0.0+up5.0.1 |
|
||||
|
||||
### 1. Gain Access to the Local Cluster
|
||||
|
||||
|
||||
@@ -6,10 +6,13 @@ title: Overview
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/fleet/overview"/>
|
||||
</head>
|
||||
|
||||
Continuous Delivery with Fleet is GitOps at scale. Fleet is designed to manage up to a million clusters. It’s also lightweight enough that it works great for a [single cluster](https://fleet.rancher.io/installation#default-install) too, but it really shines when you get to a [large scale](https://fleet.rancher.io/installation#configuration-for-multi-cluster). By large scale we mean either a lot of clusters, a lot of deployments, or a lot of teams in a single organization.
|
||||
## What is Continuous Delivery with Fleet?
|
||||
|
||||
Fleet is a separate project from Rancher, and can be installed on any Kubernetes cluster with Helm.
|
||||
Continuous Delivery is Rancher's GitOps functionality, which is provided via integration with Fleet.
|
||||
|
||||
- *Cluster engine*: Fleet is a container management and deployment engine designed to offer users more control on the local cluster and constant monitoring through GitOps. Fleet focuses not only on the ability to scale, but it also gives users a high degree of control and visibility to monitor exactly what is installed on the cluster.
|
||||
|
||||
- *Deployment management*: Fleet can manage deployments from git of raw Kubernetes YAML, Helm charts, Kustomize, or any combination of the three. Regardless of the source, all resources are dynamically turned into Helm charts, and Helm is used as the engine to deploy all resources in the cluster. As a result, users can enjoy a high degree of control, consistency, and auditability of their clusters.
|
||||
|
||||
## Architecture
|
||||
|
||||
|
||||
@@ -61,9 +61,6 @@ Once Prometheus determines that an alert needs to be fired, alerts are forwarded
|
||||
|
||||
- Routes and receivers are also stored in the Kubernetes API via the Alertmanager Secret. When the Secret is updated, Alertmanager is also updated automatically. Note that routing occurs via labels only (not via annotations, etc.).
|
||||
|
||||
<figcaption>How data flows through the monitoring application:</figcaption>
|
||||
|
||||
|
||||
## 2. How Prometheus Works
|
||||
|
||||
### Storing Time Series Data
|
||||
|
||||
@@ -1,117 +0,0 @@
|
||||
---
|
||||
title: OPA Gatekeeper
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/opa-gatekeeper"/>
|
||||
</head>
|
||||
|
||||
<DeprecationOPAGatekeeper link="kubewarden" />
|
||||
|
||||
To ensure consistency and compliance, every organization needs the ability to define and enforce policies in its environment in an automated way. [OPA (Open Policy Agent)](https://www.openpolicyagent.org/) is a policy engine that facilitates policy-based control for cloud native environments. Rancher provides the ability to enable OPA Gatekeeper in Kubernetes clusters, and also installs a couple of built-in policy definitions, which are also called constraint templates.
|
||||
|
||||
OPA provides a high-level declarative language that lets you specify policy as code and ability to extend simple APIs to offload policy decision-making.
|
||||
|
||||
[OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper) is a project that provides integration between OPA and Kubernetes. OPA Gatekeeper provides:
|
||||
|
||||
- An extensible, parameterized policy library.
|
||||
- Native Kubernetes CRDs for instantiating the policy library, also called “constraints."
|
||||
- Native Kubernetes CRDs for extending the policy library, also called "constraint templates."
|
||||
- Audit functionality.
|
||||
|
||||
To read more about OPA, please refer to the [official documentation.](https://www.openpolicyagent.org/docs/latest/)
|
||||
|
||||
## How the OPA Gatekeeper Integration Works
|
||||
|
||||
Kubernetes provides the ability to extend API server functionality via admission controller webhooks, which are invoked whenever a resource is created, updated or deleted. Gatekeeper is installed as a validating webhook and enforces policies defined by Kubernetes custom resource definitions. In addition to the admission control usage, Gatekeeper provides the capability to audit existing resources in Kubernetes clusters and mark current violations of enabled policies.
|
||||
|
||||
OPA Gatekeeper is made available via Rancher's Helm system chart, and it is installed in a namespace named `gatekeeper-system.`
|
||||
|
||||
## Enabling OPA Gatekeeper in a Cluster
|
||||
|
||||
:::note
|
||||
|
||||
In Rancher v2.5, the OPA Gatekeeper application was improved. The Rancher v2.4 feature can't be upgraded to the new version in Rancher v2.5. If you installed OPA Gatekeeper in Rancher v2.4, you will need to uninstall OPA Gatekeeper and its CRDs from the old UI, then reinstall it in Rancher v2.5. To uninstall the CRDs run the following command in the kubectl console `kubectl delete crd configs.config.gatekeeper.sh constrainttemplates.templates.gatekeeper.sh`.
|
||||
|
||||
:::
|
||||
|
||||
:::note Prerequisite:
|
||||
|
||||
Only administrators and cluster owners can enable OPA Gatekeeper.
|
||||
|
||||
:::
|
||||
|
||||
The OPA Gatekeeper Helm chart can be installed from **Apps**.
|
||||
|
||||
### Enabling OPA Gatekeeper
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. In the **Clusters** page, go to the cluster where you want to enable OPA Gatekeeper and click **Explore**.
|
||||
1. In the left navigation bar, click **Apps**.
|
||||
1. Click **Charts** and click **OPA Gatekeeper**.
|
||||
1. Click **Install**.
|
||||
|
||||
**Result:** OPA Gatekeeper is deployed in your Kubernetes cluster.
|
||||
|
||||
## Constraint Templates
|
||||
|
||||
[Constraint templates](https://github.com/open-policy-agent/gatekeeper#constraint-templates) are Kubernetes custom resources that define the schema and Rego logic of the OPA policy to be applied by Gatekeeper. For more information on the Rego policy language, refer to the [official documentation.](https://www.openpolicyagent.org/docs/latest/policy-language/)
|
||||
|
||||
When OPA Gatekeeper is enabled, Rancher installs some templates by default.
|
||||
|
||||
To list the constraint templates installed in the cluster, go to the left side menu under OPA Gatekeeper and click on **Templates**.
|
||||
|
||||
Rancher also provides the ability to create your own constraint templates by importing YAML definitions.
|
||||
|
||||
## Creating and Configuring Constraints
|
||||
|
||||
[Constraints](https://github.com/open-policy-agent/gatekeeper#constraints) are Kubernetes custom resources that define the scope of objects to which a specific constraint template applies to. The complete policy is defined by constraint templates and constraints together.
|
||||
|
||||
:::note Prerequisite:
|
||||
|
||||
OPA Gatekeeper must be enabled in the cluster.
|
||||
|
||||
:::
|
||||
|
||||
To list the constraints installed, go to the left side menu under OPA Gatekeeper, and click on **Constraints**.
|
||||
|
||||
New constraints can be created from a constraint template.
|
||||
|
||||
Rancher provides the ability to create a constraint by using a convenient form that lets you input the various constraint fields.
|
||||
|
||||
The **Edit as yaml** option is also available to configure the the constraint's yaml definition.
|
||||
|
||||
### Exempting Rancher's System Namespaces from Constraints
|
||||
|
||||
When a constraint is created, ensure that it does not apply to any Rancher or Kubernetes system namespaces. If the system namespaces are not excluded, then it is possible to see many resources under them marked as violations of the constraint.
|
||||
|
||||
To limit the scope of the constraint only to user namespaces, always specify these namespaces under the **Match** field of the constraint.
|
||||
|
||||
Also, the constraint may interfere with other Rancher functionality and deny system workloads from being deployed. To avoid this, exclude all Rancher-specific namespaces from your constraints.
|
||||
|
||||
## Enforcing Constraints in your Cluster
|
||||
|
||||
When the **Enforcement Action** is **Deny,** the constraint is immediately enabled and will deny any requests that violate the policy defined. By default, the enforcement value is **Deny**.
|
||||
|
||||
When the **Enforcement Action** is **Dryrun,** then any resources that violate the policy are only recorded under the constraint's status field.
|
||||
|
||||
To enforce constraints, create a constraint using the form. In the **Enforcement Action** field, choose **Deny**.
|
||||
|
||||
## Audit and Violations in your Cluster
|
||||
|
||||
OPA Gatekeeper runs a periodic audit to check if any existing resource violates any enforced constraint. The audit-interval (default 300s) can be configured while installing Gatekeeper.
|
||||
|
||||
On the Gatekeeper page, any violations of the defined constraints are listed.
|
||||
|
||||
Also under **Constraints,** the number of violations of the constraint can be found.
|
||||
|
||||
The detail view of each constraint lists information about the resource that violated the constraint.
|
||||
|
||||
## Disabling Gatekeeper
|
||||
|
||||
1. Navigate to the cluster's Dashboard view
|
||||
1. On the left side menu, expand the cluster menu and click on **OPA Gatekeeper**.
|
||||
1. Click the **⋮ > Disable**.
|
||||
|
||||
**Result:** Upon disabling OPA Gatekeeper, all constraint templates and constraints will also be deleted.
|
||||
|
||||
@@ -25,6 +25,24 @@ Select the first option to perform a one-time backup, or select the second optio
|
||||
| `schedule` | Provide the cron string for scheduling recurring backups. |
|
||||
| `retentionCount` | Provide the number of backup files to be retained. |
|
||||
|
||||
## ResourceSet
|
||||
|
||||
While you can create your own ResourceSets to back up custom applications, two ResourceSets specifically for backing up Rancher are officially maintained and created by default by the `rancher-backup` operator. We refer to these as `rancher-resource-set-basic` and `rancher-resource-set-full`. The difference between them is whether they include secrets or not in the backups.
|
||||
|
||||
`rancher-resource-set-basic` does not include any secrets in the backup files to safeguard confidential information. You are responsible for recording any secrets and redeploying them safely.
|
||||
|
||||
`rancher-resource-set-full` includes all essential secrets in the backup files to ensure Rancher continues running smoothly after a restore or migration. To avoid storing sensitive information in plain text, we strongly advise you to enable encryption with a strong key.
|
||||
|
||||
:::note Important:
|
||||
|
||||
`rancher-resource-set` is also included by default with the `rancher-backup` operator. However, this ResourceSet is deprecated and is only being kept for backwards compatibility reasons. `rancher-resource-set` will be removed in Rancher v2.12. Please update your Backup custom resources to use either `rancher-resource-set-full` or `rancher-resource-set-basic`.
|
||||
|
||||
:::
|
||||
|
||||
| YAML Directive Name | Description |
|
||||
| ---------------- | ---------------- |
|
||||
| `resourceSetName` | Provide the name of the ResourceSet to define which resources will be included in this backup. |
|
||||
|
||||
## Encryption
|
||||
|
||||
The rancher-backup gathers resources by making calls to the kube-apiserver. Objects returned by apiserver are decrypted, so even if [encryption at rest](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) is enabled, even the encrypted objects gathered by the backup will be in plaintext.
|
||||
|
||||
@@ -26,7 +26,7 @@ kind: Backup
|
||||
metadata:
|
||||
name: default-location-encrypted-backup
|
||||
spec:
|
||||
resourceSetName: rancher-resource-set
|
||||
resourceSetName: rancher-resource-set-full
|
||||
encryptionConfigSecretName: encryptionconfig
|
||||
```
|
||||
|
||||
@@ -38,7 +38,7 @@ kind: Backup
|
||||
metadata:
|
||||
name: default-location-recurring-backup
|
||||
spec:
|
||||
resourceSetName: rancher-resource-set
|
||||
resourceSetName: rancher-resource-set-basic
|
||||
schedule: "@every 1h"
|
||||
retentionCount: 10
|
||||
```
|
||||
@@ -51,7 +51,7 @@ kind: Backup
|
||||
metadata:
|
||||
name: default-enc-recurring-backup
|
||||
spec:
|
||||
resourceSetName: rancher-resource-set
|
||||
resourceSetName: rancher-resource-set-full
|
||||
encryptionConfigSecretName: encryptionconfig
|
||||
schedule: "@every 1h"
|
||||
retentionCount: 3
|
||||
@@ -72,7 +72,7 @@ spec:
|
||||
bucketName: rancherbackups
|
||||
endpoint: minio.xip.io
|
||||
endpointCA: <base64-encoded-cert>
|
||||
resourceSetName: rancher-resource-set
|
||||
resourceSetName: rancher-resource-set-full
|
||||
encryptionConfigSecretName: encryptionconfig
|
||||
```
|
||||
|
||||
@@ -92,7 +92,7 @@ spec:
|
||||
folder: ecm1
|
||||
region: us-west-2
|
||||
endpoint: s3.us-west-2.amazonaws.com
|
||||
resourceSetName: rancher-resource-set
|
||||
resourceSetName: rancher-resource-set-full
|
||||
encryptionConfigSecretName: encryptionconfig
|
||||
```
|
||||
|
||||
@@ -112,7 +112,7 @@ spec:
|
||||
folder: ecm1
|
||||
region: us-west-2
|
||||
endpoint: s3.us-west-2.amazonaws.com
|
||||
resourceSetName: rancher-resource-set
|
||||
resourceSetName: rancher-resource-set-full
|
||||
encryptionConfigSecretName: encryptionconfig
|
||||
schedule: "@every 1h"
|
||||
retentionCount: 10
|
||||
@@ -134,7 +134,7 @@ spec:
|
||||
folder: ecm1
|
||||
region: us-west-2
|
||||
endpoint: s3.us-west-2.amazonaws.com
|
||||
resourceSetName: rancher-resource-set
|
||||
resourceSetName: rancher-resource-set-full
|
||||
encryptionConfigSecretName: encryptionconfig
|
||||
```
|
||||
|
||||
|
||||
+1
-1
@@ -139,5 +139,5 @@ At high scale, Rancher transfers more data from the upstream cluster to UI compo
|
||||
For best performance, ensure that the host running the hardware meets these requirements:
|
||||
- 2020 i5 10th generation Intel (4 cores) or equivalent
|
||||
- 8 GB RAM
|
||||
- Total network bandwith to the upstream cluster: 72 Mb/s (equivalent to a single 802.11n Wi-Fi 4 link stream, ~8 MB/s http download throughput)
|
||||
- Total network bandwidth to the upstream cluster: 72 Mb/s (equivalent to a single 802.11n Wi-Fi 4 link stream, ~8 MB/s http download throughput)
|
||||
- Round-trip time (ping time) from browser to upstream cluster: 150 ms or less
|
||||
|
||||
+1
-1
@@ -8,7 +8,7 @@ title: AKS Cluster Configuration Reference
|
||||
|
||||
## Role-based Access Control
|
||||
|
||||
When provisioning an AKS cluster in the Rancher UI, RBAC cannot be disabled. If role-based access control is disabled for the cluster in AKS, the cluster cannot be registered or imported into Rancher.
|
||||
When provisioning an AKS cluster in the Rancher UI, RBAC cannot be disabled. If RBAC is disabled in the AKS cluster, the cluster cannot be registered or imported into Rancher. In practice, this means that local accounts must be enabled in order to register or import an AKS cluster.
|
||||
|
||||
Rancher can configure member roles for AKS clusters in the same way as any other cluster. For more information, see the section on [role-based access control.](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)
|
||||
|
||||
|
||||
@@ -42,12 +42,6 @@ Rancher's integration with Istio was improved in Rancher v2.5.
|
||||
|
||||
For more information, refer to the Istio documentation [here.](../integrations-in-rancher/istio/istio.md)
|
||||
|
||||
## OPA Gatekeeper
|
||||
|
||||
<DeprecationOPAGatekeeper link="../integrations-in-rancher/kubewarden" />
|
||||
|
||||
[OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper) is an open-source project that provides integration between OPA and Kubernetes to provide policy control via admission controller webhooks. For details on how to enable Gatekeeper in Rancher, refer to the [OPA Gatekeeper section.](../integrations-in-rancher/opa-gatekeeper.md)
|
||||
|
||||
## CIS Scans
|
||||
|
||||
Rancher can run a security scan to check whether Kubernetes is deployed according to security best practices as defined in the CIS Kubernetes Benchmark.
|
||||
|
||||
@@ -10,7 +10,12 @@ Rancher is committed to informing the community of security issues in our produc
|
||||
|
||||
| ID | Description | Date | Resolution |
|
||||
|----|-------------|------|------------|
|
||||
[CVE-2024-22030](https://github.com/rancher/rancher/security/advisories/GHSA-h4h5-9833-v2p4) | A high severity vulnerability was discovered in Rancher's agents that under very specific circumstances allows a malicious actor to take over existing Rancher nodes. The attacker needs to have control of an expired domain or execute a DNS spoofing/hijacking attack against the domain in order to exploit this vulnerability. The targeted domain is the one used as the Rancher URL (the `server-url` of the Rancher cluster). | 19 Sep 2024 | Rancher [v2.9.2](https://github.com/rancher/rancher/releases/tag/v2.9.2), [v2.8.8](https://github.com/rancher/rancher/releases/tag/v2.8.8) and [v2.7.15](https://github.com/rancher/rancher/releases/tag/v2.7.15) |
|
||||
| [CVE-2024-52281](https://github.com/rancher/rancher/security/advisories/GHSA-2v2w-8v8c-wcm9) | A high severity vulnerability was identified within the Rancher UI that allows a malicious actor to perform a Stored XSS attack through the cluster description field. | 15 Jan 2025 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) |
|
||||
| [CVE-2024-52282](https://github.com/rancher/rancher/security/advisories/GHSA-9c5p-35gj-jqp4) | A medium severity vulnerability was discovered within Rancher Manager whereby applications installed via Rancher Manager Apps Catalog store their Helm values directly into the Apps Custom Resource Definition, resulting in any users with GET access to it to be able to read any sensitive information that are contained within the Apps’ values. Additionally, the same information leaks into auditing logs when the audit level is set to equal or above 2. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 19 Nov 2024 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.8.10](https://github.com/rancher/rancher/releases/tag/v2.8.10). |
|
||||
| [CVE-2024-22036](https://github.com/rancher/rancher/security/advisories/GHSA-h99m-6755-rgwc) | A critical severity vulnerability was discovered within Rancher where a cluster or node driver can be used to escape the `chroot` jail and gain root access to the Rancher container itself. In production environments, further privilege escalation is possible based on living off the land within the Rancher container itself. For test and development environments, based on a –privileged Docker container, it is possible to escape the Docker container and gain execution access on the host system. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3), [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) and [v2.7.16](https://github.com/rancher/rancher/releases/tag/v2.7.16) |
|
||||
| [CVE-2023-32197](https://github.com/rancher/rancher/security/advisories/GHSA-7h8m-pvw3-5gh4) | A critical severity vulnerability was discovered whereby Rancher Manager deployments containing Windows nodes have weak Access Control Lists (ACL), allowing `BUILTIN\Users` or `NT AUTHORITY\Authenticated Users` to view or edit sensitive files which could lead to privilege escalation. This vulnerability is exclusive to deployments that contain Windows nodes. Linux-only environments are not affected by it. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) |
|
||||
| [CVE-2022-45157](https://github.com/rancher/rancher/security/advisories/GHSA-xj7w-r753-vj8v) | A critical severity vulnerability was discovered in the way that Rancher stores vSphere's CPI (Cloud Provider Interface) and CSI (Container Storage Interface) credentials used to deploy clusters through the vSphere cloud provider. This issue leads to the vSphere CPI and CSI passwords being stored in a plaintext object inside Rancher. This vulnerability is only applicable to users that deploy clusters in vSphere environments. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) |
|
||||
| [CVE-2024-22030](https://github.com/rancher/rancher/security/advisories/GHSA-h4h5-9833-v2p4) | A high severity vulnerability was discovered in Rancher's agents that under very specific circumstances allows a malicious actor to take over existing Rancher nodes. The attacker needs to have control of an expired domain or execute a DNS spoofing/hijacking attack against the domain in order to exploit this vulnerability. The targeted domain is the one used as the Rancher URL (the `server-url` of the Rancher cluster). | 19 Sep 2024 | Rancher [v2.9.2](https://github.com/rancher/rancher/releases/tag/v2.9.2), [v2.8.8](https://github.com/rancher/rancher/releases/tag/v2.8.8) and [v2.7.15](https://github.com/rancher/rancher/releases/tag/v2.7.15) |
|
||||
| [CVE-2024-22032](https://github.com/rancher/rancher/security/advisories/GHSA-q6c7-56cq-g2wm) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where custom secrets encryption configurations are stored in plaintext under the clusters `AppliedSpec`. This also causes clusters to continuously reconcile, as the `AppliedSpec` would never match the desired cluster `Spec`. The stored information contains the encryption configuration for secrets within etcd, and could potentially expose sensitive data if the etcd database was exposed directly. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
| [CVE-2023-32196](https://github.com/rancher/rancher/security/advisories/GHSA-64jq-m7rq-768h) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where the webhook rule resolver ignores rules from a `ClusterRole` for an external `RoleTemplate` set with `.context=project` or `.context=""`. This allows a user to create an external `ClusterRole` with `.context=project` or `.context=""`, depending on the use of the new feature flag `external-rules` and backing `ClusterRole`. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
| [CVE-2023-22650](https://github.com/rancher/rancher/security/advisories/GHSA-9ghh-mmcq-8phc) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where Rancher did not have a user retention process for when external authentication providers are used, that could be configured to run periodically and disable and/or delete inactive users. The new user retention process added in Rancher v2.8.5 and Rancher v2.7.14 is disabled by default. If enabled, a user becomes subject to the retention process if they don't log in for a configurable period of time. It's possible to set overrides for user accounts that are primarily intended for programmatic access (e.g. CI, scripts, etc.) so that they don't become subject to the retention process for a longer period of time or at all. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
|
||||
@@ -20,10 +20,9 @@ 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.3 | v0.5.3 | ✓ | ✓ |
|
||||
| v2.9.2 | v0.5.2 | ✓ | ✓ |
|
||||
| v2.9.1 | v0.5.1 | ✓ | ✓ |
|
||||
| v2.9.0 | v0.5.0 | ✗ | ✓ |
|
||||
| v2.10.2 | v0.6.3 | ✓ | ✓ |
|
||||
| v2.10.1 | v0.6.2 | ✓ | ✓ |
|
||||
| v2.10.0 | v0.6.1 | ✗ | ✓ |
|
||||
|
||||
## Why Do We Need It?
|
||||
|
||||
|
||||
@@ -185,9 +185,9 @@ module.exports = {
|
||||
label: 'Latest',
|
||||
},
|
||||
'2.10': {
|
||||
label: 'v2.10 (Preview)',
|
||||
label: 'v2.10',
|
||||
path: 'v2.10',
|
||||
banner: 'unreleased'
|
||||
banner: 'none'
|
||||
},
|
||||
2.9: {
|
||||
label: 'v2.9',
|
||||
@@ -202,12 +202,10 @@ module.exports = {
|
||||
2.7: {
|
||||
label: 'v2.7',
|
||||
path: 'v2.7',
|
||||
banner: 'none'
|
||||
},
|
||||
2.6: {
|
||||
label: 'v2.6',
|
||||
path: 'v2.6',
|
||||
banner: 'none'
|
||||
},
|
||||
2.5: {
|
||||
label: 'v2.5',
|
||||
@@ -2556,10 +2554,6 @@ module.exports = {
|
||||
to: '/integrations-in-rancher/neuvector',
|
||||
from: '/explanations/integrations-in-rancher/neuvector'
|
||||
},
|
||||
{
|
||||
to: '/integrations-in-rancher/opa-gatekeeper',
|
||||
from: '/explanations/integrations-in-rancher/opa-gatekeeper'
|
||||
},
|
||||
{
|
||||
to: '/v2.6/faq/general-faq',
|
||||
from: '/v2.6/faq'
|
||||
|
||||
+6
@@ -14,6 +14,7 @@ title: 功能开关
|
||||
|
||||
以下是 Rancher 中可用的功能开关列表。如果你是从旧 Rancher 版本升级的,你可能会在 Rancher UI 中看到其他功能,例如 `proxy` 或 `dashboard`(均[已中断](/versioned_docs/version-2.5/reference-guides/installation-references/feature-flags.md)):
|
||||
|
||||
- `clean-stale-secrets`: Removes stale secrets from the `cattle-impersonation-system` namespace. This slowly cleans up old secrets which are no longer being used by the impersonation system.
|
||||
- `continuous-delivery`:允许从 Fleet 中单独禁用 Fleet GitOps。有关详细信息,请参阅[持续交付](../../../how-to-guides/advanced-user-guides/enable-experimental-features/continuous-delivery.md)。
|
||||
- `fleet`:v2.6 及更高版本的 Rancher 配置框架需要 Fleet。即使你在旧 Rancher 版本中禁用了该标志,该标志也将在升级时自动启用。有关详细信息,请参阅 [Fleet - GitOps at Scale](../../../integrations-in-rancher/fleet/fleet.md)。
|
||||
- `harvester`:管理 Virtualization Management 页面的访问。用户可以在该页面直接导航到 Harvester 集群并访问 Harvester UI。有关详细信息,请参阅 [Harvester 集成](../../../integrations-in-rancher/harvester/overview.md)。
|
||||
@@ -23,12 +24,15 @@ title: 功能开关
|
||||
- `rke1-custom-node-cleanup`:清除已删除的 RKE1 自定义节点。建议你启用此标志,以防止已删除的节点尝试重新加入集群。
|
||||
- `rke2`:启用配置 RKE2 集群。此标志默认启用。
|
||||
- `token-hashing`:启用令牌哈希。启用后,会使用 SHA256 算法对现有 Token 和所有新 Token 进行哈希处理。一旦对 Token 进行哈希处理,就无法撤消操作。此标志在启用后无法禁用。有关详细信息,请参阅 [API 令牌](../../../api/api-tokens.md#令牌哈希)。
|
||||
- `uiextension`: Enables UI extensions. This flag is enabled by default. Enabling or disabling the flag forces the Rancher pod to restart. The first time this flag is set to `true`, it creates a CRD and enables the controllers and endpoints necessary for the feature to work. If set to `false`, it disables the previously mentioned controllers and endpoints. Setting `uiextension` to `false` has no effect on the CRD -- it does not create a CRD if it does not yet exist, nor does it delete the CRD if it already exists.
|
||||
- `unsupported-storage-drivers`:允许启用非默认启用的存储提供程序和卷插件。有关详细信息,请参阅[允许使用不受支持的存储驱动程序](../../../how-to-guides/advanced-user-guides/enable-experimental-features/unsupported-storage-drivers.md)。
|
||||
- `ui-sql-cache`: Enables a SQLite-based cache for UI tables. See [UI Server-Side Pagination](../../../how-to-guides/advanced-user-guides/enable-experimental-features/ui-server-side-pagination.md) for more information.
|
||||
|
||||
下表介绍了 Rancher 中功能开关的可用性和默认值。标记为“GA”的功能已普遍可用:
|
||||
|
||||
| 功能开关名称 | 默认值 | 状态 | 可用于 |
|
||||
| ----------------------------- | ------------- | ------------ | --------------- |
|
||||
| `clean-stale-secrets` | `true` | GA | v2.10.2 | |
|
||||
| `continuous-delivery` | `true` | GA | v2.6.0 |
|
||||
| `fleet` | `true` | 不能禁用 | v2.6.0 |
|
||||
| `fleet` | `true` | GA | v2.5.0 |
|
||||
@@ -37,3 +41,5 @@ title: 功能开关
|
||||
| `rke1-custom-node-cleanup` | `true` | GA | v2.6.0 |
|
||||
| `rke2` | `true` | 实验功能 | v2.6.0 |
|
||||
| `token-hashing` | 新安装:`false`;升级:`true` | GA | v2.6.0 |
|
||||
| `uiextension` | `true` | GA | v2.9.0 | |
|
||||
| `ui-sql-cache` | `false` | Highly experimental | v2.9.0 | |
|
||||
|
||||
+4
@@ -188,3 +188,7 @@ openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout myservice.ke
|
||||
|
||||
* 检查你的 Keycloak 日志。
|
||||
* 如果日志显示 `request validation failed: org.keycloak.common.VerificationException: SigAlg was null`,请在 Keycloak 客户端中将 `Client Signature Required` 设为 `OFF`。
|
||||
|
||||
## Configuring SAML Single Logout (SLO)
|
||||
|
||||
<ConfigureSLO />
|
||||
|
||||
+4
@@ -105,3 +105,7 @@ OpenLDAP ServiceAccount 用于所有搜索。无论用户个人的 SAML 权限
|
||||
1. 在**用户和组搜索**下,选中**配置 OpenLDAP Server**。
|
||||
|
||||
如果你在测试与 OpenLDAP Server 的连接时遇到问题,请确保你输入了ServiceAccount 的凭证并正确配置了搜索库。你可以检查 Rancher 日志来查明根本原因。调试日志可能包含有关错误的更详细信息。请参阅[如何启用调试日志](../../../../faq/technical-items.md#如何启用调试日志记录)了解更多信息。
|
||||
|
||||
## Configuring SAML Single Logout (SLO)
|
||||
|
||||
<ConfigureSLO />
|
||||
|
||||
+4
@@ -60,3 +60,7 @@ title: 配置 PingIdentity (SAML)
|
||||
- 用户组下拉列表仅显示你所属的用户组。如果你不是某个组的成员,你将无法添加该组。
|
||||
|
||||
:::
|
||||
|
||||
## Configuring SAML Single Logout (SLO)
|
||||
|
||||
<ConfigureSLO />
|
||||
|
||||
+4
@@ -51,3 +51,7 @@ title: 2. 在 Rancher 中配置 Microsoft AD FS
|
||||
```
|
||||
openssl req -x509 -newkey rsa:2048 -keyout myservice.key -out myservice.cert -days 365 -nodes -subj "/CN=myservice.example.com"
|
||||
```
|
||||
|
||||
## Configuring SAML Single Logout (SLO)
|
||||
|
||||
<ConfigureSLO />
|
||||
|
||||
+4
@@ -76,6 +76,10 @@ SAML 协议不支持用户或用户组的搜索或查找。因此,如果你没
|
||||
|
||||
要在 Rancher 中分配权限时启用搜索组,你需要为 SAML 身份认证服务配置支持组的后端(例如 OpenLDAP)。
|
||||
|
||||
### Configuring SAML Single Logout (SLO)
|
||||
|
||||
<ConfigureSLO />
|
||||
|
||||
# 在 Rancher 中设置 OpenLDAP
|
||||
|
||||
如果你将 OpenLDAP 配置为 Shibboleth 的后端,SAML 断言会返回到 Rancher,其中包括用于引用组的用户属性。然后,通过认证的用户将能够访问其所在的组有权访问的 Rancher 资源。
|
||||
|
||||
-2
@@ -19,7 +19,5 @@ Rancher Server 的数据存储在 etcd 中。etcd 数据库可以在所有三个
|
||||
- Ingress Controller 会把 HTTP 重定向到 HTTPS,在 TCP/443 端口终结 SSL/TLS。
|
||||
- Ingress Controller 会把流量转发到 Rancher deployment 的 Pod 上的 TCP/80 端口。
|
||||
|
||||
<figcaption>使用 4 层负载均衡器在 Kubernetes 集群中安装 Rancher:Ingress Controller 的 SSL 终止:</figcaption>
|
||||
|
||||

|
||||
<sup>使用 4 层负载均衡器在 Kubernetes 集群中安装 Rancher:Ingress Controller 的 SSL 终止</sup>
|
||||
|
||||
-3
@@ -56,9 +56,6 @@ PrometheusRule 用于定义指标或时间序列数据库查询触发告警的
|
||||
|
||||
- 路由和接收器也通过 Alertmanager Secret 存储在 Kubernetes API 中。当 Secret 更新时,Alertmanager 也会自动更新。请注意,路由仅通过标签发生(而不是通过注释等)。
|
||||
|
||||
<figcaption>数据如何流经 Monitoring 应用程序</figcaption>
|
||||
|
||||
|
||||
## 2. Prometheus 的工作原理
|
||||
|
||||
### 存储时间序列数据
|
||||
|
||||
+10
-1
@@ -10,7 +10,16 @@ Rancher 致力于向社区披露我们产品的安全问题。我们会针对已
|
||||
|
||||
| ID | 描述 | 日期 | 解决 |
|
||||
|----|-------------|------|------------|
|
||||
| [CVE-2024-22030](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-22030) | 发现了 Rancher 和 Fleet 代理的一个漏洞,目前被认为是中到高危的 CVE。在非特定情况下,这个漏洞允许恶意行为者接管现有的 Rancher 节点。攻击者需要控制一个过期的域名,或者对该域名执行 DNS 欺骗/劫持攻击才可以利用此漏洞。被攻击的域名是 Rancher URL(用作 Rancher 集群的 server-url)。目前还没有可用的修复方案,它影响所有受支持的 Rancher 版本。建议客户和用户遵循我们[博客文章](https://www.suse.com/c/rancher-security-update/)中描述的建议和最佳实践。 | 2024 年 2 月 16 日 | 处理中 |
|
||||
| [CVE-2024-52281](https://github.com/rancher/rancher/security/advisories/GHSA-2v2w-8v8c-wcm9) | A high severity vulnerability was identified within the Rancher UI that allows a malicious actor to perform a Stored XSS attack through the cluster description field. | 15 Jan 2025 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) |
|
||||
| [CVE-2024-52282](https://github.com/rancher/rancher/security/advisories/GHSA-9c5p-35gj-jqp4) | A medium severity vulnerability was discovered within Rancher Manager whereby applications installed via Rancher Manager Apps Catalog store their Helm values directly into the Apps Custom Resource Definition, resulting in any users with GET access to it to be able to read any sensitive information that are contained within the Apps’ values. Additionally, the same information leaks into auditing logs when the audit level is set to equal or above 2. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 19 Nov 2024 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.8.10](https://github.com/rancher/rancher/releases/tag/v2.8.10). |
|
||||
| [CVE-2024-22036](https://github.com/rancher/rancher/security/advisories/GHSA-h99m-6755-rgwc) | A critical severity vulnerability was discovered within Rancher where a cluster or node driver can be used to escape the `chroot` jail and gain root access to the Rancher container itself. In production environments, further privilege escalation is possible based on living off the land within the Rancher container itself. For test and development environments, based on a –privileged Docker container, it is possible to escape the Docker container and gain execution access on the host system. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3), [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) and [v2.7.16](https://github.com/rancher/rancher/releases/tag/v2.7.16) |
|
||||
| [CVE-2023-32197](https://github.com/rancher/rancher/security/advisories/GHSA-7h8m-pvw3-5gh4) | A critical severity vulnerability was discovered whereby Rancher Manager deployments containing Windows nodes have weak Access Control Lists (ACL), allowing `BUILTIN\Users` or `NT AUTHORITY\Authenticated Users` to view or edit sensitive files which could lead to privilege escalation. This vulnerability is exclusive to deployments that contain Windows nodes. Linux-only environments are not affected by it. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) |
|
||||
| [CVE-2022-45157](https://github.com/rancher/rancher/security/advisories/GHSA-xj7w-r753-vj8v) | A critical severity vulnerability was discovered in the way that Rancher stores vSphere's CPI (Cloud Provider Interface) and CSI (Container Storage Interface) credentials used to deploy clusters through the vSphere cloud provider. This issue leads to the vSphere CPI and CSI passwords being stored in a plaintext object inside Rancher. This vulnerability is only applicable to users that deploy clusters in vSphere environments. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) |
|
||||
| [CVE-2024-22030](https://github.com/rancher/rancher/security/advisories/GHSA-h4h5-9833-v2p4) | 发现了 Rancher 和 Fleet 代理的一个漏洞,目前被认为是中到高危的 CVE。在非特定情况下,这个漏洞允许恶意行为者接管现有的 Rancher 节点。攻击者需要控制一个过期的域名,或者对该域名执行 DNS 欺骗/劫持攻击才可以利用此漏洞。被攻击的域名是 Rancher URL(用作 Rancher 集群的 server-url)。目前还没有可用的修复方案,它影响所有受支持的 Rancher 版本。建议客户和用户遵循我们[博客文章](https://www.suse.com/c/rancher-security-update/)中描述的建议和最佳实践。 | 2024 年 9 月 19 日 | 处理中 |
|
||||
| [CVE-2024-22032](https://github.com/rancher/rancher/security/advisories/GHSA-q6c7-56cq-g2wm) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where custom secrets encryption configurations are stored in plaintext under the clusters `AppliedSpec`. This also causes clusters to continuously reconcile, as the `AppliedSpec` would never match the desired cluster `Spec`. The stored information contains the encryption configuration for secrets within etcd, and could potentially expose sensitive data if the etcd database was exposed directly. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
| [CVE-2023-32196](https://github.com/rancher/rancher/security/advisories/GHSA-64jq-m7rq-768h) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where the webhook rule resolver ignores rules from a `ClusterRole` for an external `RoleTemplate` set with `.context=project` or `.context=""`. This allows a user to create an external `ClusterRole` with `.context=project` or `.context=""`, depending on the use of the new feature flag `external-rules` and backing `ClusterRole`. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
| [CVE-2023-22650](https://github.com/rancher/rancher/security/advisories/GHSA-9ghh-mmcq-8phc) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where Rancher did not have a user retention process for when external authentication providers are used, that could be configured to run periodically and disable and/or delete inactive users. The new user retention process added in Rancher v2.8.5 and Rancher v2.7.14 is disabled by default. If enabled, a user becomes subject to the retention process if they don't log in for a configurable period of time. It's possible to set overrides for user accounts that are primarily intended for programmatic access (e.g. CI, scripts, etc.) so that they don't become subject to the retention process for a longer period of time or at all. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
| [CVE-2023-32191](https://github.com/rancher/rke/security/advisories/GHSA-6gr4-52w6-vmqx) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, in which supported RKE versions store credentials inside a ConfigMap that can be accessible by non-administrative users in Rancher. This vulnerability only affects an RKE-provisioned cluster. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
| [CVE-2023-32193](https://github.com/rancher/norman/security/advisories/GHSA-r8f4-hv23-6qp6) | 在 Rancher 2.6.13、2.7.9 和 2.8.1 及之前的版本中发现了一个问题。多个 Cross-Site Scripting (XSS) 漏洞可通过 Rancher UI (Norman) 进行利用。 | 2024 年 2 月 8 日 | Rancher [v2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2)、[v2.7.10](https://github.com/rancher/rancher/releases/tag/v2.7.10) 和 [v2.6.14](https://github.com/rancher/rancher/releases/tag/v2.6.14) |
|
||||
| [CVE-2023-32192](https://github.com/rancher/apiserver/security/advisories/GHSA-833m-37f7-jq55) | 在 Rancher 2.6.13、2.7.9 和 2.8.1 及之前的版本中发现了一个问题。多个 Cross-Site Scripting (XSS) 漏洞,可以通过 Rancher UI (Apiserver) 进行利用 | 2024 年 2 月 8 日 | Rancher [v2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2)、[v2.7.10](https://github.com/rancher/rancher/releases/tag/v2.7.10) 和 [v2.6.14](https://github.com/rancher/rancher/releases/tag/v2.6.14) |
|
||||
| [CVE-2023-22649](https://github.com/rancher/rancher/security/advisories/GHSA-xfj7-qf8w-2gcr) | 在 Rancher 2.6.13、2.7.9 和 2.8.1 及之前的版本中发现了一个问题。敏感数据可能会泄漏到 Rancher 的审计日志中。 | 2024 年 2 月 8 日 | Rancher [v2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2)、[v2.7.10](https://github.com/rancher/rancher/releases/tag/v2.7.10) 和 [v2.6.14](https://github.com/rancher/rancher/releases/tag/v2.6.14) |
|
||||
|
||||
+6
@@ -14,6 +14,7 @@ title: 功能开关
|
||||
|
||||
以下是 Rancher 中可用的功能开关列表。如果你是从旧 Rancher 版本升级的,你可能会在 Rancher UI 中看到其他功能,例如 `proxy` 或 `dashboard`(均[已中断](/versioned_docs/version-2.5/reference-guides/installation-references/feature-flags.md)):
|
||||
|
||||
- `clean-stale-secrets`: Removes stale secrets from the `cattle-impersonation-system` namespace. This slowly cleans up old secrets which are no longer being used by the impersonation system.
|
||||
- `continuous-delivery`:允许从 Fleet 中单独禁用 Fleet GitOps。有关详细信息,请参阅[持续交付](../../../how-to-guides/advanced-user-guides/enable-experimental-features/continuous-delivery.md)。
|
||||
- `fleet`:v2.6 及更高版本的 Rancher 配置框架需要 Fleet。即使你在旧 Rancher 版本中禁用了该标志,该标志也将在升级时自动启用。有关详细信息,请参阅 [Fleet - GitOps at Scale](../../../integrations-in-rancher/fleet/fleet.md)。
|
||||
- `harvester`:管理 Virtualization Management 页面的访问。用户可以在该页面直接导航到 Harvester 集群并访问 Harvester UI。有关详细信息,请参阅 [Harvester 集成](../../../integrations-in-rancher/harvester/overview.md)。
|
||||
@@ -23,12 +24,15 @@ title: 功能开关
|
||||
- `rke1-custom-node-cleanup`:清除已删除的 RKE1 自定义节点。建议你启用此标志,以防止已删除的节点尝试重新加入集群。
|
||||
- `rke2`:启用配置 RKE2 集群。此标志默认启用。
|
||||
- `token-hashing`:启用令牌哈希。启用后,会使用 SHA256 算法对现有 Token 和所有新 Token 进行哈希处理。一旦对 Token 进行哈希处理,就无法撤消操作。此标志在启用后无法禁用。有关详细信息,请参阅 [API 令牌](../../../api/api-tokens.md#令牌哈希)。
|
||||
- `uiextension`: Enables UI extensions. This flag is enabled by default. Enabling or disabling the flag forces the Rancher pod to restart. The first time this flag is set to `true`, it creates a CRD and enables the controllers and endpoints necessary for the feature to work. If set to `false`, it disables the previously mentioned controllers and endpoints. Setting `uiextension` to `false` has no effect on the CRD -- it does not create a CRD if it does not yet exist, nor does it delete the CRD if it already exists.
|
||||
- `unsupported-storage-drivers`:允许启用非默认启用的存储提供程序和卷插件。有关详细信息,请参阅[允许使用不受支持的存储驱动程序](../../../how-to-guides/advanced-user-guides/enable-experimental-features/unsupported-storage-drivers.md)。
|
||||
- `ui-sql-cache`: Enables a SQLite-based cache for UI tables. See [UI Server-Side Pagination](../../../how-to-guides/advanced-user-guides/enable-experimental-features/ui-server-side-pagination.md) for more information.
|
||||
|
||||
下表介绍了 Rancher 中功能开关的可用性和默认值。标记为“GA”的功能已普遍可用:
|
||||
|
||||
| 功能开关名称 | 默认值 | 状态 | 可用于 |
|
||||
| ----------------------------- | ------------- | ------------ | --------------- |
|
||||
| `clean-stale-secrets` | `true` | GA | v2.10.2 | |
|
||||
| `continuous-delivery` | `true` | GA | v2.6.0 |
|
||||
| `fleet` | `true` | 不能禁用 | v2.6.0 |
|
||||
| `fleet` | `true` | GA | v2.5.0 |
|
||||
@@ -37,3 +41,5 @@ title: 功能开关
|
||||
| `rke1-custom-node-cleanup` | `true` | GA | v2.6.0 |
|
||||
| `rke2` | `true` | 实验功能 | v2.6.0 |
|
||||
| `token-hashing` | 新安装:`false`;升级:`true` | GA | v2.6.0 |
|
||||
| `uiextension` | `true` | GA | v2.9.0 | |
|
||||
| `ui-sql-cache` | `false` | Highly experimental | v2.9.0 | |
|
||||
|
||||
+4
@@ -188,3 +188,7 @@ openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout myservice.ke
|
||||
|
||||
* 检查你的 Keycloak 日志。
|
||||
* 如果日志显示 `request validation failed: org.keycloak.common.VerificationException: SigAlg was null`,请在 Keycloak 客户端中将 `Client Signature Required` 设为 `OFF`。
|
||||
|
||||
## Configuring SAML Single Logout (SLO)
|
||||
|
||||
<ConfigureSLO />
|
||||
|
||||
+4
@@ -105,3 +105,7 @@ OpenLDAP ServiceAccount 用于所有搜索。无论用户个人的 SAML 权限
|
||||
1. 在**用户和组搜索**下,选中**配置 OpenLDAP Server**。
|
||||
|
||||
如果你在测试与 OpenLDAP Server 的连接时遇到问题,请确保你输入了ServiceAccount 的凭证并正确配置了搜索库。你可以检查 Rancher 日志来查明根本原因。调试日志可能包含有关错误的更详细信息。请参阅[如何启用调试日志](../../../../faq/technical-items.md#如何启用调试日志记录)了解更多信息。
|
||||
|
||||
## Configuring SAML Single Logout (SLO)
|
||||
|
||||
<ConfigureSLO />
|
||||
|
||||
+4
@@ -60,3 +60,7 @@ title: 配置 PingIdentity (SAML)
|
||||
- 用户组下拉列表仅显示你所属的用户组。如果你不是某个组的成员,你将无法添加该组。
|
||||
|
||||
:::
|
||||
|
||||
## Configuring SAML Single Logout (SLO)
|
||||
|
||||
<ConfigureSLO />
|
||||
|
||||
+4
@@ -51,3 +51,7 @@ title: 2. 在 Rancher 中配置 Microsoft AD FS
|
||||
```
|
||||
openssl req -x509 -newkey rsa:2048 -keyout myservice.key -out myservice.cert -days 365 -nodes -subj "/CN=myservice.example.com"
|
||||
```
|
||||
|
||||
## Configuring SAML Single Logout (SLO)
|
||||
|
||||
<ConfigureSLO />
|
||||
|
||||
+4
@@ -76,6 +76,10 @@ SAML 协议不支持用户或用户组的搜索或查找。因此,如果你没
|
||||
|
||||
要在 Rancher 中分配权限时启用搜索组,你需要为 SAML 身份认证服务配置支持组的后端(例如 OpenLDAP)。
|
||||
|
||||
### Configuring SAML Single Logout (SLO)
|
||||
|
||||
<ConfigureSLO />
|
||||
|
||||
# 在 Rancher 中设置 OpenLDAP
|
||||
|
||||
如果你将 OpenLDAP 配置为 Shibboleth 的后端,SAML 断言会返回到 Rancher,其中包括用于引用组的用户属性。然后,通过认证的用户将能够访问其所在的组有权访问的 Rancher 资源。
|
||||
|
||||
+1
-1
@@ -9,7 +9,7 @@ PSS 定义了工作负载的安全级别。PSA 描述了 Pod 安全上下文和
|
||||
|
||||
## 升级到 Pod 安全标准 (PSS)
|
||||
|
||||
确保将所有 PSP 都迁移到了另一个工作负载安全机制,包括将你当前的 PSP 映射到 Pod 安全标准,以便使用 [PSA 控制器](https://kubernetes.io/docs/concepts/security/pod-security-admission/)执行。如果 PSA 控制器不能满足企业的所有需求,建议你使用策略引擎,例如 [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper)、[Kubewarden](https://www.kubewarden.io/)、[Kyverno](https://kyverno.io/) 或 [NeuVector](https://neuvector.com/)。有关如何迁移 PSP 的更多信息,请参阅你选择的策略引擎的文档。
|
||||
确保将所有 PSP 都迁移到了另一个工作负载安全机制,包括将你当前的 PSP 映射到 Pod 安全标准,以便使用 [PSA 控制器](https://kubernetes.io/docs/concepts/security/pod-security-admission/)执行。如果 PSA 控制器不能满足企业的所有需求,建议你使用策略引擎,例如 [Kubewarden](https://www.kubewarden.io/)、[Kyverno](https://kyverno.io/) 或 [NeuVector](https://neuvector.com/)。有关如何迁移 PSP 的更多信息,请参阅你选择的策略引擎的文档。
|
||||
|
||||
:::caution
|
||||
必须在删除 PodSecurityPolicy 对象_之前_添加新的策略执行机制。否则,你可能会为集群内的特权升级攻击创造机会。
|
||||
|
||||
+46
@@ -161,10 +161,56 @@ spec:
|
||||
|
||||
:::
|
||||
|
||||
### Add Custom OCI Chart Repositories
|
||||
|
||||
:::caution
|
||||
|
||||
This feature is currently experimental and is not officially supported in Rancher.
|
||||
|
||||
:::
|
||||
|
||||
Helm v3 introduced storing Helm charts as [Open Container Initiative (OCI)](https://opencontainers.org/about/overview/) artifacts in container registries. With Rancher v2.9.0, you can add [OCI-based Helm chart repositories](https://helm.sh/docs/topics/registries/) alongside HTTP-based and Git-based repositories. This means you can deploy apps that are stored as OCI artifacts. For more information, see [Using OCI Helm Chart Repositories](./oci-repositories.md).
|
||||
|
||||
### Helm 兼容性
|
||||
|
||||
仅支持 Helm 3 兼容 Chart 。
|
||||
|
||||
#### Refresh Interval
|
||||
|
||||
Rancher v2.10.0 adds the `refreshInterval` field to the `ClusterRepo` CRD. The default value is 3600 seconds, meaning that Rancher syncs each Helm repository every 3600 seconds.
|
||||
|
||||
To modify the refresh interval of a chart repository:
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
|
||||
1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.
|
||||
1. Find the repository you want to modify, and click **⋮ > Edit YAML**.
|
||||
1. Set the **refreshInterval** field under **Spec** to the desired value in seconds.
|
||||
1. Click **Save**.
|
||||
|
||||
### Enable/Disable Helm Chart Repositories
|
||||
|
||||
Rancher v2.10.0 adds the ability to enable and disable Helm repositories. Helm repositories are enabled by default.
|
||||
|
||||
To disable a chart repository:
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
|
||||
1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.
|
||||
1. Find the repository you want to disable, and click **⋮ > Edit YAML**.
|
||||
1. Set the **Enabled** field under **Spec** to **false**.
|
||||
1. Click **Save**.
|
||||
1. When you disable a repository, updates are disabled and new changes to the clusterRepo are not applied.
|
||||
|
||||
To enable a chart repository:
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
|
||||
1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.
|
||||
1. Find the repository you want to disable, and click **⋮ > Edit YAML**.
|
||||
1. Set the **Enabled** field under **Spec** to **true**.
|
||||
1. Click **Save**.
|
||||
|
||||
### 部署和升级 Chart
|
||||
|
||||
安装和部署 chart:
|
||||
|
||||
-2
@@ -19,7 +19,5 @@ Rancher Server 的数据存储在 etcd 中。etcd 数据库可以在所有三个
|
||||
- Ingress Controller 会把 HTTP 重定向到 HTTPS,在 TCP/443 端口终结 SSL/TLS。
|
||||
- Ingress Controller 会把流量转发到 Rancher deployment 的 Pod 上的 TCP/80 端口。
|
||||
|
||||
<figcaption>使用 4 层负载均衡器在 Kubernetes 集群中安装 Rancher:Ingress Controller 的 SSL 终止:</figcaption>
|
||||
|
||||

|
||||
<sup>使用 4 层负载均衡器在 Kubernetes 集群中安装 Rancher:Ingress Controller 的 SSL 终止</sup>
|
||||
|
||||
-1
@@ -31,6 +31,5 @@ Rancher 包含 Kubernetes 中未包含的各种工具来协助你进行 DevOps
|
||||
- Logging
|
||||
- Monitoring
|
||||
- Istio 服务网格
|
||||
- OPA Gatekeeper
|
||||
|
||||
你可以通过 **Apps** 来安装工具。
|
||||
|
||||
+1
-7
@@ -15,13 +15,7 @@ title: 安装 Adapter
|
||||
|
||||
| Rancher 版本 | Adapter 版本 |
|
||||
|-----------------|:---------------:|
|
||||
| v2.7.0 | v2.0.0 |
|
||||
| v2.7.1 | v2.0.0 |
|
||||
| v2.7.2 | v2.0.1 |
|
||||
| v2.7.3 | v2.0.1 |
|
||||
| v2.7.4 | v2.0.1 |
|
||||
| v2.7.5 | v2.0.2 |
|
||||
|
||||
| v2.10.0 | v5.0.1 |
|
||||
|
||||
## 1. 获取对 Local 集群的访问权限
|
||||
|
||||
|
||||
-3
@@ -56,9 +56,6 @@ PrometheusRule 用于定义指标或时间序列数据库查询触发告警的
|
||||
|
||||
- 路由和接收器也通过 Alertmanager Secret 存储在 Kubernetes API 中。当 Secret 更新时,Alertmanager 也会自动更新。请注意,路由仅通过标签发生(而不是通过注释等)。
|
||||
|
||||
<figcaption>数据如何流经 Monitoring 应用程序</figcaption>
|
||||
|
||||
|
||||
## 2. Prometheus 的工作原理
|
||||
|
||||
### 存储时间序列数据
|
||||
|
||||
-111
@@ -1,111 +0,0 @@
|
||||
---
|
||||
title: OPA Gatekeeper
|
||||
---
|
||||
|
||||
为了确保一致性和合规性,每个组织都需要能够以自动化的方式在环境中定义和执行策略。[OPA(Open Policy Agent)](https://www.openpolicyagent.org/) 是一个策略引擎,用于基于策略控制云原生环境。Rancher 支持在 Kubernetes 集群中启用 OPA Gatekeeper,并且还安装了一些内置的策略定义(也称为约束模板)。
|
||||
|
||||
OPA 提供了一种高级声明性语言,可以让你将策略指定为代码,还能扩展简单的 API,从而减轻策略决策的负担。
|
||||
|
||||
[OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper) 是一个提供 OPA 和 Kubernetes 集成的项目。OPA Gatekeeper 提供:
|
||||
|
||||
- 一个可扩展的参数化策略库。
|
||||
- 用于实例化策略库的原生 Kubernetes CRD,也称为“约束”。
|
||||
- 用于扩展策略库的原生 Kubernetes CRD,也称为“约束模板”。
|
||||
- 审计功能。
|
||||
|
||||
要了解更多关于 OPA 的信息,请参阅[官方文档](https://www.openpolicyagent.org/docs/latest/)。
|
||||
|
||||
## OPA Gatekeeper 集成的工作原理
|
||||
|
||||
Kubernetes 支持通过准入控制器(准入控制器)webhook 来扩展 API Server 的功能,创建、更新或删除资源时都会调用这些 webhook。Gatekeeper 作为验证 webhook 安装,并执行由 Kubernetes CRD(Custom Resource Definition)定义的策略。除了使用准入控制之外,Gatekeeper 还能审计 Kubernetes 集群中的现有资源,并对违反当前策略的情况进行标记。
|
||||
|
||||
OPA Gatekeeper 由 Rancher 的 Helm system Chart 提供,它安装在名为 `gatekeeper-system` 的命名空间中。
|
||||
|
||||
## 在集群中启用 OPA Gatekeeper
|
||||
|
||||
:::note
|
||||
|
||||
Rancher 2.5 改进了 OPA Gatekeeper 应用。无法从 Rancher 2.4 升级到 Rancher 2.5 中的新版本。如果你在 Rancher 2.4 中安装了 OPA Gatekeeper,则需要在旧 UI 中卸载 OPA Gatekeeper 及其 CRD,然后在 Rancher 2.5 中重新安装它。如需卸载 CRD,请在 kubectl 控制台中运行 `kubectl delete crd configs.config.gatekeeper.sh constrainttemplates.templates.gatekeeper.sh` 命令。
|
||||
|
||||
:::
|
||||
|
||||
:::note 先决条件:
|
||||
|
||||
只有管理员和集群所有者才能启用 OPA Gatekeeper。
|
||||
|
||||
:::
|
||||
|
||||
你可以在 **Apps** 页面安装 OPA Gatekeeper Helm Chart。
|
||||
|
||||
### 启用 OPA Gatekeeper
|
||||
|
||||
1. 在左上角,单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面中,转到要启用 OPA Gatekeeper 的集群,然后单击 **Explore**。
|
||||
1. 在左侧导航栏中,点击 **Apps**。
|
||||
1. 点击 **Charts** 并点击 **OPA Gatekeeper**。
|
||||
1. 单击**安装**。
|
||||
|
||||
**结果**:已将 OPA Gatekeeper 部署到你的 Kubernetes 集群。
|
||||
|
||||
## 约束模板
|
||||
|
||||
[约束模板](https://github.com/open-policy-agent/gatekeeper#constraint-templates)是 Kubernetes 自定义资源,用于定义要由 Gatekeeper 应用的 OPA 策略的架构和 Rego 逻辑。有关 Rego 策略语言的更多信息,请参阅[官方文档](https://www.openpolicyagent.org/docs/latest/policy-language/)。
|
||||
|
||||
启用 OPA Gatekeeper 后,Rancher 默认会安装一些模板。
|
||||
|
||||
要列出集群中安装的约束模板,请转到 OPA Gatekeeper 下的左侧菜单,然后单击**模板**。
|
||||
|
||||
Rancher 还支持通过导入 YAML 定义来创建你自己的约束模板。
|
||||
|
||||
## 创建和配置约束
|
||||
|
||||
[约束](https://github.com/open-policy-agent/gatekeeper#constraints)是 Kubernetes 自定义资源,用于定义要应用约束模板的对象范围。约束模板和约束共同定义一个完整的策略。
|
||||
|
||||
:::note 先决条件:
|
||||
|
||||
集群中已启用 OPA Gatekeeper。
|
||||
|
||||
:::
|
||||
|
||||
要列出已安装的约束,请转到 OPA Gatekeeper 下的左侧菜单,然后单击**约束**。
|
||||
|
||||
可以从约束模板创建新的约束。
|
||||
|
||||
Rancher 支持通过使用方便的表单来创建约束,你可以在该表单中输入各种约束字段。
|
||||
|
||||
**以 YAML 文件编辑**选项也可以用于配置约束的 YAML 定义。
|
||||
|
||||
### 使 Rancher 的 System 命名空间不受约束
|
||||
|
||||
创建约束时,请确保该约束不应用于任何 Rancher 或 Kubernetes System 命名空间。如果不排除 System 命名空间,则可能会出现 system 命名空间下的许多资源被标记为违反约束。
|
||||
|
||||
要让约束仅限制用户命名空间,请在约束的**匹配**字段下指定这些命名空间。
|
||||
|
||||
此外,该约束可能会干扰其他 Rancher 功能并拒绝部署系统工作负载。为避免这种情况,请从你的约束中排除所有 Rancher 特定的命名空间。
|
||||
|
||||
## 在集群中实施约束
|
||||
|
||||
如果**执行动作**为 **Deny**,约束会立即启用,并拒绝任何违反策略的请求。默认情况下,执行的值为 **Deny**。
|
||||
|
||||
如果**执行动作** 为 **Dryrun**,违反策略的资源仅会记录在约束的状态字段中。
|
||||
|
||||
要强制执行约束,请使用表单创建约束。在**执行动作**字段中,选择 **Deny**。
|
||||
|
||||
## 集群中的审计和违规
|
||||
|
||||
OPA Gatekeeper 运行定期审计,以检查现有资源是否违反强制执行的约束。你可以在安装 Gatekeeper 时配置审计间隔(默认 300 秒)。
|
||||
|
||||
Gatekeeper 页面上列出了违反已定义的约束的情况。
|
||||
|
||||
此外,你也可以在**约束**页面中找到违反约束的数量。
|
||||
|
||||
每个约束的详细信息视图列出了违反约束的资源的信息。
|
||||
|
||||
## 禁用 Gatekeeper
|
||||
|
||||
1. 导航到集群的仪表板视图。
|
||||
1. 在左侧菜单中,展开集群菜单并单击 **OPA Gatekeeper**。
|
||||
1. 单击 **⋮ > 禁用**。
|
||||
|
||||
**结果**:禁用 OPA Gatekeeper 后,所有约束模板和约束也将被删除。
|
||||
|
||||
+1
-4
@@ -4,7 +4,6 @@ title: 集群工具:Logging,Monitoring 和可视化
|
||||
|
||||
Rancher 包含 Kubernetes 中未包含的各种工具来协助你进行 DevOps 操作。Rancher 可以与外部服务集成,让你的集群更高效地运行。工具分为以下几类:
|
||||
|
||||
|
||||
## Logging
|
||||
|
||||
Logging 支持:
|
||||
@@ -18,6 +17,7 @@ Logging 支持:
|
||||
Rancher 可以与 Elasticsearch、splunk、kafka、syslog 和 fluentd 集成。
|
||||
|
||||
有关详细信息,请参阅 [Logging 文档](../integrations-in-rancher/logging/logging.md)。
|
||||
|
||||
## 监控和告警
|
||||
|
||||
你可以使用 Rancher,通过业界领先并开源的 [Prometheus](https://prometheus.io/) 来监控集群节点、Kubernetes 组件和软件部署的状态和进程。
|
||||
@@ -37,9 +37,6 @@ Rancher 可以与 Elasticsearch、splunk、kafka、syslog 和 fluentd 集成。
|
||||
Rancher v2.5 改进了与 Istio 的集成。
|
||||
|
||||
如需更多信息,请参阅 [Istio 文档](..//integrations-in-rancher/istio/istio.md)。
|
||||
## OPA Gatekeeper
|
||||
|
||||
[OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper) 是一个开源项目,它对 OPA 和 Kubernetes 进行了集成,以通过许可控制器 Webhook 提供策略控制。有关如何在 Rancher 中启用 Gatekeeper 的详细信息,请参阅 [OPA Gatekeeper](../integrations-in-rancher/opa-gatekeeper.md)。
|
||||
|
||||
## CIS 扫描
|
||||
|
||||
|
||||
+10
-1
@@ -10,7 +10,16 @@ Rancher 致力于向社区披露我们产品的安全问题。我们会针对已
|
||||
|
||||
| ID | 描述 | 日期 | 解决 |
|
||||
|----|-------------|------|------------|
|
||||
| [CVE-2024-22030](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-22030) | 发现了 Rancher 和 Fleet 代理的一个漏洞,目前被认为是中到高危的 CVE。在非特定情况下,这个漏洞允许恶意行为者接管现有的 Rancher 节点。攻击者需要控制一个过期的域名,或者对该域名执行 DNS 欺骗/劫持攻击才可以利用此漏洞。被攻击的域名是 Rancher URL(用作 Rancher 集群的 server-url)。目前还没有可用的修复方案,它影响所有受支持的 Rancher 版本。建议客户和用户遵循我们[博客文章](https://www.suse.com/c/rancher-security-update/)中描述的建议和最佳实践。 | 2024 年 2 月 16 日 | 处理中 |
|
||||
| [CVE-2024-52281](https://github.com/rancher/rancher/security/advisories/GHSA-2v2w-8v8c-wcm9) | A high severity vulnerability was identified within the Rancher UI that allows a malicious actor to perform a Stored XSS attack through the cluster description field. | 15 Jan 2025 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) |
|
||||
| [CVE-2024-52282](https://github.com/rancher/rancher/security/advisories/GHSA-9c5p-35gj-jqp4) | A medium severity vulnerability was discovered within Rancher Manager whereby applications installed via Rancher Manager Apps Catalog store their Helm values directly into the Apps Custom Resource Definition, resulting in any users with GET access to it to be able to read any sensitive information that are contained within the Apps’ values. Additionally, the same information leaks into auditing logs when the audit level is set to equal or above 2. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 19 Nov 2024 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.8.10](https://github.com/rancher/rancher/releases/tag/v2.8.10). |
|
||||
| [CVE-2024-22036](https://github.com/rancher/rancher/security/advisories/GHSA-h99m-6755-rgwc) | A critical severity vulnerability was discovered within Rancher where a cluster or node driver can be used to escape the `chroot` jail and gain root access to the Rancher container itself. In production environments, further privilege escalation is possible based on living off the land within the Rancher container itself. For test and development environments, based on a –privileged Docker container, it is possible to escape the Docker container and gain execution access on the host system. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3), [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) and [v2.7.16](https://github.com/rancher/rancher/releases/tag/v2.7.16) |
|
||||
| [CVE-2023-32197](https://github.com/rancher/rancher/security/advisories/GHSA-7h8m-pvw3-5gh4) | A critical severity vulnerability was discovered whereby Rancher Manager deployments containing Windows nodes have weak Access Control Lists (ACL), allowing `BUILTIN\Users` or `NT AUTHORITY\Authenticated Users` to view or edit sensitive files which could lead to privilege escalation. This vulnerability is exclusive to deployments that contain Windows nodes. Linux-only environments are not affected by it. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) |
|
||||
| [CVE-2022-45157](https://github.com/rancher/rancher/security/advisories/GHSA-xj7w-r753-vj8v) | A critical severity vulnerability was discovered in the way that Rancher stores vSphere's CPI (Cloud Provider Interface) and CSI (Container Storage Interface) credentials used to deploy clusters through the vSphere cloud provider. This issue leads to the vSphere CPI and CSI passwords being stored in a plaintext object inside Rancher. This vulnerability is only applicable to users that deploy clusters in vSphere environments. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) |
|
||||
| [CVE-2024-22030](https://github.com/rancher/rancher/security/advisories/GHSA-h4h5-9833-v2p4) | 发现了 Rancher 和 Fleet 代理的一个漏洞,目前被认为是中到高危的 CVE。在非特定情况下,这个漏洞允许恶意行为者接管现有的 Rancher 节点。攻击者需要控制一个过期的域名,或者对该域名执行 DNS 欺骗/劫持攻击才可以利用此漏洞。被攻击的域名是 Rancher URL(用作 Rancher 集群的 server-url)。目前还没有可用的修复方案,它影响所有受支持的 Rancher 版本。建议客户和用户遵循我们[博客文章](https://www.suse.com/c/rancher-security-update/)中描述的建议和最佳实践。 | 2024 年 9 月 19 日 | 处理中 |
|
||||
| [CVE-2024-22032](https://github.com/rancher/rancher/security/advisories/GHSA-q6c7-56cq-g2wm) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where custom secrets encryption configurations are stored in plaintext under the clusters `AppliedSpec`. This also causes clusters to continuously reconcile, as the `AppliedSpec` would never match the desired cluster `Spec`. The stored information contains the encryption configuration for secrets within etcd, and could potentially expose sensitive data if the etcd database was exposed directly. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
| [CVE-2023-32196](https://github.com/rancher/rancher/security/advisories/GHSA-64jq-m7rq-768h) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where the webhook rule resolver ignores rules from a `ClusterRole` for an external `RoleTemplate` set with `.context=project` or `.context=""`. This allows a user to create an external `ClusterRole` with `.context=project` or `.context=""`, depending on the use of the new feature flag `external-rules` and backing `ClusterRole`. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
| [CVE-2023-22650](https://github.com/rancher/rancher/security/advisories/GHSA-9ghh-mmcq-8phc) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where Rancher did not have a user retention process for when external authentication providers are used, that could be configured to run periodically and disable and/or delete inactive users. The new user retention process added in Rancher v2.8.5 and Rancher v2.7.14 is disabled by default. If enabled, a user becomes subject to the retention process if they don't log in for a configurable period of time. It's possible to set overrides for user accounts that are primarily intended for programmatic access (e.g. CI, scripts, etc.) so that they don't become subject to the retention process for a longer period of time or at all. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
| [CVE-2023-32191](https://github.com/rancher/rke/security/advisories/GHSA-6gr4-52w6-vmqx) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, in which supported RKE versions store credentials inside a ConfigMap that can be accessible by non-administrative users in Rancher. This vulnerability only affects an RKE-provisioned cluster. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
| [CVE-2023-32193](https://github.com/rancher/norman/security/advisories/GHSA-r8f4-hv23-6qp6) | 在 Rancher 2.6.13、2.7.9 和 2.8.1 及之前的版本中发现了一个问题。多个 Cross-Site Scripting (XSS) 漏洞可通过 Rancher UI (Norman) 进行利用。 | 2024 年 2 月 8 日 | Rancher [v2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2)、[v2.7.10](https://github.com/rancher/rancher/releases/tag/v2.7.10) 和 [v2.6.14](https://github.com/rancher/rancher/releases/tag/v2.6.14) |
|
||||
| [CVE-2023-32192](https://github.com/rancher/apiserver/security/advisories/GHSA-833m-37f7-jq55) | 在 Rancher 2.6.13、2.7.9 和 2.8.1 及之前的版本中发现了一个问题。多个 Cross-Site Scripting (XSS) 漏洞,可以通过 Rancher UI (Apiserver) 进行利用 | 2024 年 2 月 8 日 | Rancher [v2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2)、[v2.7.10](https://github.com/rancher/rancher/releases/tag/v2.7.10) 和 [v2.6.14](https://github.com/rancher/rancher/releases/tag/v2.6.14) |
|
||||
| [CVE-2023-22649](https://github.com/rancher/rancher/security/advisories/GHSA-xfj7-qf8w-2gcr) | 在 Rancher 2.6.13、2.7.9 和 2.8.1 及之前的版本中发现了一个问题。敏感数据可能会泄漏到 Rancher 的审计日志中。 | 2024 年 2 月 8 日 | Rancher [v2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2)、[v2.7.10](https://github.com/rancher/rancher/releases/tag/v2.7.10) 和 [v2.6.14](https://github.com/rancher/rancher/releases/tag/v2.6.14) |
|
||||
|
||||
-2
@@ -19,7 +19,5 @@ Rancher Server 的数据存储在 etcd 中。etcd 数据库可以在所有三个
|
||||
- Ingress Controller 会把 HTTP 重定向到 HTTPS,在 TCP/443 端口终结 SSL/TLS。
|
||||
- Ingress Controller 会把流量转发到 Rancher deployment 的 Pod 上的 TCP/80 端口。
|
||||
|
||||
<figcaption>使用 4 层负载均衡器在 Kubernetes 集群中安装 Rancher:Ingress Controller 的 SSL 终止:</figcaption>
|
||||
|
||||

|
||||
<sup>使用 4 层负载均衡器在 Kubernetes 集群中安装 Rancher:Ingress Controller 的 SSL 终止</sup>
|
||||
|
||||
-3
@@ -56,9 +56,6 @@ PrometheusRule 用于定义指标或时间序列数据库查询触发告警的
|
||||
|
||||
- 路由和接收器也通过 Alertmanager Secret 存储在 Kubernetes API 中。当 Secret 更新时,Alertmanager 也会自动更新。请注意,路由仅通过标签发生(而不是通过注释等)。
|
||||
|
||||
<figcaption>数据如何流经 Monitoring 应用程序</figcaption>
|
||||
|
||||
|
||||
## 2. Prometheus 的工作原理
|
||||
|
||||
### 存储时间序列数据
|
||||
|
||||
-2
@@ -19,7 +19,5 @@ Rancher Server 的数据存储在 etcd 中。etcd 数据库可以在所有三个
|
||||
- Ingress Controller 会把 HTTP 重定向到 HTTPS,在 TCP/443 端口终结 SSL/TLS。
|
||||
- Ingress Controller 会把流量转发到 Rancher deployment 的 Pod 上的 TCP/80 端口。
|
||||
|
||||
<figcaption>使用 4 层负载均衡器在 Kubernetes 集群中安装 Rancher:Ingress Controller 的 SSL 终止:</figcaption>
|
||||
|
||||

|
||||
<sup>使用 4 层负载均衡器在 Kubernetes 集群中安装 Rancher:Ingress Controller 的 SSL 终止</sup>
|
||||
|
||||
-3
@@ -56,9 +56,6 @@ PrometheusRule 用于定义指标或时间序列数据库查询触发告警的
|
||||
|
||||
- 路由和接收器也通过 Alertmanager Secret 存储在 Kubernetes API 中。当 Secret 更新时,Alertmanager 也会自动更新。请注意,路由仅通过标签发生(而不是通过注释等)。
|
||||
|
||||
<figcaption>数据如何流经 Monitoring 应用程序</figcaption>
|
||||
|
||||
|
||||
## 2. Prometheus 的工作原理
|
||||
|
||||
### 存储时间序列数据
|
||||
|
||||
+10
@@ -10,6 +10,16 @@ Rancher 致力于向社区披露我们产品的安全问题。我们会针对已
|
||||
|
||||
| ID | 描述 | 日期 | 解决 |
|
||||
|----|-------------|------|------------|
|
||||
| [CVE-2024-52281](https://github.com/rancher/rancher/security/advisories/GHSA-2v2w-8v8c-wcm9) | A high severity vulnerability was identified within the Rancher UI that allows a malicious actor to perform a Stored XSS attack through the cluster description field. | 15 Jan 2025 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) |
|
||||
| [CVE-2024-52282](https://github.com/rancher/rancher/security/advisories/GHSA-9c5p-35gj-jqp4) | A medium severity vulnerability was discovered within Rancher Manager whereby applications installed via Rancher Manager Apps Catalog store their Helm values directly into the Apps Custom Resource Definition, resulting in any users with GET access to it to be able to read any sensitive information that are contained within the Apps’ values. Additionally, the same information leaks into auditing logs when the audit level is set to equal or above 2. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 19 Nov 2024 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.8.10](https://github.com/rancher/rancher/releases/tag/v2.8.10). |
|
||||
| [CVE-2024-22036](https://github.com/rancher/rancher/security/advisories/GHSA-h99m-6755-rgwc) | A critical severity vulnerability was discovered within Rancher where a cluster or node driver can be used to escape the `chroot` jail and gain root access to the Rancher container itself. In production environments, further privilege escalation is possible based on living off the land within the Rancher container itself. For test and development environments, based on a –privileged Docker container, it is possible to escape the Docker container and gain execution access on the host system. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3), [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) and [v2.7.16](https://github.com/rancher/rancher/releases/tag/v2.7.16) |
|
||||
| [CVE-2023-32197](https://github.com/rancher/rancher/security/advisories/GHSA-7h8m-pvw3-5gh4) | A critical severity vulnerability was discovered whereby Rancher Manager deployments containing Windows nodes have weak Access Control Lists (ACL), allowing `BUILTIN\Users` or `NT AUTHORITY\Authenticated Users` to view or edit sensitive files which could lead to privilege escalation. This vulnerability is exclusive to deployments that contain Windows nodes. Linux-only environments are not affected by it. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) |
|
||||
| [CVE-2022-45157](https://github.com/rancher/rancher/security/advisories/GHSA-xj7w-r753-vj8v) | A critical severity vulnerability was discovered in the way that Rancher stores vSphere's CPI (Cloud Provider Interface) and CSI (Container Storage Interface) credentials used to deploy clusters through the vSphere cloud provider. This issue leads to the vSphere CPI and CSI passwords being stored in a plaintext object inside Rancher. This vulnerability is only applicable to users that deploy clusters in vSphere environments. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) |
|
||||
| [CVE-2024-22030](https://github.com/rancher/rancher/security/advisories/GHSA-h4h5-9833-v2p4) | 发现了 Rancher 和 Fleet 代理的一个漏洞,目前被认为是中到高危的 CVE。在非特定情况下,这个漏洞允许恶意行为者接管现有的 Rancher 节点。攻击者需要控制一个过期的域名,或者对该域名执行 DNS 欺骗/劫持攻击才可以利用此漏洞。被攻击的域名是 Rancher URL(用作 Rancher 集群的 server-url)。目前还没有可用的修复方案,它影响所有受支持的 Rancher 版本。建议客户和用户遵循我们[博客文章](https://www.suse.com/c/rancher-security-update/)中描述的建议和最佳实践。 | 2024 年 9 月 19 日 | 处理中 |
|
||||
| [CVE-2024-22032](https://github.com/rancher/rancher/security/advisories/GHSA-q6c7-56cq-g2wm) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where custom secrets encryption configurations are stored in plaintext under the clusters `AppliedSpec`. This also causes clusters to continuously reconcile, as the `AppliedSpec` would never match the desired cluster `Spec`. The stored information contains the encryption configuration for secrets within etcd, and could potentially expose sensitive data if the etcd database was exposed directly. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
| [CVE-2023-32196](https://github.com/rancher/rancher/security/advisories/GHSA-64jq-m7rq-768h) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where the webhook rule resolver ignores rules from a `ClusterRole` for an external `RoleTemplate` set with `.context=project` or `.context=""`. This allows a user to create an external `ClusterRole` with `.context=project` or `.context=""`, depending on the use of the new feature flag `external-rules` and backing `ClusterRole`. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
| [CVE-2023-22650](https://github.com/rancher/rancher/security/advisories/GHSA-9ghh-mmcq-8phc) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where Rancher did not have a user retention process for when external authentication providers are used, that could be configured to run periodically and disable and/or delete inactive users. The new user retention process added in Rancher v2.8.5 and Rancher v2.7.14 is disabled by default. If enabled, a user becomes subject to the retention process if they don't log in for a configurable period of time. It's possible to set overrides for user accounts that are primarily intended for programmatic access (e.g. CI, scripts, etc.) so that they don't become subject to the retention process for a longer period of time or at all. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
| [CVE-2023-32191](https://github.com/rancher/rke/security/advisories/GHSA-6gr4-52w6-vmqx) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, in which supported RKE versions store credentials inside a ConfigMap that can be accessible by non-administrative users in Rancher. This vulnerability only affects an RKE-provisioned cluster. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
| [CVE-2023-32193](https://github.com/rancher/norman/security/advisories/GHSA-r8f4-hv23-6qp6) | 在 Rancher 2.6.13、2.7.9 和 2.8.1 及之前的版本中发现了一个问题。多个 Cross-Site Scripting (XSS) 漏洞可通过 Rancher UI (Norman) 进行利用。 | 2024 年 2 月 8 日 | Rancher [v2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2)、[v2.7.10](https://github.com/rancher/rancher/releases/tag/v2.7.10) 和 [v2.6.14](https://github.com/rancher/rancher/releases/tag/v2.6.14) |
|
||||
| [CVE-2023-32192](https://github.com/rancher/apiserver/security/advisories/GHSA-833m-37f7-jq55) | 在 Rancher 2.6.13、2.7.9 和 2.8.1 及之前的版本中发现了一个问题。多个 Cross-Site Scripting (XSS) 漏洞,可以通过 Rancher UI (Apiserver) 进行利用 | 2024 年 2 月 8 日 | Rancher [v2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2)、[v2.7.10](https://github.com/rancher/rancher/releases/tag/v2.7.10) 和 [v2.6.14](https://github.com/rancher/rancher/releases/tag/v2.6.14) |
|
||||
| [CVE-2023-22649](https://github.com/rancher/rancher/security/advisories/GHSA-xfj7-qf8w-2gcr) | 在 Rancher 2.6.13、2.7.9 和 2.8.1 及之前的版本中发现了一个问题。敏感数据可能会泄漏到 Rancher 的审计日志中。 | 2024 年 2 月 8 日 | Rancher [v2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2)、[v2.7.10](https://github.com/rancher/rancher/releases/tag/v2.7.10) 和 [v2.6.14](https://github.com/rancher/rancher/releases/tag/v2.6.14) |
|
||||
|
||||
-2
@@ -19,7 +19,5 @@ Rancher Server 的数据存储在 etcd 中。etcd 数据库可以在所有三个
|
||||
- Ingress Controller 会把 HTTP 重定向到 HTTPS,在 TCP/443 端口终结 SSL/TLS。
|
||||
- Ingress Controller 会把流量转发到 Rancher deployment 的 Pod 上的 TCP/80 端口。
|
||||
|
||||
<figcaption>使用 4 层负载均衡器在 Kubernetes 集群中安装 Rancher:Ingress Controller 的 SSL 终止:</figcaption>
|
||||
|
||||

|
||||
<sup>使用 4 层负载均衡器在 Kubernetes 集群中安装 Rancher:Ingress Controller 的 SSL 终止</sup>
|
||||
|
||||
-3
@@ -56,9 +56,6 @@ PrometheusRule 用于定义指标或时间序列数据库查询触发告警的
|
||||
|
||||
- 路由和接收器也通过 Alertmanager Secret 存储在 Kubernetes API 中。当 Secret 更新时,Alertmanager 也会自动更新。请注意,路由仅通过标签发生(而不是通过注释等)。
|
||||
|
||||
<figcaption>数据如何流经 Monitoring 应用程序</figcaption>
|
||||
|
||||
|
||||
## 2. Prometheus 的工作原理
|
||||
|
||||
### 存储时间序列数据
|
||||
|
||||
+10
-1
@@ -10,7 +10,16 @@ Rancher 致力于向社区披露我们产品的安全问题。我们会针对已
|
||||
|
||||
| ID | 描述 | 日期 | 解决 |
|
||||
|----|-------------|------|------------|
|
||||
| [CVE-2024-22030](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-22030) | 发现了 Rancher 和 Fleet 代理的一个漏洞,目前被认为是中到高危的 CVE。在非特定情况下,这个漏洞允许恶意行为者接管现有的 Rancher 节点。攻击者需要控制一个过期的域名,或者对该域名执行 DNS 欺骗/劫持攻击才可以利用此漏洞。被攻击的域名是 Rancher URL(用作 Rancher 集群的 server-url)。目前还没有可用的修复方案,它影响所有受支持的 Rancher 版本。建议客户和用户遵循我们[博客文章](https://www.suse.com/c/rancher-security-update/)中描述的建议和最佳实践。 | 2024 年 2 月 16 日 | 处理中 |
|
||||
| [CVE-2024-52281](https://github.com/rancher/rancher/security/advisories/GHSA-2v2w-8v8c-wcm9) | A high severity vulnerability was identified within the Rancher UI that allows a malicious actor to perform a Stored XSS attack through the cluster description field. | 15 Jan 2025 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) |
|
||||
| [CVE-2024-52282](https://github.com/rancher/rancher/security/advisories/GHSA-9c5p-35gj-jqp4) | A medium severity vulnerability was discovered within Rancher Manager whereby applications installed via Rancher Manager Apps Catalog store their Helm values directly into the Apps Custom Resource Definition, resulting in any users with GET access to it to be able to read any sensitive information that are contained within the Apps’ values. Additionally, the same information leaks into auditing logs when the audit level is set to equal or above 2. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 19 Nov 2024 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.8.10](https://github.com/rancher/rancher/releases/tag/v2.8.10). |
|
||||
| [CVE-2024-22036](https://github.com/rancher/rancher/security/advisories/GHSA-h99m-6755-rgwc) | A critical severity vulnerability was discovered within Rancher where a cluster or node driver can be used to escape the `chroot` jail and gain root access to the Rancher container itself. In production environments, further privilege escalation is possible based on living off the land within the Rancher container itself. For test and development environments, based on a –privileged Docker container, it is possible to escape the Docker container and gain execution access on the host system. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3), [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) and [v2.7.16](https://github.com/rancher/rancher/releases/tag/v2.7.16) |
|
||||
| [CVE-2023-32197](https://github.com/rancher/rancher/security/advisories/GHSA-7h8m-pvw3-5gh4) | A critical severity vulnerability was discovered whereby Rancher Manager deployments containing Windows nodes have weak Access Control Lists (ACL), allowing `BUILTIN\Users` or `NT AUTHORITY\Authenticated Users` to view or edit sensitive files which could lead to privilege escalation. This vulnerability is exclusive to deployments that contain Windows nodes. Linux-only environments are not affected by it. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) |
|
||||
| [CVE-2022-45157](https://github.com/rancher/rancher/security/advisories/GHSA-xj7w-r753-vj8v) | A critical severity vulnerability was discovered in the way that Rancher stores vSphere's CPI (Cloud Provider Interface) and CSI (Container Storage Interface) credentials used to deploy clusters through the vSphere cloud provider. This issue leads to the vSphere CPI and CSI passwords being stored in a plaintext object inside Rancher. This vulnerability is only applicable to users that deploy clusters in vSphere environments. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) |
|
||||
| [CVE-2024-22030](https://github.com/rancher/rancher/security/advisories/GHSA-h4h5-9833-v2p4) | 发现了 Rancher 和 Fleet 代理的一个漏洞,目前被认为是中到高危的 CVE。在非特定情况下,这个漏洞允许恶意行为者接管现有的 Rancher 节点。攻击者需要控制一个过期的域名,或者对该域名执行 DNS 欺骗/劫持攻击才可以利用此漏洞。被攻击的域名是 Rancher URL(用作 Rancher 集群的 server-url)。目前还没有可用的修复方案,它影响所有受支持的 Rancher 版本。建议客户和用户遵循我们[博客文章](https://www.suse.com/c/rancher-security-update/)中描述的建议和最佳实践。 | 2024 年 9 月 19 日 | 处理中 |
|
||||
| [CVE-2024-22032](https://github.com/rancher/rancher/security/advisories/GHSA-q6c7-56cq-g2wm) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where custom secrets encryption configurations are stored in plaintext under the clusters `AppliedSpec`. This also causes clusters to continuously reconcile, as the `AppliedSpec` would never match the desired cluster `Spec`. The stored information contains the encryption configuration for secrets within etcd, and could potentially expose sensitive data if the etcd database was exposed directly. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
| [CVE-2023-32196](https://github.com/rancher/rancher/security/advisories/GHSA-64jq-m7rq-768h) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where the webhook rule resolver ignores rules from a `ClusterRole` for an external `RoleTemplate` set with `.context=project` or `.context=""`. This allows a user to create an external `ClusterRole` with `.context=project` or `.context=""`, depending on the use of the new feature flag `external-rules` and backing `ClusterRole`. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
| [CVE-2023-22650](https://github.com/rancher/rancher/security/advisories/GHSA-9ghh-mmcq-8phc) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where Rancher did not have a user retention process for when external authentication providers are used, that could be configured to run periodically and disable and/or delete inactive users. The new user retention process added in Rancher v2.8.5 and Rancher v2.7.14 is disabled by default. If enabled, a user becomes subject to the retention process if they don't log in for a configurable period of time. It's possible to set overrides for user accounts that are primarily intended for programmatic access (e.g. CI, scripts, etc.) so that they don't become subject to the retention process for a longer period of time or at all. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
| [CVE-2023-32191](https://github.com/rancher/rke/security/advisories/GHSA-6gr4-52w6-vmqx) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, in which supported RKE versions store credentials inside a ConfigMap that can be accessible by non-administrative users in Rancher. This vulnerability only affects an RKE-provisioned cluster. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
| [CVE-2023-32193](https://github.com/rancher/norman/security/advisories/GHSA-r8f4-hv23-6qp6) | 在 Rancher 2.6.13、2.7.9 和 2.8.1 及之前的版本中发现了一个问题。多个 Cross-Site Scripting (XSS) 漏洞可通过 Rancher UI (Norman) 进行利用。 | 2024 年 2 月 8 日 | Rancher [v2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2)、[v2.7.10](https://github.com/rancher/rancher/releases/tag/v2.7.10) 和 [v2.6.14](https://github.com/rancher/rancher/releases/tag/v2.6.14) |
|
||||
| [CVE-2023-32192](https://github.com/rancher/apiserver/security/advisories/GHSA-833m-37f7-jq55) | 在 Rancher 2.6.13、2.7.9 和 2.8.1 及之前的版本中发现了一个问题。多个 Cross-Site Scripting (XSS) 漏洞,可以通过 Rancher UI (Apiserver) 进行利用 | 2024 年 2 月 8 日 | Rancher [v2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2)、[v2.7.10](https://github.com/rancher/rancher/releases/tag/v2.7.10) 和 [v2.6.14](https://github.com/rancher/rancher/releases/tag/v2.6.14) |
|
||||
| [CVE-2023-22649](https://github.com/rancher/rancher/security/advisories/GHSA-xfj7-qf8w-2gcr) | 在 Rancher 2.6.13、2.7.9 和 2.8.1 及之前的版本中发现了一个问题。敏感数据可能会泄漏到 Rancher 的审计日志中。 | 2024 年 2 月 8 日 | Rancher [v2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2)、[v2.7.10](https://github.com/rancher/rancher/releases/tag/v2.7.10) 和 [v2.6.14](https://github.com/rancher/rancher/releases/tag/v2.6.14) |
|
||||
|
||||
+4
@@ -14,6 +14,7 @@ title: 功能开关
|
||||
|
||||
以下是 Rancher 中可用的功能开关列表。如果你是从旧 Rancher 版本升级的,你可能会在 Rancher UI 中看到其他功能,例如 `proxy` 或 `dashboard`(均[已中断](/versioned_docs/version-2.5/reference-guides/installation-references/feature-flags.md)):
|
||||
|
||||
- `clean-stale-secrets`: Removes stale secrets from the `cattle-impersonation-system` namespace. This slowly cleans up old secrets which are no longer being used by the impersonation system.
|
||||
- `continuous-delivery`:允许从 Fleet 中单独禁用 Fleet GitOps。有关详细信息,请参阅[持续交付](../../../how-to-guides/advanced-user-guides/enable-experimental-features/continuous-delivery.md)。
|
||||
- `fleet`:v2.6 及更高版本的 Rancher 配置框架需要 Fleet。即使你在旧 Rancher 版本中禁用了该标志,该标志也将在升级时自动启用。有关详细信息,请参阅 [Fleet - GitOps at Scale](../../../integrations-in-rancher/fleet/fleet.md)。
|
||||
- `harvester`:管理 Virtualization Management 页面的访问。用户可以在该页面直接导航到 Harvester 集群并访问 Harvester UI。有关详细信息,请参阅 [Harvester 集成](../../../integrations-in-rancher/harvester/overview.md)。
|
||||
@@ -23,12 +24,15 @@ title: 功能开关
|
||||
- `rke1-custom-node-cleanup`:清除已删除的 RKE1 自定义节点。建议你启用此标志,以防止已删除的节点尝试重新加入集群。
|
||||
- `rke2`:启用配置 RKE2 集群。此标志默认启用。
|
||||
- `token-hashing`:启用令牌哈希。启用后,会使用 SHA256 算法对现有 Token 和所有新 Token 进行哈希处理。一旦对 Token 进行哈希处理,就无法撤消操作。此标志在启用后无法禁用。有关详细信息,请参阅 [API 令牌](../../../reference-guides/about-the-api/api-tokens.md#令牌哈希)。
|
||||
- `uiextension`: Enables UI extensions. This flag is enabled by default. Enabling or disabling the flag forces the Rancher pod to restart. The first time this flag is set to `true`, it creates a CRD and enables the controllers and endpoints necessary for the feature to work. If set to `false`, it disables the previously mentioned controllers and endpoints. Setting `uiextension` to `false` has no effect on the CRD -- it does not create a CRD if it does not yet exist, nor does it delete the CRD if it already exists.
|
||||
- `unsupported-storage-drivers`:允许启用非默认启用的存储提供程序和卷插件。有关详细信息,请参阅[允许使用不受支持的存储驱动程序](../../../how-to-guides/advanced-user-guides/enable-experimental-features/unsupported-storage-drivers.md)。
|
||||
- `ui-sql-cache`: Enables a SQLite-based cache for UI tables. See [UI Server-Side Pagination](../../../how-to-guides/advanced-user-guides/enable-experimental-features/ui-server-side-pagination.md) for more information.
|
||||
|
||||
下表介绍了 Rancher 中功能开关的可用性和默认值。标记为“GA”的功能已普遍可用:
|
||||
|
||||
| 功能开关名称 | 默认值 | 状态 | 可用于 |
|
||||
| ----------------------------- | ------------- | ------------ | --------------- |
|
||||
| `clean-stale-secrets` | `true` | GA | v2.9.6 | |
|
||||
| `continuous-delivery` | `true` | GA | v2.6.0 |
|
||||
| `fleet` | `true` | 不能禁用 | v2.6.0 |
|
||||
| `fleet` | `true` | GA | v2.5.0 |
|
||||
|
||||
-2
@@ -19,7 +19,5 @@ Rancher Server 的数据存储在 etcd 中。etcd 数据库可以在所有三个
|
||||
- Ingress Controller 会把 HTTP 重定向到 HTTPS,在 TCP/443 端口终结 SSL/TLS。
|
||||
- Ingress Controller 会把流量转发到 Rancher deployment 的 Pod 上的 TCP/80 端口。
|
||||
|
||||
<figcaption>使用 4 层负载均衡器在 Kubernetes 集群中安装 Rancher:Ingress Controller 的 SSL 终止:</figcaption>
|
||||
|
||||

|
||||
<sup>使用 4 层负载均衡器在 Kubernetes 集群中安装 Rancher:Ingress Controller 的 SSL 终止</sup>
|
||||
|
||||
-3
@@ -56,9 +56,6 @@ PrometheusRule 用于定义指标或时间序列数据库查询触发告警的
|
||||
|
||||
- 路由和接收器也通过 Alertmanager Secret 存储在 Kubernetes API 中。当 Secret 更新时,Alertmanager 也会自动更新。请注意,路由仅通过标签发生(而不是通过注释等)。
|
||||
|
||||
<figcaption>数据如何流经 Monitoring 应用程序</figcaption>
|
||||
|
||||
|
||||
## 2. Prometheus 的工作原理
|
||||
|
||||
### 存储时间序列数据
|
||||
|
||||
+10
-1
@@ -10,7 +10,16 @@ Rancher 致力于向社区披露我们产品的安全问题。我们会针对已
|
||||
|
||||
| ID | 描述 | 日期 | 解决 |
|
||||
|----|-------------|------|------------|
|
||||
| [CVE-2024-22030](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-22030) | 发现了 Rancher 和 Fleet 代理的一个漏洞,目前被认为是中到高危的 CVE。在非特定情况下,这个漏洞允许恶意行为者接管现有的 Rancher 节点。攻击者需要控制一个过期的域名,或者对该域名执行 DNS 欺骗/劫持攻击才可以利用此漏洞。被攻击的域名是 Rancher URL(用作 Rancher 集群的 server-url)。目前还没有可用的修复方案,它影响所有受支持的 Rancher 版本。建议客户和用户遵循我们[博客文章](https://www.suse.com/c/rancher-security-update/)中描述的建议和最佳实践。 | 2024 年 2 月 16 日 | 处理中 |
|
||||
| [CVE-2024-52281](https://github.com/rancher/rancher/security/advisories/GHSA-2v2w-8v8c-wcm9) | A high severity vulnerability was identified within the Rancher UI that allows a malicious actor to perform a Stored XSS attack through the cluster description field. | 15 Jan 2025 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) |
|
||||
| [CVE-2024-52282](https://github.com/rancher/rancher/security/advisories/GHSA-9c5p-35gj-jqp4) | A medium severity vulnerability was discovered within Rancher Manager whereby applications installed via Rancher Manager Apps Catalog store their Helm values directly into the Apps Custom Resource Definition, resulting in any users with GET access to it to be able to read any sensitive information that are contained within the Apps’ values. Additionally, the same information leaks into auditing logs when the audit level is set to equal or above 2. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 19 Nov 2024 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.8.10](https://github.com/rancher/rancher/releases/tag/v2.8.10). |
|
||||
| [CVE-2024-22036](https://github.com/rancher/rancher/security/advisories/GHSA-h99m-6755-rgwc) | A critical severity vulnerability was discovered within Rancher where a cluster or node driver can be used to escape the `chroot` jail and gain root access to the Rancher container itself. In production environments, further privilege escalation is possible based on living off the land within the Rancher container itself. For test and development environments, based on a –privileged Docker container, it is possible to escape the Docker container and gain execution access on the host system. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3), [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) and [v2.7.16](https://github.com/rancher/rancher/releases/tag/v2.7.16) |
|
||||
| [CVE-2023-32197](https://github.com/rancher/rancher/security/advisories/GHSA-7h8m-pvw3-5gh4) | A critical severity vulnerability was discovered whereby Rancher Manager deployments containing Windows nodes have weak Access Control Lists (ACL), allowing `BUILTIN\Users` or `NT AUTHORITY\Authenticated Users` to view or edit sensitive files which could lead to privilege escalation. This vulnerability is exclusive to deployments that contain Windows nodes. Linux-only environments are not affected by it. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) |
|
||||
| [CVE-2022-45157](https://github.com/rancher/rancher/security/advisories/GHSA-xj7w-r753-vj8v) | A critical severity vulnerability was discovered in the way that Rancher stores vSphere's CPI (Cloud Provider Interface) and CSI (Container Storage Interface) credentials used to deploy clusters through the vSphere cloud provider. This issue leads to the vSphere CPI and CSI passwords being stored in a plaintext object inside Rancher. This vulnerability is only applicable to users that deploy clusters in vSphere environments. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) |
|
||||
| [CVE-2024-22030](https://github.com/rancher/rancher/security/advisories/GHSA-h4h5-9833-v2p4) | 发现了 Rancher 和 Fleet 代理的一个漏洞,目前被认为是中到高危的 CVE。在非特定情况下,这个漏洞允许恶意行为者接管现有的 Rancher 节点。攻击者需要控制一个过期的域名,或者对该域名执行 DNS 欺骗/劫持攻击才可以利用此漏洞。被攻击的域名是 Rancher URL(用作 Rancher 集群的 server-url)。目前还没有可用的修复方案,它影响所有受支持的 Rancher 版本。建议客户和用户遵循我们[博客文章](https://www.suse.com/c/rancher-security-update/)中描述的建议和最佳实践。 | 2024 年 9 月 19 日 | 处理中 |
|
||||
| [CVE-2024-22032](https://github.com/rancher/rancher/security/advisories/GHSA-q6c7-56cq-g2wm) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where custom secrets encryption configurations are stored in plaintext under the clusters `AppliedSpec`. This also causes clusters to continuously reconcile, as the `AppliedSpec` would never match the desired cluster `Spec`. The stored information contains the encryption configuration for secrets within etcd, and could potentially expose sensitive data if the etcd database was exposed directly. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
| [CVE-2023-32196](https://github.com/rancher/rancher/security/advisories/GHSA-64jq-m7rq-768h) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where the webhook rule resolver ignores rules from a `ClusterRole` for an external `RoleTemplate` set with `.context=project` or `.context=""`. This allows a user to create an external `ClusterRole` with `.context=project` or `.context=""`, depending on the use of the new feature flag `external-rules` and backing `ClusterRole`. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
| [CVE-2023-22650](https://github.com/rancher/rancher/security/advisories/GHSA-9ghh-mmcq-8phc) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where Rancher did not have a user retention process for when external authentication providers are used, that could be configured to run periodically and disable and/or delete inactive users. The new user retention process added in Rancher v2.8.5 and Rancher v2.7.14 is disabled by default. If enabled, a user becomes subject to the retention process if they don't log in for a configurable period of time. It's possible to set overrides for user accounts that are primarily intended for programmatic access (e.g. CI, scripts, etc.) so that they don't become subject to the retention process for a longer period of time or at all. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
| [CVE-2023-32191](https://github.com/rancher/rke/security/advisories/GHSA-6gr4-52w6-vmqx) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, in which supported RKE versions store credentials inside a ConfigMap that can be accessible by non-administrative users in Rancher. This vulnerability only affects an RKE-provisioned cluster. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
| [CVE-2023-32193](https://github.com/rancher/norman/security/advisories/GHSA-r8f4-hv23-6qp6) | 在 Rancher 2.6.13、2.7.9 和 2.8.1 及之前的版本中发现了一个问题。多个 Cross-Site Scripting (XSS) 漏洞可通过 Rancher UI (Norman) 进行利用。 | 2024 年 2 月 8 日 | Rancher [v2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2)、[v2.7.10](https://github.com/rancher/rancher/releases/tag/v2.7.10) 和 [v2.6.14](https://github.com/rancher/rancher/releases/tag/v2.6.14) |
|
||||
| [CVE-2023-32192](https://github.com/rancher/apiserver/security/advisories/GHSA-833m-37f7-jq55) | 在 Rancher 2.6.13、2.7.9 和 2.8.1 及之前的版本中发现了一个问题。多个 Cross-Site Scripting (XSS) 漏洞,可以通过 Rancher UI (Apiserver) 进行利用 | 2024 年 2 月 8 日 | Rancher [v2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2)、[v2.7.10](https://github.com/rancher/rancher/releases/tag/v2.7.10) 和 [v2.6.14](https://github.com/rancher/rancher/releases/tag/v2.6.14) |
|
||||
| [CVE-2023-22649](https://github.com/rancher/rancher/security/advisories/GHSA-xfj7-qf8w-2gcr) | 在 Rancher 2.6.13、2.7.9 和 2.8.1 及之前的版本中发现了一个问题。敏感数据可能会泄漏到 Rancher 的审计日志中。 | 2024 年 2 月 8 日 | Rancher [v2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2)、[v2.7.10](https://github.com/rancher/rancher/releases/tag/v2.7.10) 和 [v2.6.14](https://github.com/rancher/rancher/releases/tag/v2.6.14) |
|
||||
|
||||
@@ -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 October 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 January 2025.
|
||||
|
||||
| Provider | Project | Stars | Forks | Contributors |
|
||||
| ---- | ---- | ---- | ---- | ---- |
|
||||
| Canal | https://github.com/projectcalico/canal | 716 | 100 | 20 |
|
||||
| Flannel | https://github.com/flannel-io/flannel | 8.8k | 2.9k | 234 |
|
||||
| Calico | https://github.com/projectcalico/calico | 6.0k | 1.3k | 353 |
|
||||
| Weave | https://github.com/weaveworks/weave/ | 6.6k | 670 | 85 |
|
||||
| Cilium | https://github.com/cilium/cilium | 20.0k | 2.9k | 832 |
|
||||
| Canal | https://github.com/projectcalico/canal | 719 | 100 | 20 |
|
||||
| Flannel | https://github.com/flannel-io/flannel | 8.9k | 2.9k | 236 |
|
||||
| Calico | https://github.com/projectcalico/calico | 6.2k | 1.4k | 365 |
|
||||
| Weave | https://github.com/weaveworks/weave | 6.6k | 673 | 84 |
|
||||
| Cilium | https://github.com/cilium/cilium | 20.7k | 3k | 877 |
|
||||
|
||||
@@ -0,0 +1,16 @@
|
||||
Rancher supports the ability to configure SAML SLO. Options include logging out of the Rancher application only, logging out of Rancher and registered applications tied to the external authentication provider, or a prompt asking the user to choose between the previous options. The steps below outline configuration from the application GUI:
|
||||
|
||||
:::note
|
||||
The **Log Out behavior** configuration section only appears if the SAML authentication provider allows for `SAML SLO`.
|
||||
:::
|
||||
|
||||
1. Sign in to Rancher using a standard user or an administrator role to configure SAML SLO.
|
||||
1. In the top left corner, click **☰ > Users & Authentication**.
|
||||
1. In the left navigation menu, click **Auth Provider**.
|
||||
1. Under the section **Log Out behavior**, choose the appropriate SLO setting as described below:
|
||||
|
||||
| Setting | Description |
|
||||
| ------------------------- | ----------------------------------------------------------------------------- |
|
||||
| Log out of Rancher and not authentication provider | Choosing this option will only logout the Rancher application and not external authentication providers. |
|
||||
| Log out of Rancher and authentication provider (includes all other applications registered with authentication provider) | Choosing this option will logout Rancher and all external authentication providers along with any registered applications linked to the provider. |
|
||||
| Allow the user to choose one of the above in an additional log out step | Choosing this option presents users with a choice of logout method as described above. |
|
||||
@@ -1293,7 +1293,6 @@ const sidebars = {
|
||||
"integrations-in-rancher/monitoring-and-alerting/promql-expressions",
|
||||
]
|
||||
},
|
||||
"integrations-in-rancher/opa-gatekeeper",
|
||||
"integrations-in-rancher/rancher-extensions",
|
||||
]
|
||||
},
|
||||
@@ -1307,7 +1306,6 @@ const sidebars = {
|
||||
"faq/dockershim",
|
||||
"faq/technical-items",
|
||||
"faq/security",
|
||||
"faq/telemetry",
|
||||
"faq/container-network-interface-providers",
|
||||
"faq/rancher-is-no-longer-needed",
|
||||
]
|
||||
|
||||
+96
-6
@@ -6,7 +6,7 @@ title: Rancher Documentation Versions
|
||||
|
||||
### Current Versions
|
||||
|
||||
Here you can find links to supporting documentation for the current released version of Rancher v2.9, and its availability for [Rancher Prime](/v2.8/getting-started/quick-start-guides/deploy-rancher-manager/prime) and the Community version of Rancher:
|
||||
Here you can find links to supporting documentation for the current released version of Rancher v2.10, and its availability for [Rancher Prime](/v2.10/getting-started/quick-start-guides/deploy-rancher-manager/prime) and the Community version of Rancher:
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
@@ -18,15 +18,36 @@ Here you can find links to supporting documentation for the current released ver
|
||||
<th>Community</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.9.3</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.3">Release Notes</a></td>
|
||||
<td><b>v2.10.2</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.10">Documentation</a></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.10.2">Release Notes</a></td>
|
||||
<td><center>N/A</center></td>
|
||||
<td><center>✓</center></td>
|
||||
<td><center>✓</center></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
Here you can find links to supporting documentation for the current released version of Rancher v2.9, and its 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.6</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.6">Release Notes</a></td>
|
||||
<td><center>N/A</center></td>
|
||||
<td><center>✓</center></td>
|
||||
<td><center>N/A</center></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
Here you can find links to supporting documentation for the current released version of Rancher v2.8, and its availability for [Rancher Prime](/v2.8/getting-started/quick-start-guides/deploy-rancher-manager/prime) and the Community version of Rancher:
|
||||
|
||||
<table>
|
||||
@@ -39,9 +60,9 @@ Here you can find links to supporting documentation for the current released ver
|
||||
<th>Community</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.8.10</b></td>
|
||||
<td><b>v2.8.12</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.10">Release Notes</a></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.8.12">Release Notes</a></td>
|
||||
<td><center>N/A</center></td>
|
||||
<td><center>✓</center></td>
|
||||
<td><center>N/A</center></td>
|
||||
@@ -71,6 +92,35 @@ 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.10, and their availability for [Rancher Prime](/v2.10/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.10.1</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.10">Documentation</a></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.10.1">Release Notes</a></td>
|
||||
<td><a href="https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/rancher-v2-10-1/">Support Matrix</a></td>
|
||||
<td><center>✓</center></td>
|
||||
<td><center>✓</center></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.10.0</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.10">Documentation</a></td>
|
||||
<td><a href="https://github.com/rancher/rancher/releases/tag/v2.10.0">Release Notes</a></td>
|
||||
<td><center>N/A</center></td>
|
||||
<td><center>N/A</center></td>
|
||||
<td><center>✓</center></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
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>
|
||||
@@ -82,6 +132,30 @@ Here you can find links to supporting documentation for previous versions of Ran
|
||||
<th>Prime</th>
|
||||
<th>Community</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.9.5</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.5">Release Notes</a></td>
|
||||
<td><a href="https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/rancher-v2-9-5/">Support Matrix</a></td>
|
||||
<td><center>✓</center></td>
|
||||
<td><center>N/A</center></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.9.4</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.4">Release Notes</a></td>
|
||||
<td><a href="https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/rancher-v2-9-4/">Support Matrix</a></td>
|
||||
<td><center>✓</center></td>
|
||||
<td><center>N/A</center></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.9.3</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.3">Release Notes</a></td>
|
||||
<td><a href="https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/rancher-v2-9-3/">Support Matrix</a></td>
|
||||
<td><center>✓</center></td>
|
||||
<td><center>✓</center></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.9.2</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.9">Documentation</a></td>
|
||||
@@ -121,6 +195,22 @@ Here you can find links to supporting documentation for previous versions of Ran
|
||||
<th>Prime</th>
|
||||
<th>Community</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.8.11</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.11">Release Notes</a></td>
|
||||
<td><a href="https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/rancher-v2-8-11/">Support Matrix</a></td>
|
||||
<td><center>✓</center></td>
|
||||
<td><center>N/A</center></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.8.10</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.10">Release Notes</a></td>
|
||||
<td><a href="https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/rancher-v2-8-10/">Support Matrix</a></td>
|
||||
<td><center>✓</center></td>
|
||||
<td><center>N/A</center></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>v2.8.9</b></td>
|
||||
<td><a href="https://ranchermanager.docs.rancher.com/v2.8">Documentation</a></td>
|
||||
|
||||
@@ -11,6 +11,7 @@ import DeprecationOPAGatekeeper from '/shared-files/_deprecation-opa-gatekeeper.
|
||||
import DeprecationWeave from '/shared-files/_deprecation-weave.md';
|
||||
import DeprecationHelm2 from '/shared-files/_deprecation-helm2.md';
|
||||
import DockerSupportWarning from '/shared-files/_docker-support-warning.md';
|
||||
import ConfigureSLO from '/shared-files/_configure-slo.md';
|
||||
|
||||
export default {
|
||||
// Re-use the default mapping
|
||||
@@ -23,6 +24,7 @@ export default {
|
||||
Card,
|
||||
|
||||
CNIPopularityTable,
|
||||
ConfigureSLO,
|
||||
DeprecationOPAGatekeeper,
|
||||
DeprecationWeave,
|
||||
DeprecationHelm2,
|
||||
|
||||
@@ -49,6 +49,10 @@ EOF
|
||||
|
||||
Setting the `field.cattle.io/creatorId` field allows the cluster member account to see project resources with the `get` command and view the project in the Rancher UI. Cluster owner and admin accounts don't need to set this annotation to perform these tasks.
|
||||
|
||||
Setting the `field.cattle.io/creator-principal-name` annotation to the user's principal preserves it in a projectroletemplatebinding automatically created for the project owner.
|
||||
|
||||
If you don't want the creator to be added as the owner member (e.g. if the creator is a cluster administrator) to the project you may set the `field.cattle.io/no-creator-rbac` annotation to `true`, which will prevent the corresponding projectroletemplatebinding from being created.
|
||||
|
||||
### Creating a Project With a Resource Quota
|
||||
|
||||
Refer to [Kubernetes Resource Quota](https://kubernetes.io/docs/concepts/policy/resource-quotas/).
|
||||
@@ -91,6 +95,77 @@ spec:
|
||||
limitsMemory: 100Mi
|
||||
requestsCpu: 50m
|
||||
requestsMemory: 50Mi
|
||||
EOF
|
||||
```
|
||||
|
||||
## Adding a Member to a Project
|
||||
|
||||
Look up the project ID to specify the `metadata.namespace` field and `projectName` field values.
|
||||
|
||||
```bash
|
||||
kubectl --namespace c-m-abcde get projects
|
||||
```
|
||||
|
||||
Look up the role template ID to specify the `roleTemplateName` field value (e.g. `project-member` or `project-owner`).
|
||||
|
||||
```bash
|
||||
kubectl get roletemplates
|
||||
```
|
||||
|
||||
When adding a user member specify the `userPrincipalName` field:
|
||||
|
||||
```bash
|
||||
kubectl create -f - <<EOF
|
||||
apiVersion: management.cattle.io/v3
|
||||
kind: ProjectRoleTemplateBinding
|
||||
metadata:
|
||||
generateName: prtb-
|
||||
namespace: p-vwxyz
|
||||
projectName: c-m-abcde:p-vwxyz
|
||||
roleTemplateName: project-member
|
||||
userPrincipalName: keycloak_user://user
|
||||
EOF
|
||||
```
|
||||
|
||||
When adding a group member specify the `groupPrincipalName` field instead:
|
||||
|
||||
```bash
|
||||
kubectl create -f - <<EOF
|
||||
apiVersion: management.cattle.io/v3
|
||||
kind: ProjectRoleTemplateBinding
|
||||
metadata:
|
||||
generateName: prtb-
|
||||
namespace: p-vwxyz
|
||||
projectName: c-m-abcde:p-vwxyz
|
||||
roleTemplateName: project-member
|
||||
groupPrincipalName: keycloak_group://group
|
||||
EOF
|
||||
```
|
||||
|
||||
Create a projectroletemplatebinding for each role you want to assign to the project member.
|
||||
|
||||
## Listing Project Members
|
||||
|
||||
Look up the project ID:
|
||||
|
||||
```bash
|
||||
kubectl --namespace c-m-abcde get projects
|
||||
```
|
||||
|
||||
to list projectroletemplatebindings in the project's namespace:
|
||||
|
||||
```bash
|
||||
kubectl --namespace p-vwxyz get projectroletemplatebindings
|
||||
```
|
||||
|
||||
## Deleting a Member From a Project
|
||||
|
||||
Lookup the projectroletemplatebinding IDs containing the member in the project's namespace as decribed in the [Listing Project Members](#listing-project-members) section.
|
||||
|
||||
Delete the projectroletemplatebinding from the project's namespace:
|
||||
|
||||
```bash
|
||||
kubectl --namespace p-vwxyz delete projectroletemplatebindings prtb-qx874 prtb-7zw7s
|
||||
```
|
||||
|
||||
## Creating a Namespace in a Project
|
||||
@@ -132,4 +207,4 @@ Delete the project under the cluster namespace:
|
||||
kubectl --namespace c-m-abcde delete project p-vwxyz
|
||||
```
|
||||
|
||||
Note that this command doesn't delete the namespaces and resources that formerly belonged to the project.
|
||||
Note that this command doesn't delete the namespaces and resources that formerly belonged to the project.
|
||||
|
||||
@@ -16,9 +16,9 @@ Rancher will publish deprecated features as part of the [release notes](https://
|
||||
|
||||
| Patch Version | Release Date |
|
||||
|---------------|---------------|
|
||||
| [2.9.2](https://github.com/rancher/rancher/releases/tag/v2.9.2) | Sep 19, 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 |
|
||||
| [2.10.2](https://github.com/rancher/rancher/releases/tag/v2.10.2) | Jan 29, 2025 |
|
||||
| [2.10.1](https://github.com/rancher/rancher/releases/tag/v2.10.1) | Dec 19, 2024 |
|
||||
| [2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) | Nov 18, 2024 |
|
||||
|
||||
## What can I expect when a feature is marked for deprecation?
|
||||
|
||||
|
||||
@@ -91,11 +91,11 @@ The UI consists of static files, and works based on responses of the API. That m
|
||||
|
||||
## The IP address of a node changed, how can I recover?
|
||||
|
||||
A node is required to have a static IP configured (or a reserved IP via DHCP). If the IP of a node has changed, you will have to remove it from the cluster and readd it. After it is removed, Rancher will update the cluster to the correct state. If the cluster is no longer in `Provisioning` state, the node is removed from the cluster.
|
||||
A node is required to have a static IP configured (or a reserved IP via DHCP). If the IP of a node has changed, you will have to remove it from the cluster and add it again. After it is removed, Rancher will update the cluster to the correct state. If the cluster is no longer in `Provisioning` state, the node is removed from the cluster.
|
||||
|
||||
When the IP address of the node changed, Rancher lost connection to the node, so it will be unable to clean the node properly. See [Cleaning cluster nodes](../how-to-guides/new-user-guides/manage-clusters/clean-cluster-nodes.md) to clean the node.
|
||||
|
||||
When the node is removed from the cluster, and the node is cleaned, you can readd the node to the cluster.
|
||||
When the node is removed from the cluster, and the node is cleaned, you can add the node to the cluster.
|
||||
|
||||
## How can I add more arguments/binds/environment variables to Kubernetes components in a Rancher Launched Kubernetes cluster?
|
||||
|
||||
|
||||
+6
-2
@@ -18,11 +18,13 @@ Some feature flags require a restart of the Rancher container. Features that req
|
||||
|
||||
The following is a list of feature flags available in Rancher. If you've upgraded from a previous Rancher version, you may see additional flags in the Rancher UI, such as `proxy` or `dashboard` (both [discontinued](/versioned_docs/version-2.5/reference-guides/installation-references/feature-flags.md)):
|
||||
|
||||
- `clean-stale-secrets`: Removes stale secrets from the `cattle-impersonation-system` namespace. This slowly cleans up old secrets which are no longer being used by the impersonation system.
|
||||
- `continuous-delivery`: Allows Fleet GitOps to be disabled separately from Fleet. See [Continuous Delivery.](../../../how-to-guides/advanced-user-guides/enable-experimental-features/continuous-delivery.md) for more information.
|
||||
- `fleet`: The Rancher provisioning framework in v2.6 and later requires Fleet. The flag will be automatically enabled when you upgrade, even if you disabled this flag in an earlier version of Rancher. See [Continuous Delivery with Fleet](../../../integrations-in-rancher/fleet/fleet.md) for more information.
|
||||
- `harvester`: Manages access to the Virtualization Management page, where users can navigate directly to Harvester clusters and access the Harvester UI. See [Harvester Integration Overview](../../../integrations-in-rancher/harvester/overview.md) for more information.
|
||||
- `istio-virtual-service-ui`: Enables a [visual interface](../../../how-to-guides/advanced-user-guides/enable-experimental-features/istio-traffic-management-features.md) to create, read, update, and delete Istio virtual services and destination rules, which are Istio traffic management features.
|
||||
- `legacy`: Enables a set of features from 2.5.x and earlier, that are slowly being phased out in favor of newer implementations. These are a mix of deprecated features as well as features that will eventually be available to newer versions. This flag is disabled by default on new Rancher installations. If you're upgrading from a previous version of Rancher, this flag is enabled.
|
||||
- `managed-system-upgrade-controller`: Enables the installation of the system-upgrade-controller app in downstream RKE2/K3s clusters, currently limited to imported clusters and the local cluster, with plans to expand support to node-driver clusters.
|
||||
- `multi-cluster-management`: Allows multi-cluster provisioning and management of Kubernetes clusters. This flag can only be set at install time. It can't be enabled or disabled later.
|
||||
- `rke1-custom-node-cleanup`: Enables cleanup of deleted RKE1 custom nodes. We recommend that you keep this flag enabled, to prevent removed nodes from attempting to rejoin the cluster.
|
||||
- `rke2`: Enables provisioning RKE2 clusters. This flag is enabled by default.
|
||||
@@ -36,14 +38,16 @@ The following table shows the availability and default values for some feature f
|
||||
|
||||
| Feature Flag Name | Default Value | Status | Available As Of | Additional Information |
|
||||
| ----------------------------- | ------------- | ------------ | --------------- | ---------------------- |
|
||||
| `clean-stale-secrets` | `true` | GA | v2.10.2 | |
|
||||
| `continuous-delivery` | `true` | GA | v2.6.0 | |
|
||||
| `external-rules` | v2.7.14: `false`, v2.8.5: `true` | Removed | v2.7.14, v2.8.5 | This flag affected [external `RoleTemplate` behavior](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#external-roletemplate-behavior). It is removed in Rancher v2.9.0 and later as the behavior is enabled by default. |
|
||||
| `fleet` | `true` | Can no longer be disabled | v2.6.0 | |
|
||||
| `fleet` | `true` | GA | v2.5.0 | |
|
||||
| `harvester` | `true` | Experimental | v2.6.1 | |
|
||||
| `legacy` | `false` for new installs, `true` for upgrades | GA | v2.6.0 | |
|
||||
| `managed-system-upgrade-controller` | `true` | GA | v2.10.0 | |
|
||||
| `rke1-custom-node-cleanup`| `true` | GA | v2.6.0 | |
|
||||
| `rke2` | `true` | Experimental | v2.6.0 | |
|
||||
| `token-hashing` | `false` for new installs, `true` for upgrades | GA | v2.6.0 | |
|
||||
| `uiextension` | `true` | GA | v2.9.0 |
|
||||
| `ui-sql-cache` | `false` | Highly experimental | v2.9.0 |
|
||||
| `uiextension` | `true` | GA | v2.9.0 | |
|
||||
| `ui-sql-cache` | `false` | Highly experimental | v2.9.0 | |
|
||||
|
||||
+8
-1
@@ -13,4 +13,11 @@ To view the generated CIS scan reports,
|
||||
1. Click **CIS Benchmark > Scan**.
|
||||
1. The **Scans** page will show the generated reports. To see a detailed report, go to a scan report and click the name.
|
||||
|
||||
One can download the report from the Scans list or from the scan detail page.
|
||||
One can download the report from the Scans list or from the scan detail page.
|
||||
|
||||
To get the verbose version of the CIS scan results, run the following command on the cluster that was scanned. Note that the scan must be completed before this can be done.
|
||||
|
||||
```console
|
||||
export REPORT="scan-report-name"
|
||||
kubectl get clusterscanreport $REPORT -o json |jq ".spec.reportJSON | fromjson" | jq -r ".actual_value_map_data" | base64 -d | gunzip | jq .
|
||||
```
|
||||
|
||||
+4
@@ -192,3 +192,7 @@ Try configuring and saving keycloak as your SAML provider and then accessing the
|
||||
|
||||
* Check your Keycloak log.
|
||||
* If the log displays `request validation failed: org.keycloak.common.VerificationException: SigAlg was null`, set `Client Signature Required` to `OFF` in your Keycloak client.
|
||||
|
||||
## Configuring SAML Single Logout (SLO)
|
||||
|
||||
<ConfigureSLO />
|
||||
|
||||
+5
-1
@@ -107,4 +107,8 @@ The OpenLDAP service account is used for all searches. Rancher users will see us
|
||||
1. Click **Okta** or, if SAML is already configured, **Edit Config**
|
||||
1. Under **User and Group Search**, check **Configure an OpenLDAP server**
|
||||
|
||||
If you experience issues when you test the connection to the OpenLDAP server, ensure that you entered the credentials for the service account and configured the search base correctly. Inspecting the Rancher logs can help pinpoint the root cause. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging](../../../../faq/technical-items.md#how-can-i-enable-debug-logging) for more information.
|
||||
If you experience issues when you test the connection to the OpenLDAP server, ensure that you entered the credentials for the service account and configured the search base correctly. Inspecting the Rancher logs can help pinpoint the root cause. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging](../../../../faq/technical-items.md#how-can-i-enable-debug-logging) for more information.
|
||||
|
||||
## Configuring SAML Single Logout (SLO)
|
||||
|
||||
<ConfigureSLO />
|
||||
|
||||
+4
@@ -64,3 +64,7 @@ Note that these URLs will not return valid data until the authentication configu
|
||||
- The group drop-down shows only the groups that you are a member of. You will not be able to add groups that you are not a member of.
|
||||
|
||||
:::
|
||||
|
||||
## Configuring SAML Single Logout (SLO)
|
||||
|
||||
<ConfigureSLO />
|
||||
|
||||
+4
@@ -51,3 +51,7 @@ You can generate a certificate using an openssl command. For example:
|
||||
```
|
||||
openssl req -x509 -newkey rsa:2048 -keyout myservice.key -out myservice.cert -days 365 -nodes -subj "/CN=myservice.example.com"
|
||||
```
|
||||
|
||||
## Configuring SAML Single Logout (SLO)
|
||||
|
||||
<ConfigureSLO />
|
||||
|
||||
+4
@@ -77,6 +77,10 @@ If you configure Shibboleth without OpenLDAP, the following caveats apply due to
|
||||
|
||||
To enable searching for groups when assigning permissions in Rancher, you will need to configure a back end for the SAML provider that supports groups, such as OpenLDAP.
|
||||
|
||||
### Configuring SAML Single Logout (SLO)
|
||||
|
||||
<ConfigureSLO />
|
||||
|
||||
## Setting up OpenLDAP in Rancher
|
||||
|
||||
If you also configure OpenLDAP as the back end to Shibboleth, it will return a SAML assertion to Rancher with user attributes that include groups. Then authenticated users will be able to access resources in Rancher that their groups have permissions for.
|
||||
|
||||
+1
-1
@@ -13,7 +13,7 @@ PSS define security levels for workloads. PSAs describe requirements for pod sec
|
||||
|
||||
## Upgrade to Pod Security Standards (PSS)
|
||||
|
||||
Ensure that you migrate all PSPs to another workload security mechanism. This includes mapping your current PSPs to Pod Security Standards for enforcement with the [PSA controller](https://kubernetes.io/docs/concepts/security/pod-security-admission/). If the PSA controller won't meet all of your organization's needs, we recommend that you use a policy engine, such as [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper), [Kubewarden](https://www.kubewarden.io/), [Kyverno](https://kyverno.io/), or [NeuVector](https://neuvector.com/). Refer to the documentation of your policy engine of choice for more information on how to migrate from PSPs.
|
||||
Ensure that you migrate all PSPs to another workload security mechanism. This includes mapping your current PSPs to Pod Security Standards for enforcement with the [PSA controller](https://kubernetes.io/docs/concepts/security/pod-security-admission/). If the PSA controller won't meet all of your organization's needs, we recommend that you use a policy engine, such as [Kubewarden](https://www.kubewarden.io/), [Kyverno](https://kyverno.io/), or [NeuVector](https://neuvector.com/). Refer to the documentation of your policy engine of choice for more information on how to migrate from PSPs.
|
||||
|
||||
:::caution
|
||||
You must add your new policy enforcement mechanisms _before_ you remove the PodSecurityPolicy objects. If you don't, you may create an opportunity for privilege escalation attacks within the cluster.
|
||||
|
||||
+38
-3
@@ -53,8 +53,7 @@ To display prerelease versions:
|
||||
| rancher-alerting-drivers | 100.0.0 | 100.0.2 |
|
||||
| rancher-backup | 2.0.1 | 2.1.2 |
|
||||
| rancher-cis-benchmark | 2.0.1 | 2.0.4 |
|
||||
| rancher-gatekeeper | 100.0.0+up3.6.0 | 100.1.0+up3.7.1 |
|
||||
| rancher-istio | 100.0.0+up1.10.4 | 100.3.0+up1.13.3 |
|
||||
| rancher-istio | 105.0.0+up1.19.6 | 105.4.0+up1.23.2 |
|
||||
| rancher-logging | 100.0.0+up3.12.0 | 100.1.2+up3.17.4 |
|
||||
| rancher-longhorn | 100.0.0+up1.1.2 | 100.1.2+up1.2.4 |
|
||||
| rancher-monitoring | 100.0.0+up16.6.0 | 100.1.2+up19.0.3 |
|
||||
@@ -194,6 +193,42 @@ Non-Airgap Rancher installations upon refresh will reflect any chart repository
|
||||
|
||||
Airgap installations where Rancher is configured to use the packaged copy of Helm system charts ([`useBundledSystemChart=true`](../../../getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha.md#helm-chart-options-for-air-gap-installations)) will only refer to the [system-chart](https://github.com/rancher/system-charts) repository that comes bundled and will not be able to be refreshed or synced.
|
||||
|
||||
#### Refresh Interval
|
||||
|
||||
Rancher v2.10.0 adds the `refreshInterval` field to the `ClusterRepo` CRD. The default value is 3600 seconds, meaning that Rancher syncs each Helm repository every 3600 seconds.
|
||||
|
||||
To modify the refresh interval of a chart repository:
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
|
||||
1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.
|
||||
1. Find the repository you want to modify, and click **⋮ > Edit YAML**.
|
||||
1. Set the **refreshInterval** field under **Spec** to the desired value in seconds.
|
||||
1. Click **Save**.
|
||||
|
||||
### Enable/Disable Helm Chart Repositories
|
||||
|
||||
Rancher v2.10.0 adds the ability to enable and disable Helm repositories. Helm repositories are enabled by default.
|
||||
|
||||
To disable a chart repository:
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
|
||||
1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.
|
||||
1. Find the repository you want to disable, and click **⋮ > Edit YAML**.
|
||||
1. Set the **Enabled** field under **Spec** to **false**.
|
||||
1. Click **Save**.
|
||||
1. When you disable a repository, updates are disabled and new changes to the clusterRepo are not applied.
|
||||
|
||||
To enable a chart repository:
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
|
||||
1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Repositories**.
|
||||
1. Find the repository you want to disable, and click **⋮ > Edit YAML**.
|
||||
1. Set the **Enabled** field under **Spec** to **true**.
|
||||
1. Click **Save**.
|
||||
|
||||
## Deploy and Upgrade Charts
|
||||
|
||||
To install and deploy a chart:
|
||||
@@ -201,7 +236,7 @@ To install and deploy a chart:
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Find the name of the cluster whose repositories you want to access. Click **Explore** at the end of the cluster's row.
|
||||
1. In the left navigation menu on the **Cluster Dashboard**, click **Apps > Charts**.
|
||||
1. Select a chart, and click **Install**.
|
||||
1. Select a chart, and click **Install**.
|
||||
|
||||
Rancher and Partner charts may have extra configurations available through custom pages or questions.yaml files. However, all chart installations can modify the values.yaml and other basic settings. After you click **Install**, a Helm operation job is deployed, and the console for the job is displayed.
|
||||
|
||||
|
||||
-2
@@ -23,7 +23,5 @@ For information on how Rancher works, regardless of the installation method, ref
|
||||
- The Ingress controller will redirect HTTP to HTTPS and terminate SSL/TLS on port TCP/443.
|
||||
- The Ingress controller will forward traffic to port TCP/80 on the pod in the Rancher deployment.
|
||||
|
||||
<figcaption>Kubernetes Rancher install with layer 4 load balancer, depicting SSL termination at ingress controllers</figcaption>
|
||||
|
||||

|
||||
<sup>Kubernetes Rancher install with Layer 4 load balancer (TCP), depicting SSL termination at ingress controllers</sup>
|
||||
|
||||
+19
@@ -35,6 +35,8 @@ Since, by default, Google Kubernetes Engine (GKE) doesn't grant the `cluster-adm
|
||||
|
||||
To successfully import or provision EKS, AKS, and GKE clusters from Rancher, the cluster must have at least one managed node group.
|
||||
|
||||
AKS clusters can be imported only if local accounts are enabled. If a cluster is configured to use Microsoft Entra ID for authentication, then Rancher will not be able to import it and report an error.
|
||||
|
||||
EKS Anywhere clusters can be imported/registered into Rancher with an API address and credentials, as with any downstream cluster. EKS Anywhere clusters are treated as imported clusters and do not have full lifecycle support from Rancher.
|
||||
|
||||
GKE Autopilot clusters aren't supported. See [Compare GKE Autopilot and Standard](https://cloud.google.com/kubernetes-engine/docs/resources/autopilot-standard-feature-comparison) for more information about the differences between GKE modes.
|
||||
@@ -286,3 +288,20 @@ To annotate a registered cluster,
|
||||
6. Click **Save**.
|
||||
|
||||
**Result:** The annotation does not give the capabilities to the cluster, but it does indicate to Rancher that the cluster has those capabilities.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
This section lists some of the most common errors that may occur when importing a cluster, along with steps to troubleshoot them.
|
||||
|
||||
### AKS
|
||||
|
||||
- The following error may occur if local accounts are disabled in your cluster.
|
||||
```sh
|
||||
Error: Getting static credential is not allowed because this cluster is set to disable local accounts.
|
||||
```
|
||||
|
||||
To resolve this issue, enable local accounts before attempting to [import the cluster](#registering-a-cluster) again.
|
||||
|
||||
```sh
|
||||
az aks update --resource-group <resource-group> --name <cluster-name> --enable-local-accounts
|
||||
```
|
||||
+137
-187
@@ -93,7 +93,7 @@ This [tutorial](https://aws.amazon.com/blogs/opensource/managing-eks-clusters-ra
|
||||
|
||||
## Minimum EKS Permissions
|
||||
|
||||
These are the minimum set of permissions necessary to access the full functionality of Rancher's EKS driver. You'll need additional permissions for Rancher to provision the `Service Role` and `VPC` resources. If you create these resources **before** you create the cluster, they'll be available when you configure the cluster.
|
||||
These are the minimum set of permissions necessary to access the full functionality of Rancher's EKS driver. These permissions allow Rancher to create the Service Role and Virtual Private Cloud (VPC) resources on the users' behalf, if necessary.
|
||||
|
||||
:::note
|
||||
In EKS v1.23 and above, you must use the out-of-tree drivers for EBS-backed volumes. You need [specific permissions](#ebs-csi-driver-addon-permissions) to enable this add-on.
|
||||
@@ -101,133 +101,66 @@ In EKS v1.23 and above, you must use the out-of-tree drivers for EBS-backed volu
|
||||
|
||||
Resource | Description
|
||||
---------|------------
|
||||
Service Role | Provides permissions that allow Kubernetes to manage resources on your behalf. Rancher can create the service role with the following [Service Role Permissions](#service-role-permissions).
|
||||
VPC | Provides isolated network resources utilised by EKS and worker nodes. Rancher can create the VPC resources with the following [VPC Permissions](#vpc-permissions).
|
||||
EBS CSI Driver add-on | Provides permissions that allow Kubernetes to interact with EBS and configure the cluster to enable the add-on (required for EKS v1.23 and above). Rancher can install the add-on with the following [EBS CSI Driver addon Permissions](#ebs-csi-driver-addon-permissions).
|
||||
|
||||
|
||||
Resource targeting uses `*` as the ARN of many of the resources created cannot be known before creating the EKS cluster in Rancher.
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "EC2Permissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:RunInstances",
|
||||
"ec2:RevokeSecurityGroupIngress",
|
||||
"ec2:RevokeSecurityGroupEgress",
|
||||
"ec2:DescribeInstanceTypes",
|
||||
"ec2:DescribeRegions",
|
||||
"ec2:DescribeVpcs",
|
||||
"ec2:DescribeTags",
|
||||
"ec2:DescribeSubnets",
|
||||
"ec2:DescribeSecurityGroups",
|
||||
"ec2:DescribeRouteTables",
|
||||
"ec2:DescribeLaunchTemplateVersions",
|
||||
"ec2:DescribeLaunchTemplates",
|
||||
"ec2:DescribeKeyPairs",
|
||||
"ec2:DescribeInternetGateways",
|
||||
"ec2:DescribeImages",
|
||||
"ec2:DescribeAvailabilityZones",
|
||||
"ec2:DescribeAccountAttributes",
|
||||
"ec2:DeleteTags",
|
||||
"ec2:DeleteLaunchTemplateVersions",
|
||||
"ec2:DeleteLaunchTemplate",
|
||||
"ec2:DeleteSecurityGroup",
|
||||
"ec2:DeleteKeyPair",
|
||||
"ec2:CreateTags",
|
||||
"ec2:CreateSecurityGroup",
|
||||
"ec2:CreateLaunchTemplateVersion",
|
||||
"ec2:CreateLaunchTemplate",
|
||||
"ec2:CreateKeyPair",
|
||||
"ec2:AuthorizeSecurityGroupIngress",
|
||||
"ec2:AuthorizeSecurityGroupEgress"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "CloudFormationPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"cloudformation:ListStacks",
|
||||
"cloudformation:ListStackResources",
|
||||
"cloudformation:DescribeStacks",
|
||||
"cloudformation:DescribeStackResources",
|
||||
"cloudformation:DescribeStackResource",
|
||||
"cloudformation:DeleteStack",
|
||||
"cloudformation:CreateStackSet",
|
||||
"cloudformation:CreateStack"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "IAMPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"iam:PassRole",
|
||||
"iam:ListRoles",
|
||||
"iam:ListRoleTags",
|
||||
"iam:ListInstanceProfilesForRole",
|
||||
"iam:ListInstanceProfiles",
|
||||
"iam:ListAttachedRolePolicies",
|
||||
"iam:GetRole",
|
||||
"iam:GetInstanceProfile",
|
||||
"iam:DetachRolePolicy",
|
||||
"iam:DeleteRole",
|
||||
"iam:CreateRole",
|
||||
"iam:AttachRolePolicy"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "KMSPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": "kms:ListKeys",
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "EKSPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"eks:UpdateNodegroupVersion",
|
||||
"eks:UpdateNodegroupConfig",
|
||||
"eks:UpdateClusterVersion",
|
||||
"eks:UpdateClusterConfig",
|
||||
"eks:UntagResource",
|
||||
"eks:TagResource",
|
||||
"eks:ListUpdates",
|
||||
"eks:ListTagsForResource",
|
||||
"eks:ListNodegroups",
|
||||
"eks:ListFargateProfiles",
|
||||
"eks:ListClusters",
|
||||
"eks:DescribeUpdate",
|
||||
"eks:DescribeNodegroup",
|
||||
"eks:DescribeFargateProfile",
|
||||
"eks:DescribeCluster",
|
||||
"eks:DeleteNodegroup",
|
||||
"eks:DeleteFargateProfile",
|
||||
"eks:DeleteCluster",
|
||||
"eks:CreateNodegroup",
|
||||
"eks:CreateFargateProfile",
|
||||
"eks:CreateCluster"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Service Role Permissions
|
||||
|
||||
These are permissions that are needed during EKS cluster creation, so Rancher can create a service role on the users' behalf.
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "EC2Permissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:AuthorizeSecurityGroupEgress",
|
||||
"ec2:AuthorizeSecurityGroupIngress",
|
||||
"ec2:CreateKeyPair",
|
||||
"ec2:CreateLaunchTemplate",
|
||||
"ec2:CreateLaunchTemplateVersion",
|
||||
"ec2:CreateSecurityGroup",
|
||||
"ec2:CreateTags",
|
||||
"ec2:DeleteKeyPair",
|
||||
"ec2:DeleteLaunchTemplate",
|
||||
"ec2:DeleteLaunchTemplateVersions",
|
||||
"ec2:DeleteSecurityGroup",
|
||||
"ec2:DeleteTags",
|
||||
"ec2:DescribeAccountAttributes",
|
||||
"ec2:DescribeAvailabilityZones",
|
||||
"ec2:DescribeImages",
|
||||
"ec2:DescribeInternetGateways",
|
||||
"ec2:DescribeInstanceTypes",
|
||||
"ec2:DescribeKeyPairs",
|
||||
"ec2:DescribeLaunchTemplateVersions",
|
||||
"ec2:DescribeLaunchTemplates",
|
||||
"ec2:DescribeRegions",
|
||||
"ec2:DescribeRouteTables",
|
||||
"ec2:DescribeSecurityGroups",
|
||||
"ec2:DescribeSubnets",
|
||||
"ec2:DescribeTags",
|
||||
"ec2:DescribeVpcs",
|
||||
"ec2:RevokeSecurityGroupEgress",
|
||||
"ec2:RevokeSecurityGroupIngress",
|
||||
"ec2:RunInstances"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "CloudFormationPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"cloudformation:CreateStack",
|
||||
"cloudformation:CreateStackSet",
|
||||
"cloudformation:DeleteStack",
|
||||
"cloudformation:DescribeStackResource",
|
||||
"cloudformation:DescribeStackResources",
|
||||
"cloudformation:DescribeStacks",
|
||||
"cloudformation:ListStackResources",
|
||||
"cloudformation:ListStacks"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "IAMPermissions",
|
||||
"Effect": "Allow",
|
||||
@@ -248,7 +181,70 @@ These are permissions that are needed during EKS cluster creation, so Rancher ca
|
||||
"iam:ListRoles",
|
||||
"iam:ListRoleTags",
|
||||
"iam:PassRole",
|
||||
"iam:RemoveRoleFromInstanceProfile"
|
||||
"iam:RemoveRoleFromInstanceProfile",
|
||||
"iam:TagRole"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "KMSPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": "kms:ListKeys",
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "EKSPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"eks:CreateCluster",
|
||||
"eks:CreateFargateProfile",
|
||||
"eks:CreateNodegroup",
|
||||
"eks:DeleteCluster",
|
||||
"eks:DeleteFargateProfile",
|
||||
"eks:DeleteNodegroup",
|
||||
"eks:DescribeAddon",
|
||||
"eks:DescribeCluster",
|
||||
"eks:DescribeFargateProfile",
|
||||
"eks:DescribeNodegroup",
|
||||
"eks:DescribeUpdate",
|
||||
"eks:ListClusters",
|
||||
"eks:ListFargateProfiles",
|
||||
"eks:ListNodegroups",
|
||||
"eks:ListTagsForResource",
|
||||
"eks:ListUpdates",
|
||||
"eks:TagResource",
|
||||
"eks:UntagResource",
|
||||
"eks:UpdateClusterConfig",
|
||||
"eks:UpdateClusterVersion",
|
||||
"eks:UpdateNodegroupConfig",
|
||||
"eks:UpdateNodegroupVersion"
|
||||
],
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Sid": "VPCPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:AssociateRouteTable",
|
||||
"ec2:AttachInternetGateway",
|
||||
"ec2:CreateInternetGateway",
|
||||
"ec2:CreateRoute",
|
||||
"ec2:CreateRouteTable",
|
||||
"ec2:CreateSecurityGroup",
|
||||
"ec2:CreateSubnet",
|
||||
"ec2:CreateVpc",
|
||||
"ec2:DeleteInternetGateway",
|
||||
"ec2:DeleteRoute",
|
||||
"ec2:DeleteRouteTable",
|
||||
"ec2:DeleteSubnet",
|
||||
"ec2:DeleteTags",
|
||||
"ec2:DeleteVpc",
|
||||
"ec2:DescribeVpcs",
|
||||
"ec2:DetachInternetGateway",
|
||||
"ec2:DisassociateRouteTable",
|
||||
"ec2:ModifySubnetAttribute",
|
||||
"ec2:ModifyVpcAttribute",
|
||||
"ec2:ReplaceRoute"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
@@ -281,79 +277,33 @@ arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
|
||||
arn:aws:iam::aws:policy/AmazonEKSServicePolicy
|
||||
```
|
||||
|
||||
### VPC Permissions
|
||||
|
||||
These are permissions that are needed by Rancher to create a Virtual Private Cloud (VPC) and associated resources.
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "VPCPermissions",
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"ec2:ReplaceRoute",
|
||||
"ec2:ModifyVpcAttribute",
|
||||
"ec2:ModifySubnetAttribute",
|
||||
"ec2:DisassociateRouteTable",
|
||||
"ec2:DetachInternetGateway",
|
||||
"ec2:DescribeVpcs",
|
||||
"ec2:DeleteVpc",
|
||||
"ec2:DeleteTags",
|
||||
"ec2:DeleteSubnet",
|
||||
"ec2:DeleteRouteTable",
|
||||
"ec2:DeleteRoute",
|
||||
"ec2:DeleteInternetGateway",
|
||||
"ec2:CreateVpc",
|
||||
"ec2:CreateSubnet",
|
||||
"ec2:CreateSecurityGroup",
|
||||
"ec2:CreateRouteTable",
|
||||
"ec2:CreateRoute",
|
||||
"ec2:CreateInternetGateway",
|
||||
"ec2:AttachInternetGateway",
|
||||
"ec2:AssociateRouteTable"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### EBS CSI Driver addon Permissions
|
||||
|
||||
The following are the required permissions for installing the Amazon EBS CSI Driver add-on.
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"iam:GetRole",
|
||||
"eks:DescribeAddonConfiguration",
|
||||
"eks:UpdateAddon",
|
||||
"eks:ListAddons",
|
||||
"iam:CreateRole",
|
||||
"iam:AttachRolePolicy",
|
||||
"eks:DescribeAddon",
|
||||
"iam:CreateOpenIDConnectProvider",
|
||||
"iam:PassRole",
|
||||
"eks:DescribeIdentityProviderConfig",
|
||||
"eks:DeleteAddon",
|
||||
"iam:ListOpenIDConnectProviders",
|
||||
"iam:ListAttachedRolePolicies",
|
||||
"eks:CreateAddon",
|
||||
"eks:DescribeCluster",
|
||||
"eks:DescribeAddonVersions",
|
||||
"sts:AssumeRoleWithWebIdentity",
|
||||
"eks:AssociateIdentityProviderConfig",
|
||||
"eks:ListIdentityProviderConfigs"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"eks:AssociateIdentityProviderConfig",
|
||||
"eks:CreateAddon",
|
||||
"eks:DeleteAddon",
|
||||
"eks:DescribeAddonConfiguration",
|
||||
"eks:DescribeAddonVersions",
|
||||
"eks:DescribeIdentityProviderConfig",
|
||||
"eks:ListAddons",
|
||||
"eks:ListIdentityProviderConfigs",
|
||||
"eks:UpdateAddon",
|
||||
"iam:CreateOpenIDConnectProvider",
|
||||
"iam:ListOpenIDConnectProviders",
|
||||
"sts:AssumeRoleWithWebIdentity"
|
||||
],
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
-1
@@ -31,6 +31,5 @@ Rancher contains a variety of tools that aren't included in Kubernetes to assist
|
||||
- Logging
|
||||
- Monitoring
|
||||
- Istio Service Mesh
|
||||
- OPA Gatekeeper
|
||||
|
||||
Tools can be installed through **Apps.**
|
||||
|
||||
+3
-3
@@ -19,9 +19,9 @@ In order to deploy and run the adapter successfully, you need to ensure its vers
|
||||
|
||||
| Rancher Version | Adapter Version |
|
||||
|-----------------|------------------|
|
||||
| v2.9.2 | v104.0.0+up4.0.0 |
|
||||
| v2.9.1 | v104.0.0+up4.0.0 |
|
||||
| v2.9.0 | v104.0.0+up4.0.0 |
|
||||
| v2.10.2 | v105.0.0+up5.0.1 |
|
||||
| v2.10.1 | v105.0.0+up5.0.1 |
|
||||
| v2.10.0 | v105.0.0+up5.0.1 |
|
||||
|
||||
### 1. Gain Access to the Local Cluster
|
||||
|
||||
|
||||
-3
@@ -61,9 +61,6 @@ Once Prometheus determines that an alert needs to be fired, alerts are forwarded
|
||||
|
||||
- Routes and receivers are also stored in the Kubernetes API via the Alertmanager Secret. When the Secret is updated, Alertmanager is also updated automatically. Note that routing occurs via labels only (not via annotations, etc.).
|
||||
|
||||
<figcaption>How data flows through the monitoring application:</figcaption>
|
||||
|
||||
|
||||
## 2. How Prometheus Works
|
||||
|
||||
### Storing Time Series Data
|
||||
|
||||
@@ -1,117 +0,0 @@
|
||||
---
|
||||
title: OPA Gatekeeper
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/opa-gatekeeper"/>
|
||||
</head>
|
||||
|
||||
<DeprecationOPAGatekeeper link="kubewarden" />
|
||||
|
||||
To ensure consistency and compliance, every organization needs the ability to define and enforce policies in its environment in an automated way. [OPA (Open Policy Agent)](https://www.openpolicyagent.org/) is a policy engine that facilitates policy-based control for cloud native environments. Rancher provides the ability to enable OPA Gatekeeper in Kubernetes clusters, and also installs a couple of built-in policy definitions, which are also called constraint templates.
|
||||
|
||||
OPA provides a high-level declarative language that lets you specify policy as code and ability to extend simple APIs to offload policy decision-making.
|
||||
|
||||
[OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper) is a project that provides integration between OPA and Kubernetes. OPA Gatekeeper provides:
|
||||
|
||||
- An extensible, parameterized policy library.
|
||||
- Native Kubernetes CRDs for instantiating the policy library, also called “constraints."
|
||||
- Native Kubernetes CRDs for extending the policy library, also called "constraint templates."
|
||||
- Audit functionality.
|
||||
|
||||
To read more about OPA, please refer to the [official documentation.](https://www.openpolicyagent.org/docs/latest/)
|
||||
|
||||
## How the OPA Gatekeeper Integration Works
|
||||
|
||||
Kubernetes provides the ability to extend API server functionality via admission controller webhooks, which are invoked whenever a resource is created, updated or deleted. Gatekeeper is installed as a validating webhook and enforces policies defined by Kubernetes custom resource definitions. In addition to the admission control usage, Gatekeeper provides the capability to audit existing resources in Kubernetes clusters and mark current violations of enabled policies.
|
||||
|
||||
OPA Gatekeeper is made available via Rancher's Helm system chart, and it is installed in a namespace named `gatekeeper-system.`
|
||||
|
||||
## Enabling OPA Gatekeeper in a Cluster
|
||||
|
||||
:::note
|
||||
|
||||
In Rancher v2.5, the OPA Gatekeeper application was improved. The Rancher v2.4 feature can't be upgraded to the new version in Rancher v2.5. If you installed OPA Gatekeeper in Rancher v2.4, you will need to uninstall OPA Gatekeeper and its CRDs from the old UI, then reinstall it in Rancher v2.5. To uninstall the CRDs run the following command in the kubectl console `kubectl delete crd configs.config.gatekeeper.sh constrainttemplates.templates.gatekeeper.sh`.
|
||||
|
||||
:::
|
||||
|
||||
:::note Prerequisite:
|
||||
|
||||
Only administrators and cluster owners can enable OPA Gatekeeper.
|
||||
|
||||
:::
|
||||
|
||||
The OPA Gatekeeper Helm chart can be installed from **Apps**.
|
||||
|
||||
### Enabling OPA Gatekeeper
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. In the **Clusters** page, go to the cluster where you want to enable OPA Gatekeeper and click **Explore**.
|
||||
1. In the left navigation bar, click **Apps**.
|
||||
1. Click **Charts** and click **OPA Gatekeeper**.
|
||||
1. Click **Install**.
|
||||
|
||||
**Result:** OPA Gatekeeper is deployed in your Kubernetes cluster.
|
||||
|
||||
## Constraint Templates
|
||||
|
||||
[Constraint templates](https://github.com/open-policy-agent/gatekeeper#constraint-templates) are Kubernetes custom resources that define the schema and Rego logic of the OPA policy to be applied by Gatekeeper. For more information on the Rego policy language, refer to the [official documentation.](https://www.openpolicyagent.org/docs/latest/policy-language/)
|
||||
|
||||
When OPA Gatekeeper is enabled, Rancher installs some templates by default.
|
||||
|
||||
To list the constraint templates installed in the cluster, go to the left side menu under OPA Gatekeeper and click on **Templates**.
|
||||
|
||||
Rancher also provides the ability to create your own constraint templates by importing YAML definitions.
|
||||
|
||||
## Creating and Configuring Constraints
|
||||
|
||||
[Constraints](https://github.com/open-policy-agent/gatekeeper#constraints) are Kubernetes custom resources that define the scope of objects to which a specific constraint template applies to. The complete policy is defined by constraint templates and constraints together.
|
||||
|
||||
:::note Prerequisite:
|
||||
|
||||
OPA Gatekeeper must be enabled in the cluster.
|
||||
|
||||
:::
|
||||
|
||||
To list the constraints installed, go to the left side menu under OPA Gatekeeper, and click on **Constraints**.
|
||||
|
||||
New constraints can be created from a constraint template.
|
||||
|
||||
Rancher provides the ability to create a constraint by using a convenient form that lets you input the various constraint fields.
|
||||
|
||||
The **Edit as yaml** option is also available to configure the the constraint's yaml definition.
|
||||
|
||||
### Exempting Rancher's System Namespaces from Constraints
|
||||
|
||||
When a constraint is created, ensure that it does not apply to any Rancher or Kubernetes system namespaces. If the system namespaces are not excluded, then it is possible to see many resources under them marked as violations of the constraint.
|
||||
|
||||
To limit the scope of the constraint only to user namespaces, always specify these namespaces under the **Match** field of the constraint.
|
||||
|
||||
Also, the constraint may interfere with other Rancher functionality and deny system workloads from being deployed. To avoid this, exclude all Rancher-specific namespaces from your constraints.
|
||||
|
||||
## Enforcing Constraints in your Cluster
|
||||
|
||||
When the **Enforcement Action** is **Deny,** the constraint is immediately enabled and will deny any requests that violate the policy defined. By default, the enforcement value is **Deny**.
|
||||
|
||||
When the **Enforcement Action** is **Dryrun,** then any resources that violate the policy are only recorded under the constraint's status field.
|
||||
|
||||
To enforce constraints, create a constraint using the form. In the **Enforcement Action** field, choose **Deny**.
|
||||
|
||||
## Audit and Violations in your Cluster
|
||||
|
||||
OPA Gatekeeper runs a periodic audit to check if any existing resource violates any enforced constraint. The audit-interval (default 300s) can be configured while installing Gatekeeper.
|
||||
|
||||
On the Gatekeeper page, any violations of the defined constraints are listed.
|
||||
|
||||
Also under **Constraints,** the number of violations of the constraint can be found.
|
||||
|
||||
The detail view of each constraint lists information about the resource that violated the constraint.
|
||||
|
||||
## Disabling Gatekeeper
|
||||
|
||||
1. Navigate to the cluster's Dashboard view
|
||||
1. On the left side menu, expand the cluster menu and click on **OPA Gatekeeper**.
|
||||
1. Click the **⋮ > Disable**.
|
||||
|
||||
**Result:** Upon disabling OPA Gatekeeper, all constraint templates and constraints will also be deleted.
|
||||
|
||||
+1
-1
@@ -139,5 +139,5 @@ At high scale, Rancher transfers more data from the upstream cluster to UI compo
|
||||
For best performance, ensure that the host running the hardware meets these requirements:
|
||||
- 2020 i5 10th generation Intel (4 cores) or equivalent
|
||||
- 8 GB RAM
|
||||
- Total network bandwith to the upstream cluster: 72 Mb/s (equivalent to a single 802.11n Wi-Fi 4 link stream, ~8 MB/s http download throughput)
|
||||
- Total network bandwidth to the upstream cluster: 72 Mb/s (equivalent to a single 802.11n Wi-Fi 4 link stream, ~8 MB/s http download throughput)
|
||||
- Round-trip time (ping time) from browser to upstream cluster: 150 ms or less
|
||||
|
||||
+1
-1
@@ -8,7 +8,7 @@ title: AKS Cluster Configuration Reference
|
||||
|
||||
## Role-based Access Control
|
||||
|
||||
When provisioning an AKS cluster in the Rancher UI, RBAC cannot be disabled. If role-based access control is disabled for the cluster in AKS, the cluster cannot be registered or imported into Rancher.
|
||||
When provisioning an AKS cluster in the Rancher UI, RBAC cannot be disabled. If role-based access control is disabled for the cluster in AKS, the cluster cannot be registered or imported into Rancher. In practice, this means that local accounts must be enabled in order to register an AKS cluster.
|
||||
|
||||
Rancher can configure member roles for AKS clusters in the same way as any other cluster. For more information, see the section on [role-based access control.](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)
|
||||
|
||||
|
||||
@@ -42,12 +42,6 @@ Rancher's integration with Istio was improved in Rancher v2.5.
|
||||
|
||||
For more information, refer to the Istio documentation [here.](../integrations-in-rancher/istio/istio.md)
|
||||
|
||||
## OPA Gatekeeper
|
||||
|
||||
<DeprecationOPAGatekeeper link="../integrations-in-rancher/kubewarden" />
|
||||
|
||||
[OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper) is an open-source project that provides integration between OPA and Kubernetes to provide policy control via admission controller webhooks. For details on how to enable Gatekeeper in Rancher, refer to the [OPA Gatekeeper section.](../integrations-in-rancher/opa-gatekeeper.md)
|
||||
|
||||
## CIS Scans
|
||||
|
||||
Rancher can run a security scan to check whether Kubernetes is deployed according to security best practices as defined in the CIS Kubernetes Benchmark.
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user