public/rancher-docs
1
0
Fork 0
mirror of https://github.com/rancher/rancher-docs.git synced 2026-09-24 20:18:18 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translate v2.7 and v2.6 docs

Browse Source
This commit is contained in:
vickyhella
2023-05-12 17:45:17 +08:00
parent f6ab15291d
commit 217a159889
113 changed files with 31002 additions and 14352 deletions
Download Patch File Download Diff File Expand all files Collapse all files
i18n/zh/docusaurus-plugin-content-docs/current.json
+19 -11
View File
@@ -307,10 +307,6 @@
"message": "Rancher 安全",
"description": "The label for category Rancher Security in sidebar tutorialSidebar"
},
"sidebar.tutorialSidebar.category.Rancher v2.6 Hardening Guides": {
"message": "Rancher 2.6 强化指南",
"description": "The label for category Rancher v2.6 Hardening Guides in sidebar tutorialSidebar"
},
"sidebar.tutorialSidebar.category.SELinux RPM": {
"message": "SELinux RPM",
"description": "The label for category SELinux RPM in sidebar tutorialSidebar"
@@ -331,10 +327,6 @@
"message": "CIS 扫描",
"description": "The label for category CIS Scans in sidebar tutorialSidebar"
},
"sidebar.tutorialSidebar.category.Fleet - GitOps at Scale": {
"message": "Fleet - 大规模的 GitOps",
"description": "The label for category Fleet - GitOps at Scale in sidebar tutorialSidebar"
},
"sidebar.tutorialSidebar.category.Istio": {
"message": "Istio",
"description": "The label for category Istio in sidebar tutorialSidebar"
@@ -371,8 +363,24 @@
"message": "其他故障排除提示",
"description": "The label for category Other Troubleshooting Tips in sidebar tutorialSidebar"
},
"sidebar.tutorialSidebar.category.Rancher v2.7 Hardening Guides": {
"message": "Rancher v2.7 强化指南",
"description": "The label for category Rancher v2.7 Hardening Guides in sidebar tutorialSidebar"
"sidebar.tutorialSidebar.category.Hardening Guides": {
"message": "加固指南",
"description": "The label for category Hardening Guides in sidebar tutorialSidebar"
},
"sidebar.tutorialSidebar.category.RKE Hardening Guides": {
"message": "RKE 加固指南",
"description": "The label for category RKE Hardening Guides in sidebar tutorialSidebar"
},
"sidebar.tutorialSidebar.category.RKE2 Hardening Guides": {
"message": "RKE2 加固指南",
"description": "The label for category RKE2 Hardening Guides in sidebar tutorialSidebar"
},
"sidebar.tutorialSidebar.category.K3s Hardening Guides": {
"message": "K3s 加固指南",
"description": "The label for category K3s Hardening Guides in sidebar tutorialSidebar"
},
"sidebar.tutorialSidebar.category.Continuous Delivery with Fleet": {
"message": "使用 Fleet 进行持续交付",
"description": "The label for category Continuous Delivery with Fleet in sidebar tutorialSidebar"
}
}
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-aks.md
+14 -3
View File
@@ -50,7 +50,7 @@ az group create --name rancher-rg --location eastus
:::note
如果 Kubernetes 的版本更新到 v1.22 或更高版本，则 ingress-nginx 的版本也需要[更新](https://kubernetes.github.io/ingress-nginx/user-guide/k8s-122-migration/)。
如果你要从旧的 Kubernetes 版本更新到 Kubernetes v1.22 或更高版本，你还需要[更新](https://kubernetes.github.io/ingress-nginx/user-guide/k8s-122-migration/) ingress-nginx。
:::
@@ -79,16 +79,27 @@ az aks get-credentials --resource-group rancher-rg --name rancher-server
集群需要一个 Ingress，以从集群外部访问 Rancher。要 Ingress，你需要分配一个公共 IP 地址。请确保你有足够的配额，否则它将无法分配 IP 地址。公共 IP 地址的限制在每个订阅的区域级别生效。
以下命令安装了带有 Kubernetes 负载均衡器服务的 `nginx-ingress-controller`。
为确保你选择了正确的 Ingress-NGINX Helm Chart，首先在 [Kubernetes/ingress-nginx 支持表](https://github.com/kubernetes/ingress-nginx#supported-versions-table)中找到与你的 Kubernetes 版本兼容的 `Ingress-NGINX 版本`。
然后，运行以下命令列出可用的 Helm Chart：
```
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
helm search repo ingress-nginx -l
```
`helm search` 命令的输出包含一个 `APP VERSION` 列。此列下的版本等同于你之前选择的 `Ingress-NGINX 版本`。使用应用程序版本，选择一个 Chart 版本，该版本打包了与你的 Kubernetes 兼容的应用程序。例如，如果使用的是 Kubernetes v1.24，则可以选择 v4.6.0 Helm Chart，因为 Ingress-NGINX v1.7.0 与该 Chart 打包在一起，而 v1.7.0 与 Kubernetes v1.24 兼容。如有疑问，请选择最新的兼容版本。
了解你需要的 Helm chart `版本`后，运行以下命令。它安装一个带有 Kubernetes 负载均衡器服务的 `nginx-ingress-controller`：
```
helm search repo ingress-nginx -l
helm upgrade --install \
ingress-nginx ingress-nginx/ingress-nginx \
--namespace ingress-nginx \
--set controller.service.type=LoadBalancer \
--version 4.0.18 \
--version 4.6.0 \
--create-namespace
```
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks.md
+13 -3
View File
@@ -79,7 +79,7 @@ aws configure
运行以下命令创建一个 EKS 集群。使用适用于你的用例的 AWS 区域。在选择 Kubernetes 版本时，请务必先查阅[支持矩阵](https://rancher.com/support-matrix/)，以找出已针对你的 Rancher 版本验证的最新 Kubernetes 版本。
**注意**：如果 Kubernetes 的版本更新到 v1.22 或更高版本，则 ingress-nginx 的版本也需要[更新](https://kubernetes.github.io/ingress-nginx/user-guide/k8s-122-migration/)。
**注意**：如果你要从旧的 Kubernetes 版本更新到 Kubernetes v1.22 或更高版本，你还需要[更新](https://kubernetes.github.io/ingress-nginx/user-guide/k8s-122-migration/) ingress-nginx。
```
eksctl create cluster \
@@ -117,16 +117,26 @@ rancher-server-cluster us-west-2 True
集群需要一个 Ingress，以从集群外部访问 Rancher。
以下命令安装了一个 `nginx-ingress-controller`和一个 LoadBalancer 服务。因此，NGINX 前面会有一个 ELB（Elastic Load Balancer）：
为确保你选择了正确的 Ingress-NGINX Helm Chart，首先在 [Kubernetes/ingress-nginx 支持表](https://github.com/kubernetes/ingress-nginx#supported-versions-table)中找到与你的 Kubernetes 版本兼容的 `Ingress-NGINX 版本`。
然后，运行以下命令列出可用的 Helm Chart：
```
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
helm search repo ingress-nginx -l
```
`helm search` 命令的输出包含一个 `APP VERSION` 列。此列下的版本等同于你之前选择的 `Ingress-NGINX 版本`。使用应用程序版本，选择一个 Chart 版本，该版本打包了与你的 Kubernetes 兼容的应用程序。例如，如果使用的是 Kubernetes v1.23，则可以选择 v4.6.0 Helm Chart，因为 Ingress-NGINX v1.7.0 与该 Chart 打包在一起，而 v1.7.0 与 Kubernetes v1.23 兼容。如有疑问，请选择最新的兼容版本。
了解你需要的 Helm chart `版本`后，运行以下命令。它安装一个带有 Kubernetes 负载均衡器服务的 `nginx-ingress-controller`：
```
helm upgrade --install \
ingress-nginx ingress-nginx/ingress-nginx \
--namespace ingress-nginx \
--set controller.service.type=LoadBalancer \
--version 4.0.18 \
--version 4.6.0 \
--create-namespace
```
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-gke.md
+1 -1
View File
@@ -120,7 +120,7 @@ Your active configuration is: [default]
要使用 Rancher 成功创建 GKE 集群，GKE 必须处于 Standard 模式。GKE 在创建 Kubernetes 集群时有两种运行模式，分别是 Autopilot 和 Standard 模式。Autopilot 模式的集群配置对编辑 kube-system 命名空间有限制。但是，Rancher 在安装时需要在 kube-system 命名空间中创建资源。因此，你将无法在以 Autopilot 模式创建的 GKE 集群上安装 Rancher。如需详细了解 GKE Autopilot 模式和 Standard 模式之间的差异，请访问[比较 GKE Autopilot 和 Standard ](https://cloud.google.com/kubernetes-engine/docs/resources/autopilot-standard-feature-comparison)。
**注意**：如果 Kubernetes 的版本更新到 v1.22 或更高版本，则 ingress-nginx 的版本也需要[更新](https://kubernetes.github.io/ingress-nginx/user-guide/k8s-122-migration/)。
**注意**：如果你要从旧的 Kubernetes 版本更新到 Kubernetes v1.22 或更高版本，你还需要[更新](https://kubernetes.github.io/ingress-nginx/user-guide/k8s-122-migration/) ingress-nginx。
```
gcloud container clusters create cluster-name --num-nodes=3 --cluster-version=<VERSION>
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-psact.yaml
+37
View File
@@ -0,0 +1,37 @@
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- configuration:
apiVersion: pod-security.admission.config.k8s.io/v1
defaults:
audit: restricted
audit-version: latest
enforce: restricted
enforce-version: latest
warn: restricted
warn-version: latest
exemptions:
namespaces:
- ingress-nginx
- kube-system
- cattle-system
- cattle-epinio-system
- cattle-fleet-system
- longhorn-system
- cattle-neuvector-system
- cattle-monitoring-system
- rancher-alerting-drivers
- cis-operator-system
- cattle-csp-adapter-system
- cattle-externalip-system
- cattle-gatekeeper-system
- istio-system
- cattle-istio-system
- cattle-logging-system
- cattle-windows-gmsa-system
- cattle-sriov-system
- cattle-ui-plugin-system
- tigera-operator
kind: PodSecurityConfiguration
name: PodSecurity
path: ""
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrade-a-hardened-cluster-to-k8s-v1-25.md
+68
View File
@@ -0,0 +1,68 @@
---
title: 将加固的自定义/导入集群升级到 Kubernetes v1.25
---
Kubernetes v1.25 改变了集群描述和执行安全策略的方式。从这个版本开始，[Pod 安全策略 (PSP)](https://kubernetes.io/docs/concepts/security/pod-security-policy/)不再可用。Kubernetes v1.25 将它们替换为新的安全对象：[Pod 安全标准 (PSS)](https://kubernetes.io/docs/concepts/security/pod-security-standards/) 和 [Pod 安全准入 (PSA)](https://kubernetes.io/docs/concepts/security/pod-security-admission/)。
如果你具有自定义或导入的加固集群，你需要做好准备，确保将旧版本的 Kubernetes 顺利升级到 v1.25 或更高版本。
:::note
升级到 v1.25 后，添加必要的 Rancher 命名空间豁免。有关详细信息，请参阅 [Pod 安全准入 (PSA) 配置模板](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/psa-config-templates.md#豁免必须的-rancher-命名空间)。
:::
## 将导入的加固集群升级到 Kubernetes v1.25 或更高版本
<Tabs groupId="k8s-distro">
<TabItem value="RKE2" default>
在集群中的每个节点上执行以下操作：
1. 将 [`rancher-psact.yaml`](./rancher-psact.yaml) 保存到 `/etc/rancher/rke2` 中。
1. 编辑 RKE2 配置文件：
1. 将 `profile` 字段更新为 `cis-1.23`。
1. 指定刚才添加的配置文件的路径：`pod-security-admission-config-file: /etc/rancher/rke2/rancher-psact.yaml`。
</TabItem>
<TabItem value="K3s">
在集群中的每个节点上执行以下操作：
遵循 K3s [将加固集群从 v1.24.x 升级到 v1.25.x](https://docs.k3s.io/known-issues#hardened-125)的官方说明，但使用[自定义](./rancher-psact.yaml)Rancher PSA 配置模板，而不是 K3s 官方网站上提供的配置。
</TabItem>
</Tabs>
执行这些步骤后，你可以通过 Rancher UI 升级集群的 Kubernetes 版本：
1. 在左上角，单击 **☰ > 集群管理**。
1. 在**集群**表中找到要更新的集群，点击 **⋮**。
1. 选择**编辑配置**。
1. 在 **Kubernetes 版本**下拉菜单中，选择要使用的版本。
1. 单击**保存**。
## 将自定义加固集群升级到 Kubernetes v1.25 或更高版本
<Tabs groupId="k8s-distro">
<TabItem value="RKE2" default>
1. 在左上角，单击 **☰ > 集群管理**。
1. 在**集群**表中找到要更新的集群，点击 **⋮**。
1. 选择**编辑配置**。
1. 在**基本信息 > 安全**下的 **CIS 配置文件**下拉菜单中，选择 `cis-1.23`。
1. 在 **PSA 配置模板**下拉菜单中，选择 `rancher-restricted`。
1. 在 **Kubernetes 版本**下拉菜单中，选择要使用的版本。
1. 单击**保存**。
</TabItem>
<TabItem value="K3s">
1. 在左上角，单击 **☰ > 集群管理**。
1. 在**集群**表中找到要更新的集群，点击 **⋮**。
1. 选择**编辑 YAML**。
1. 从 `kube-apiserver-arg.enable-admission-plugins` 中删除 `PodSecurityPolicy`。
1. 在 `spec` 字段中，添加一行：`defaultPodSecurityAdmissionConfigurationTemplateName: rancher-restricted`
1. 将 `kubernetesVersion` 更新为你选择的版本（v1.25 或更高版本）。
1. 单击**保存**。
</TabItem>
</Tabs>
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades.md
+16 -8
View File
@@ -137,7 +137,9 @@ hostname: rancher.my.org
保留你的所有设置把 Rancher 升级到最新版本。
将上一步中的所有值用 `--set key=value`追加到命令中。
将上一步中的所有值用 `--set key=value` 追加到命令中。
对于 Kubernetes v1.25 或更高版本，将 `global.cattle.psp.enabled` 设置为 `false`。
```
helm upgrade rancher rancher-<CHART_REPO>/rancher \
@@ -153,14 +155,20 @@ helm upgrade rancher rancher-<CHART_REPO>/rancher \
另外，你也可以将当前的值导出到一个文件中，并在升级时引用该文件。例如，如果你只需要改变 Rancher 的版本：
```
helm get values rancher -n cattle-system -o yaml > values.yaml
1. 将当前值导出到文件：
```
helm get values rancher -n cattle-system -o yaml > values.yaml
```
1. 只更新 Rancher 版本：
helm upgrade rancher rancher-<CHART_REPO>/rancher \
--namespace cattle-system \
-f values.yaml \
--version=2.6.8
```
对于 Kubernetes v1.25 或更高版本，将 `global.cattle.psp.enabled` 设置为 `false`。
```
helm upgrade rancher rancher-<CHART_REPO>/rancher \
--namespace cattle-system \
-f values.yaml \
--version=2.6.8
```
### 4. 验证升级
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/installation-references/feature-flags.md
+25 -29
View File
@@ -2,42 +2,38 @@
title: 功能开关
---
为了让你试用默认关闭的实验功能，我们引入了功能开关（feature flag）。
使用功能开关（Feature Flag），你可以试用可选或实验性的功能并启用正在逐步淘汰的旧版功能。
如需了解功能的值以及如何启用功能，请参阅[此处](../../../pages-for-subheaders/enable-experimental-features.md)。
要了解功能的值以及如何启用它们，请参阅[启用实验性功能](../../../pages-for-subheaders/enable-experimental-features.md)。
:::note
某些功能需要重启 Rancher Server 容器才能生效。我们在文档的表格和 UI 中对这些功能进行了标记。
某些功能要求重新启动 Rancher 容器。Rancher UI 中标记了要求重启的功能。
:::
以下是 Rancher 中可用的功能开关列表：
以下是 Rancher 中可用的功能开关列表。如果你是从旧 Rancher 版本升级的，你可能会在 Rancher UI 中看到其他功能，例如 `proxy` 或 `dashboard`（均[已中断](/versioned_docs/version-2.5/reference-guides/installation-references/feature-flags.md)）：
- `harvester`：从 2.6.1 开始可用。Harvester 用于管理 Virtualization Management 页面的访问。用户可以在该页面直接导航到 Harvester 集群并访问 Harvester UI。详情请参见[本页](../../../integrations-in-rancher/harvester.md#功能开关)。
- `rke2`：用于启用配置 RKE2 集群的功能。这个功能开关默认开启，即允许用户尝试配置此类集群。
- `fleet`：由于 Fleet 功能已应用到新的配置框架中，因此我们需要启用先前的 `fleet` 功能开关。如果你在早期版本中禁用了此功能开关，升级到 Rancher 2.6 后，该功能开关会自动启用。详情请参见[此页](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md)。
- `continuous-delivery`：在 Rancher v2.5.x 中，Fleet 带有 GitOps 功能，该功能不能与 Fleet 分开禁用。在 Rancher 2.6 中，我们引入了 `continuous-delivery` 功能开关，让你可以单独禁用 Fleet 的 GitOps 功能。如需更多信息，请参阅[此页面](../../../how-to-guides/advanced-user-guides/enable-experimental-features/continuous-delivery.md)。
- `legacy`：Rancher 会逐渐淘汰之前版本中的某些功能，以实现功能迭代。此处包括已弃用，以及之后会转移到其他地方的功能。默认情况下，新安装会禁用此功能开关。如果你从先前的版本升级，此功能开关会启用。
- `token-hashing`：用于启动新的 token-hashing 功能。启用后，会使用 SHA256 算法对现有 Token 和所有新 Token 进行哈希处理。一旦对 Token 进行哈希处理，就无法撤消操作。该功能开关启用后无法被禁用。详情请参见[哈西处理 Token](../../../reference-guides/about-the-api/api-tokens.md)。
- `unsupported-storage-drivers`：该功能[允许使用不支持的存储驱动](../../../how-to-guides/advanced-user-guides/enable-experimental-features/unsupported-storage-drivers.md)。换言之，此功能允许你使用默认情况下未启用的存储提供商和卷插件。
- `istio-virtual-service-ui`：此功能让你[启动用于管理 Istio 流量的 UI，其中包括创建、读取、更新和删除 Istio 虚拟服务（Virtual Service）和目标规则（Destination Rule）](../../../how-to-guides/advanced-user-guides/enable-experimental-features/istio-traffic-management-features.md)。
- `multi-cluster-management`：用于配置和管理多个 Kubernetes 集群。此功能开关只能在安装时设置，之后不能更改。
- `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](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md)。
- `harvester`：管理 Virtualization Management 页面的访问。用户可以在该页面直接导航到 Harvester 集群并访问 Harvester UI。有关详细信息，请参阅 [Harvester 集成](../../../integrations-in-rancher/harvester.md)。
- `istio-virtual-service-ui`：启用[可视界面](../../../how-to-guides/advanced-user-guides/enable-experimental-features/istio-traffic-management-features.md)来创建、读取、更新和删除 Istio 虚拟服务和目标规则，这些都是 Istio 流量管理功能。
- `legacy`：启用 2.5.x 及更早版本的一组功能，这些功能正逐渐被新的实现淘汰。它们是已弃用以及后续可用于新版本的功能组合。新的 Rancher 安装会默认禁用此标志。如果你从以前版本的 Rancher 升级，此标志会启用。
- `multi-cluster-management`：允许配置和管理多个 Kubernetes 集群。此标志只能在安装时设置。后续无法启用或禁用它。
- `rke1-custom-node-cleanup`：清除已删除的 RKE1 自定义节点。建议你启用此标志，以防止已删除的节点尝试重新加入集群。
- `rke2`：启用配置 RKE2 集群。此标志默认启用。
- `token-hashing`：启用令牌哈希。启用后，会使用 SHA256 算法对现有 Token 和所有新 Token 进行哈希处理。一旦对 Token 进行哈希处理，就无法撤消操作。此标志在启用后无法禁用。有关详细信息，请参阅 [API 令牌](../../../reference-guides/about-the-api/api-tokens.md#令牌哈希)。
- `unsupported-storage-drivers`：允许启用非默认启用的存储提供程序和卷插件。有关详细信息，请参阅[允许使用不受支持的存储驱动程序](../../../how-to-guides/advanced-user-guides/enable-experimental-features/unsupported-storage-drivers.md)。
下表介绍了 Rancher 中功能开关的可用版本和默认值：
下表介绍了 Rancher 中功能开关的可用性和默认值。标记为“GA”的功能已普遍可用：
| 功能开关名称 | 默认值 | 状态 | 可用于 | 是否需要重启 Rancher |
| ----------------------------- | ------------- | ------------ | --------------- |---|
| `istio-virtual-service-ui` | `false` | 实验功能 | v2.3.0 | |
| `istio-virtual-service-ui` | `true` | GA* | v2.3.2 | |
| `unsupported-storage-drivers` | `false` | 实验功能 | v2.3.0 | |
| `fleet` | `true` | GA* | v2.5.0 | |
| `fleet` | `true` | 不能禁用 | v2.6.0 | N/A |
| `continuous-delivery` | `true` | GA* | v2.6.0 | |
| `token-hashing` | 新安装：`false`；升级：`true` | GA* | v2.6.0 | |
| `legacy` | 新安装：`false`；升级：`true` | GA* | v2.6.0 | |
| `multi-cluster-management` | `false` | GA* | v2.5.0 | |
| `harvester` | `true` | 实验功能 | v2.6.1 | |
| `rke2` | `true` | 实验功能 | v2.6.0 | |
\* 一般情况下可用。此功能包含在 Rancher 中，不是实验功能的。
| 功能开关名称 | 默认值 | 状态 | 可用于 |
| ----------------------------- | ------------- | ------------ | --------------- |
| `continuous-delivery` | `true` | GA | v2.6.0 |
| `fleet` | `true` | 不能禁用 | v2.6.0 |
| `fleet` | `true` | GA | v2.5.0 |
| `harvester` | `true` | 实验功能 | v2.6.1 |
| `legacy` | 新安装：`false`；升级：`true` | GA | v2.6.0 |
| `rke1-custom-node-cleanup` | `true` | GA | v2.6.0 |
| `rke2` | `true` | 实验功能 | v2.6.0 |
| `token-hashing` | 新安装：`false`；升级：`true` | GA | v2.6.0 |
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/installation-references/helm-chart-options.md
+43 -8
View File
@@ -57,7 +57,7 @@ title: Rancher Helm Chart 选项
| `systemDefaultRegistry` | "" | `string` - 用于所有系统容器镜像的私有仓库，例如 http://registry.example.com/ |
| `tls` | "ingress" | `string` - 详情请参见[外部 TLS 终止](#外部-tls-终止)。- "ingress, external" |
| `useBundledSystemChart` | `false` | `bool` - 选择 Rancher Server 打包的 system-charts。此参数用于离线环境安装。 |
| `global.cattle.psp.enabled` | `true` | `bool` - 选择 "false" 以禁用 RKE/RKE2（K8s）`v1.25` 及以上版本的 PSP。 |
### 引导密码
@@ -92,13 +92,19 @@ kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{
### 额外设置环境变量
你可以使用 `extraEnv` 为 Rancher Server 额外设置环境变量。该列表使用与容器清单定义相同的 `name` 和 `value` 键。记住需要给值加上引号。
你可以使用 `extraEnv` 为 Rancher Server 额外设置环境变量。该列表以 YAML 格式传递给 Rancher 部署，它嵌入在 Rancher 容器的 `env` 下。你可以参考 Kubernetes 文档设置容器环境变量。`extraEnv` 可以使用 [Define Environment Variables for a Container](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/#define-an-environment-variable-for-a-container) 中引用的任何键。
使用 `name` 和 `value` 键的示例：
```plain
--set 'extraEnv[0].name=CATTLE_TLS_MIN_VERSION'
--set 'extraEnv[0].value=1.0'
```
如果将敏感数据（例如代理认证凭证）作为环境变量的值传递，则强烈建议使用 Secret 引用。这将防止敏感数据在 Helm 或 Rancher 部署中暴露。
你可以参考使用 `name`、`valueFrom.secretKeyRef.name` 和 `valueFrom.secretKeyRef.key` 键的示例。详见 [HTTP 代理](#http-代理)中的示例。
### TLS 设置
当你在 Kubernetes 集群内安装 Rancher 时，TLS 会在集群的 Ingress Controller 上卸载。支持的 TLS 设置取决于使用的 Ingress Controller。
@@ -125,7 +131,7 @@ kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{
### 自定义 Ingress
要自定义或使用 Rancher Server 的其他 Ingress，你可以设置自己的 Ingress annotations。
要自定义或使用 Rancher Server 的其他 Ingress，你可以设置自己的 Ingress 注释。
设置自定义证书颁发者的示例：
@@ -133,7 +139,7 @@ kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{
--set ingress.extraAnnotations.'cert-manager\.io/cluster-issuer'=issuer-name
```
以下是使用 `ingress.configurationSnippet`设置静态代理头的实例。该值像模板一样进行解析，因此可以使用变量。
以下是使用 `ingress.configurationSnippet`设置静态代理标头的示例。该值像模板一样进行解析，因此可以使用变量。
```plain
--set ingress.configurationSnippet='more_set_input_headers X-Forwarded-Host {{ .Values.hostname }};'
@@ -141,15 +147,44 @@ kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{
### HTTP 代理
Rancher 的一些功能（Helm Chart）需要使用互联网才能使用。使用 `proxy` 来设置你的代理服务器。
Rancher 的一些功能（Helm Chart）需要使用互联网才能使用。你可以使用 `proxy` 设置代理服务器，或使用 `extraEnv` 设置 `HTTPS_PROXY` 环境变量来指向代理服务器。
在 `noProxy` 列表中添加例外的 IP。确保你已添加了 Pod 集群 IP 范围（默认：`10.42.0.0/16`），服务集群 IP 范围（默认：`10.43.0.0/16`），内部集群域名（默认：`.svc,.cluster.local`）和所有 worker 集群 `controlplane` 节点。Rancher 支持在此列表中使用 CIDR 表示法范围。
将要排除的 IP 使用逗号分隔列表添加到 `noProxy` Chart value 中。确保添加了以下值：
- Pod 集群 IP 范围（默认值：`10.42.0.0/16`）。
- Service Cluster IP 范围（默认值：`10.43.0.0/16`）。
- 内部集群域（默认值：`.svc,.cluster.local`）。
- 任何 Worker 集群 `controlplane` 节点。
Rancher 支持在此列表中使用 CIDR 表示法来表示范围。
不包括敏感数据时，可以使用 `proxy` 或 `extraEnv` Chart 选项。使用 `extraEnv` 时将忽略 `noProxy` Helm 选项。因此，`NO_PROXY` 环境变量也必须设置为 `extraEnv`。
以下是使用 `extraEnv` Chart 选项设置代理的示例：
```plain
--set proxy="http://<username>:<password>@<proxy_url>:<proxy_port>/"
--set noProxy="127.0.0.0/8\,10.0.0.0/8\,172.16.0.0/12\,192.168.0.0/16\,.svc\,.cluster.local"
--set proxy="http://<proxy_url:proxy_port>/"
```
使用 `extraEnv` Chart 选项设置代理的示例：
```plain
--set extraEnv[1].name=HTTPS_PROXY
--set extraEnv[1].value="http://<proxy_url>:<proxy_port>/"
--set extraEnv[2].name=NO_PROXY
--set extraEnv[2].value="127.0.0.0/8\,10.0.0.0/8\,172.16.0.0/12\,192.168.0.0/16\,.svc\,.cluster.local"
```
包含敏感数据（例如代理认证凭证）时，请使用 `extraEnv` 选项和 `valueFrom.secretRef` 来防止敏感数据在 Helm 或 Rancher 部署中暴露。
下面是使用 `extraEnv` 配置代理的示例。此示例 Secret 在 Secret 的 `"https-proxy-url"` 键中包含 `"http://<username>:<password>@<proxy_url>:<proxy_port>/"` 值：
```plain
--set extraEnv[1].name=HTTPS_PROXY
--set extraEnv[1].valueFrom.secretKeyRef.name=secret-name
--set extraEnv[1].valueFrom.secretKeyRef.key=https-proxy-url
--set extraEnv[2].name=NO_PROXY
--set extraEnv[2].value="127.0.0.0/8\,10.0.0.0/8\,172.16.0.0/12\,192.168.0.0/16\,.svc\,.cluster.local"
```
有关如何配置环境变量的更多信息，请参阅[为容器定义环境变量](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/#define-an-environment-variable-for-a-container)。
### 额外的授信 CA
如果你有私有镜像仓库（registries）、应用商店（catalogs）或拦截证书的代理，则可能需要向 Rancher 添加额外的授信 CA。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha.md
+10 -2
View File
@@ -80,7 +80,6 @@ Rancher Server 默认设计为安全的，并且需要 SSL/TLS 配置。
#### 选项 A：使用 Rancher 默认的自签名证书
默认情况下，Rancher 会生成一个 CA 并使用 cert-manager 颁发证书以访问 Rancher Server 界面。
:::note
@@ -112,7 +111,6 @@ v2.6.4 兼容 cert-manager 版本 1.6.2 和 1.7.1。推荐使用 v1.7.x，因为
helm fetch jetstack/cert-manager --version v1.11.0
```
##### 3. 检索 Cert-Manager CRD
为 cert-manager 下载所需的 CRD 文件：
@@ -128,6 +126,12 @@ curl -L -o cert-manager-crd.yaml https://github.com/cert-manager/cert-manager/re
使用要用于安装 Chart 的选项来安装 cert-manager。记住要设置 `image.repository` 选项，以从你的私有镜像仓库拉取镜像。此操作会创建一个包含 Kubernetes manifest 文件的 `cert-manager` 目录。
:::note
要查看自定义 cert-manager 安装的选项（包括集群使用 PodSecurityPolicies 的情况），请参阅 [cert-manager 文档](https://artifacthub.io/packages/helm/cert-manager/cert-manager#configuration)。
:::
<details id="install-cert-manager">
<summary>单击展开</summary>
@@ -169,6 +173,8 @@ kubectl create namespace cattle-system
然后安装 Rancher，并声明你选择的选项。参考下表来替换每个占位符。Rancher 需要配置为使用私有镜像仓库，以便配置所有 Rancher 启动的 Kubernetes 集群或 Rancher 工具。
对于 Kubernetes v1.25 或更高版本，将 `global.cattle.psp.enabled` 设置为 `false`。
| 占位符 | 描述 |
------------|-------------
| `<VERSION>` | 输出压缩包的版本号。 |
@@ -198,6 +204,8 @@ kubectl create namespace cattle-system
安装 Rancher，并声明你选择的选项。参考下表来替换每个占位符。Rancher 需要配置为使用私有镜像仓库，以便配置所有 Rancher 启动的 Kubernetes 集群或 Rancher 工具。
对于 Kubernetes v1.25 或更高版本，将 `global.cattle.psp.enabled` 设置为 `false`。
| 占位符 | 描述 |
| -------------------------------- | ----------------------------------------------- |
| `<VERSION>` | 输出压缩包的版本号。 |
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/publish-images.md
-6
View File
@@ -56,12 +56,6 @@ title: '2. 收集镜像并发布到私有仓库'
在 Kubernetes 安装中，如果你使用的是 Rancher 默认的自签名 TLS 证书，则必须将 [`cert-manager`](https://artifacthub.io/packages/helm/cert-manager/cert-manager) 镜像添加到 `rancher-images.txt` 文件中。
:::note
v2.6.4 兼容 cert-manager 版本 1.6.2 和 1.7.1。推荐使用 v1.7.x，因为 v 1.6.x 将在 2022 年 3 月 30 日结束生命周期。
:::
1. 获取最新的 `cert-manager` Helm Chart，并解析模板以获取镜像的详情信息：
:::note
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/installation-and-upgrade/other-installation-methods/rancher-behind-an-http-proxy/install-rancher.md
+6 -6
View File
@@ -30,18 +30,18 @@ kubectl create namespace cert-manager
安装 cert-manager 的 CustomResourceDefinitions：
:::note
v2.6.4 兼容 cert-manager 版本 1.6.2 和 1.7.1。推荐使用 v1.7.x，因为 v 1.6.x 将在 2022 年 3 月 30 日结束生命周期。
:::
```
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml
```
使用 Helm 安装 cert-manager。请注意，cert-manager 还需要你配置代理，以防它需要与 Let's Encrypt 或其他外部证书颁发商进行通信：
:::note
要查看自定义 cert-manager 安装的选项（包括集群使用 PodSecurityPolicies 的情况），请参阅 [cert-manager 文档](https://artifacthub.io/packages/helm/cert-manager/cert-manager#configuration)。
:::
```
helm upgrade --install cert-manager jetstack/cert-manager \
--namespace cert-manager --version v1.11.0 \
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/overview.md
+1 -1
View File
@@ -56,7 +56,7 @@ Rancher API Server 是基于嵌入式 Kubernetes API Server 和 etcd 数据库
对于已有集群而言，可提供的选项和设置取决于你配置集群的方法。例如，只有[通过 RKE 启动](../pages-for-subheaders/launch-kubernetes-with-rancher.md)的集群才有可编辑的**集群选项**。
使用 Rancher 创建集群后，集群管理员可以管理集群成员，开启 Pod 安全策略，管理节点池，以及进行[其他操作](../pages-for-subheaders/cluster-configuration.md)。
使用 Rancher 创建集群后，集群管理员可以管理集群成员，管理节点池，或进行[其他操作](../pages-for-subheaders/cluster-configuration.md)。
下表总结了每一种类型的集群和对应的可编辑的选项和设置：
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/quick-start-guides/deploy-rancher-manager/aws-marketplace.md
+6
View File
@@ -0,0 +1,6 @@
---
title: Rancher AWS Marketplace 快速入门
description: 使用 Amazon EKS 部署 Rancher Server。
---
Amazon Elastic Kubernetes Service (EKS) 可以快速[将 Rancher 部署到 Amazon Web Services (AWS)](https://documentation.suse.com/trd/kubernetes/single-html/gs_rancher_aws-marketplace/)。详情请参见我们的 [Amazon Marketplace 列表](https://aws.amazon.com/marketplace/pp/prodview-go7ent7goo5ae)。观看 [demo](https://youtu.be/9dznJ7Ons0M)，了解 AWS Marketplace SUSE Rancher 设置的演练。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/quick-start-guides/deploy-rancher-manager/aws.md
+1 -1
View File
@@ -52,7 +52,7 @@ AWS 模块只创建一个 EC2 密钥对、一个 EC2 安全组和一个 EC2 实
- `aws_access_key` - 替换为 Amazon AWS 访问密钥
- `aws_secret_key` - 替换为 Amazon AWS Secret 密钥
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码（最少 12 字符）
5. **可选**：修改 `terraform.tfvars` 中的可选参数。参见 [Quickstart Readme](https://github.com/rancher/quickstart) 以及 [AWS Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/aws) 了解更多信息。
建议包括：
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/quick-start-guides/deploy-rancher-manager/azure.md
+1 -1
View File
@@ -39,7 +39,7 @@ description: 阅读此分步 Rancher Azure 指南，以快速部署带有单节
- `azure_client_id` - 替换为 Microsoft Azure 客户端 ID。
- `azure_client_secret` - 替换为 Microsoft Azure 客户端密文。
- `azure_tenant_id` - 替换为 Microsoft Azure 租户 ID。
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码（最少 12 字符）
5. **可选**：修改 `terraform.tfvars` 中的可选参数。
参见 [Quickstart Readme](https://github.com/rancher/quickstart) 以及 [Azure Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/azure) 了解更多信息。建议包括：
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/quick-start-guides/deploy-rancher-manager/digitalocean.md
+1 -1
View File
@@ -33,7 +33,7 @@ description: 阅读此分步 Rancher DigitalOcean 指南，以快速部署带有
4. 编辑 `terraform.tfvars` 文件，并替换以下变量：
- `do_token` - 替换为 DigitalOcean 访问密钥
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码（最少 12 字符）
5. **可选**：修改 `terraform.tfvars` 中的可选参数。
参见 [Quickstart Readme](https://github.com/rancher/quickstart) 以及 [DO Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/do) 了解更多信息。建议包括：
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/quick-start-guides/deploy-rancher-manager/gcp.md
+1 -1
View File
@@ -34,7 +34,7 @@ description: 阅读此分步 Rancher GCP 指南，以快速部署带有单节点
4. 编辑 `terraform.tfvars` 文件，并替换以下变量：
- `gcp_account_json` - 替换为 GCP ServiceAccount 文件路径和文件名。
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码（最少 12 字符）
5. **可选**：修改 `terraform.tfvars` 中的可选参数。
参见 [Quickstart Readme](https://github.com/rancher/quickstart) 以及 [GCP Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/gcp) 了解更多信息。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md
+10
View File
@@ -92,6 +92,12 @@ notepad.exe $env:USERPROFILE\.kube\config
从本地工作站运行以下命令。你需要先安装 [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) 和 [helm](https://helm.sh/docs/intro/install/)：
:::note
要查看自定义 cert-manager 安装的选项（包括集群使用 PodSecurityPolicies 的情况），请参阅 [cert-manager 文档](https://artifacthub.io/packages/helm/cert-manager/cert-manager#configuration)。
:::
```
helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
@@ -119,6 +125,10 @@ helm install cert-manager jetstack/cert-manager `
要安装特定的 Rancher 版本，请使用 `--version` 标志（例如，`--version 2.6.6`）。否则，默认安装最新的 Rancher。请参阅[选择 Rancher 版本](../../installation-and-upgrade/resources/choose-a-rancher-version.md)。
对于 Kubernetes v1.25 或更高版本，将 `global.cattle.psp.enabled` 设置为 `false`。
请注意，密码至少需要 12 个字符。
```
helm install rancher rancher-latest/rancher \
--namespace cattle-system \
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/quick-start-guides/deploy-rancher-manager/hetzner-cloud.md
+1 -1
View File
@@ -33,7 +33,7 @@ description: 阅读此分步 Rancher Hetzner Cloud 指南，以快速部署带
4. 编辑 `terraform.tfvars` 文件，并替换以下变量：
- `hcloud_token` - 替换为 Hetzner API 访问密钥。
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码（最少 12 字符）
5. **可选**：修改 `terraform.tfvars` 中的可选参数。
参见 [Quickstart Readme](https://github.com/rancher/quickstart) 以及 [Hetzner Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/hcloud) 了解更多信息。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/quick-start-guides/deploy-rancher-manager/outscale-qs.md
+1 -1
View File
@@ -34,7 +34,7 @@ description: 阅读此分步 Rancher Outscale 指南，以快速部署带有单
4. 编辑 `terraform.tfvars` 文件，并替换以下变量：
- `access_key_id` - 替换为 Outscale 访问密钥
- `secret_key_id` - 替换为 Outscale 密文密钥
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码（最少 12 字符）
5. **可选**：修改 `terraform.tfvars` 中的可选参数。
参见 [Quickstart Readme](https://github.com/rancher/quickstart) 以及 [Outscale Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/outscale) 了解更多信息。
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/quick-start-guides/deploy-workloads/workload-ingress.md
+1 -1
View File
@@ -19,7 +19,7 @@ title: 部署带有 Ingress 的工作负载
1. 点击 **Deployment**。
1. 为工作负载设置**名称**。
1. 在**容器镜像**字段中，输入 `rancher/hello-world`。注意区分大小写。
1. 点击**添加端口**并在**私有容器端口**字段中输入`80`。通过添加端口，你可以访问集群内外的应用。详情请参见 [Service](../../../pages-for-subheaders/workloads-and-pods.md#services)。
1. 在 `Service Type` 点击 **Add Port** 和 `Cluster IP`，并在 **Private Container Port** 字段中输入`80`。你可以将 `Name` 留空或指定名称。通过添加端口，你可以访问集群内外的应用。有关详细信息，请参阅 [Service](../../../pages-for-subheaders/workloads-and-pods.md#services)。
1. 单击**创建**。
**结果**：
i18n/zh/docusaurus-plugin-content-docs/current/how-to-guides/advanced-user-guides/cis-scan-guides/install-rancher-cis-benchmark.md
+7 -1
View File
@@ -8,4 +8,10 @@ title: 安装 Rancher CIS Benchmark
1. 单击 **CIS Benchmark**。
1. 单击**安装**。
**结果**：CIS 扫描应用已经部署在 Kubernetes 集群上。
**结果**：CIS 扫描应用已经部署在 Kubernetes 集群上。
:::note
CIS Benchmark 4.0.0 及更高版本默认禁用 PSP。要在加固集群上安装 CIS Benchmark，在安装 Chart 之前将 values 中的 `golbal.psp.enabled` 设置为 `true`。
:::
i18n/zh/docusaurus-plugin-content-docs/current/how-to-guides/advanced-user-guides/monitoring-alerting-guides/prometheus-federator-guides/enable-prometheus-federator.md
+6 -1
View File
@@ -75,7 +75,12 @@ matchLabels:
1. 单击 **Prometheus Federator** Chart。
1. 单击**安装**。
1. 在**元数据**页面，点击**下一步**。
1. 在**项目 Release 命名空间项目 ID** 字段中，`System 项目`是默认值，但你可以使用具有类似[有限访问权限](#确保-cattle-monitoring-system-命名空间位于-system-项目中（或者位于一个锁定并能访问集群中其他项目的项目中）)的另一个项目覆盖它。<!-- add info on retrieving project IDs >
1. 在**项目 Release 命名空间项目 ID** 字段中，`System 项目`是默认值，但你可以使用具有类似[有限访问权限](#确保-cattle-monitoring-system-命名空间位于-system-项目中（或者位于一个锁定并能访问集群中其他项目的项目中）)的另一个项目覆盖它。你可以在 local 上游集群中运行以下命令来找到项目 ID：
```plain
kubectl get projects -A -o custom-columns="NAMESPACE":.metadata.namespace,"ID":.metadata.name,"NAME":.spec.displayName
```
1. 单击**安装**。
**结果**：Prometheus Federator 应用程序已部署在 `cattle-monitoring-system` 命名空间中。
i18n/zh/docusaurus-plugin-content-docs/current/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/manage-rke1-templates.md
+1 -1
View File
@@ -146,7 +146,7 @@ title: 创建和修改 RKE 模板
你可以将现有集群的设置保存为 RKE 模板。
这将把集群的设置导出为新的 RKE 模板，并且将集群绑定到该模板。然后，只有[更新了模板](manage-rke1-templates.md#更新模板)并且集群升级到**使用更新版本的模板**时，集群才能改变。
这将把集群的设置导出为新的 RKE 模板，并且将集群绑定到该模板。然后，只有[更新了模板](#更新模板)并且集群升级到[使用更新版本的模板](#升级集群以使用新的模板修订版)时，集群才能改变。
要将现有集群转换为使用 RKE 模板：
i18n/zh/docusaurus-plugin-content-docs/current/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/configure-azure-ad.md
+49 -23
View File
@@ -6,6 +6,8 @@ title: 配置 Azure AD
Microsoft Graph API 现在是设置 Azure AD 的流程。下文将帮助[新用户](#新用户设置)使用新实例来配置 Azure AD，并帮助现有 Azure 应用所有者[迁移到新流程](#从-azure-ad-graph-api-迁移到-microsoft-graph-api)。
Rancher 中的 Microsoft Graph API 流程正在不断发展。建议你使用最新的 2.7 补丁版本，该版本仍在积极开发中，并将持续获得新功能和改进。
### 新用户设置
如果你在 Azure 中托管了一个 Active Directory（AD）实例，你可以将 Rancher 配置为允许你的用户使用 AD 账号登录。你需要在 Azure 和 Rancher 中进行 Azure AD 外部身份验证。
@@ -23,7 +25,7 @@ Microsoft Graph API 现在是设置 Azure AD 的流程。下文将帮助[新用
:::tip
在开始之前，打开两个浏览器选项卡：一个用于 Rancher，一个用于 Azure 门户。这样，你可以轻松将门户的配置值复制并粘贴到 Rancher 中。
在开始之前，打开两个浏览器选项卡：一个用于 Rancher，另一个用于 Azure 门户。这样，你可以将门户的配置值复制并粘贴到 Rancher 中。
:::
@@ -75,13 +77,13 @@ Microsoft Graph API 现在是设置 Azure AD 的流程。下文将帮助[新用
![Open Rancher Registration](/img/open-rancher-app-reg.png)
1. 在左侧的导航窗格中，单击 **Certificates & secrets**。
1. 在导航窗格中，单击 **Certificates & secrets**。
1. 单击 **New client secret**。
![创建新的客户端密文](/img/new-client-secret.png)
1. 输入 **Description**（例如 `Rancher`）。
1. 从 **Expires** 下的选项中选择密钥的持续时间。此下拉菜单设置的是密钥的到期日期。日期越短则越安全，但是在到期后你需要创建新密钥。
请注意，如果应用程序密钥已过期，用户将无法登录 Rancher，因此请在 Azure 中轮换密钥并在其过期前在 Rancher 中进行更新。
1. 从 **Expires** 下的选项中选择持续时间。此下拉菜单设置的是密钥的到期日期。日期越短则越安全，但需要你更频繁地创建新密钥。
请注意，如果检测到应用程序 Secret 已过期，用户将无法登录 Rancher。为避免此问题，请在 Azure 中轮换 Secret 并在过期前在 Rancher 中更新它。
1. 单击 **Add**（无需输入值，保存后会自动填充）。
<a id="secret"></a>
@@ -93,11 +95,11 @@ Microsoft Graph API 现在是设置 Azure AD 的流程。下文将帮助[新用
:::caution
请确保你设置了 Application 和 NOT Delegated 的权限类型。否则，你可能无法登录 Azure AD。
确保你设置了 Application 权限，而*不是* Delegated 权限。否则，你将无法登录 Azure AD。
:::
1. 从左侧的导航窗格中，选择 **API permissions**。
1. 在导航窗格中，选择 **API permissions**。
1. 单击 **Add a permission**。
@@ -105,13 +107,27 @@ Microsoft Graph API 现在是设置 Azure AD 的流程。下文将帮助[新用
![选择 API 权限](/img/api-permissions.png)
1. 返回左侧导航栏中的 **API permissions**。在那里，单击 **Grant admin consent**。然后单击 **Yes**。该应用程序的权限应如下所示：
1. 返回导航栏中的 **API permissions**。在那里，单击 **Grant admin consent**。然后单击 **Yes**。该应用程序的权限应如下所示：
![Open Required Permissions](/img/select-req-permissions.png)
:::note
Rancher 不会验证你授予 Azure 应用程序的权限。我们仅支持使用 `Directory.Read.All` 应用程序权限。
Rancher 不会验证你授予 Azure 应用程序的权限。你可以自由使用任何你所需的权限，只要这些权限允许 Rancher 使用 AD 用户和组。
具体来说，Rancher 需要允许以下操作的权限：
- 获取一个用户。
- 列出所有用户。
- 列出给定用户所属的组。
- 获取一个组。
- 列出所有组。
Rancher 执行这些操作来登录用户或搜索用户/组。请记住，权限必须是 `Application` 类型。
下面是几个满足 Rancher 需求的权限组合示例：
- `Directory.Read.All`
- `User.Read.All` 和 `GroupMember.Read.All`
- `User.Read.All` 和 `Group.Read.All`
:::
@@ -129,19 +145,23 @@ Rancher 不会验证你授予 Azure 应用程序的权限。我们仅支持使
1. 获取你的 Rancher **Application (Client) ID**。
1. 使用搜索打开 **App registrations**（如果还没有的话）。
1. 如果你还未在该位置，请使用搜索打开 **App registrations**。
1. 在 **Overview**中，找到你为 Rancher 创建的条目。
1. 复制 **Application (Client) ID** 并将其作为 **Application ID** 粘贴到 Rancher 中。
1. 你的端点选项通常 [Standard](#global) 或 [China](#china)。使用这些选项，你只需要输入 **Tenant ID**、**Application ID** 和 **Application Secret**。
1. 你的端点选项通常是 [Standard](#global) 或 [China](#china)。对于这两个选项，你只需要输入 **Tenant ID**、**Application ID** 和 **Application Secret**。
![标准端点选项](/img/tenant-application-id-secret.png)
**对于自定义端点**：
**警告**：Rancher 未测试也未完全支持自定义端点。
:::caution
Rancher 未测试也未完全支持自定义端点。
:::
你还需要手动输入 Graph、Token 和 Auth Endpoints。
@@ -149,14 +169,14 @@ Rancher 不会验证你授予 Azure 应用程序的权限。我们仅支持使
![点击端点](/img/endpoints.png)
- 请注意以下端点 - 这些值将是你的 Rancher 端点值。请使用端点的 v1 版本。
- 以下端点将是你的 Rancher 端点值。请使用这些端点的 v1 版本。
- **Microsoft Graph API endpoint**（Graph 端点）
- **OAuth 2.0 token endpoint (v1)**（Token 端点）
- **OAuth 2.0 authorization endpoint (v1)** (Auth 端点)
#### 5. 在 Rancher 中配置 Azure AD
在 Rancher UI 中，输入托管在 Azure 中的 AD 实例的信息以完成配置。
要完成配置，请在 Rancher UI 中输入你的 AD 实例信息。
1. 登录到 Rancher。
@@ -206,19 +226,19 @@ Rancher 不会验证你授予 Azure 应用程序的权限。我们仅支持使
### 从 Azure AD Graph API 迁移到 Microsoft Graph API
由于 [Azure AD Graph API](https://docs.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview) 已于 2020 年 6 月弃用并将于 2023 年 6 月停用，因此管理员应更新其 Azure AD 应用程序以在 Rancher 中使用新的 [Microsoft Graph API](https://docs.microsoft.com/en-us/graph/use-the-api)。
由于 [Azure AD Graph API](https://docs.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview) 已弃用并计划于 2023 年 6 月停用，管理员应更新他们的 Azure AD 应用程序以在 Rancher 中使用 [Microsoft Graph API](https://docs.microsoft.com/en-us/graph/use-the-api)。
你需要在端点弃用之前完成操作。
如果 Rancher 在停用后仍配置为使用旧的 Azure AD Graph API，用户可能无法使用 Azure AD 登录 Rancher。
如果在停用后 Rancher 仍配置为使用 Azure AD Graph API，用户可能无法使用 Azure AD 登录 Rancher。
#### 在 Rancher UI 中更新端点
:::caution
管理员需要在进行下述端点迁移之前创建一个[备份](../../../new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher.md)。
管理员需要在迁移下述端点之前创建一个 [Rancher 备份](../../../new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher.md)。
:::
1. 按照[此处](#3-设置-rancher-所需的权限)所述更新 Azure AD 应用注册的权限。这个步骤非常关键。
1. [更新](#3-设置-rancher-所需的权限) Azure AD 应用程序注册的权限。这个步骤非常关键。
1. 登录到 Rancher。
@@ -250,7 +270,12 @@ Rancher 不会验证你授予 Azure 应用程序的权限。我们仅支持使
1. 如果 Azure 应用程序所有者想要轮换应用程序密钥，他们也需要在 Rancher 中进行轮换（因为在 Azure 中更改应用程序密钥时，Rancher 不会自动更新应用程序密钥）。在 Rancher 中，它存储在名为 `azureadconfig-applicationsecret` 的 Kubernetes 密文中，该密文位于 `cattle-global-data` 命名空间中。
1. **注意**：如果管理员使用现有 Azure AD 设置升级到 Rancher v2.7.0+ 并选择了禁用身份验证提供程序，他们将无法恢复以前的设置，也无法设置使用旧流程重新设置 Azure AD。然后，管理员需要使用新的身份验证流程重新注册。Rancher 现在使用了新的 Graph API，因此，用户需要在 Azure 门户中设置[适当的权限](#3-设置-rancher-所需的权限)。
:::caution
如果你使用现有的 Azure AD 设置升级到 Rancher v2.7.0+，并选择了禁用认证提供程序，你将无法恢复以前的设置。你也无法使用旧流程设置 Azure AD。你需要使用新的认证流程重新注册。由于 Rancher 现在使用 Graph API，因此用户需要[在 Azure 门户中设置适当的权限](#3-设置-rancher-所需的权限)。
:::
#### Global:
@@ -289,12 +314,13 @@ Rancher 不会验证你授予 Azure 应用程序的权限。我们仅支持使
> **重要提示**：
>
> - [Azure AD Graph API](https://docs.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview) 已于 2022 年 6 月弃用，并将于 2022 年底停用。我们将更新我们的文档，以便在停用时向社区提供建议。Rancher 现在使用 [Microsoft Graph API](https://docs.microsoft.com/en-us/graph/use-the-api) 来将 Azure AD 设置为外部身份验证提供程序。
> - [Azure AD Graph API](https://docs.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview) 已被弃用，Microsoft 将在 2023 年 6 月 30 日后随时停用它且不会另行通知。我们将更新我们的文档，以便在停用时向社区提供建议。Rancher 现在使用 [Microsoft Graph API](https://docs.microsoft.com/en-us/graph/use-the-api) 来将 Azure AD 设置为外部身份验证提供程序。
>
>
> - 对于想要迁移的新用户或现有用户，请参阅流程说明 - <a href="#microsoft-graph-api/" target="_blank">Rancher v2.7.0+</a>。
> - 如果你是新用户或希望进行迁移，请参阅新的流程说明： <a href="#microsoft-graph-api/" target="_blank">Rancher v2.7.0+</a>。
>
>
> - 对于在 Azure AD Graph API 停用后不希望升级到 v2.7.0+ 的现有用户，他们需要：
> - 使用内置的 Rancher 身份验证，或者
> - 使用另一个第三方身份验证系统并在 Rancher 中进行设置。请参阅[身份验证文档](../../../../pages-for-subheaders/authentication-config.md)，了解如何配置其他开放式身份验证提供程序。
> - 如果你不想在 Azure AD Graph API 停用后升级到 v2.7.0+，你需要：
> - 使用内置的 Rancher 身份认证，或者
> - 使用另一个第三方身份认证系统并在 Rancher 中进行设置。请参阅[身份验证文档](../../../../pages-for-subheaders/authentication-config.md)，了解如何配置其他开放式身份验证提供程序。
i18n/zh/docusaurus-plugin-content-docs/current/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md
+12 -2
View File
@@ -2,9 +2,13 @@
title: Pod 安全策略
---
_Pod 安全策略（PSP）_ 是用来控制安全敏感相关 Pod 规范（例如 root 特权）的对象。
:::caution
Pod 安全策略仅在 Kubernetes v1.24 之前可用。[Pod 安全标准](pod-security-standards.md) 是内置的替代方案。
:::
如果某个 Pod 不满足 PSP 指定的条件，Kubernetes 将不允许它启动，并在 Rancher 中显示错误消息 `Pod <NAME> is forbidden: unable to validate...`。
[Pod 安全策略（PSP）](https://kubernetes.io/docs/concepts/security/pod-security-policy/)是用来控制安全敏感相关 Pod 规范（例如 root 特权）的对象。
如果某个 Pod 不满足 PSP 指定的条件，Kubernetes 将不允许它启动，Rancher 中将显示错误消息 `Pod <NAME> is forbidden: unable to validate...`。
## PSP 工作原理
@@ -40,6 +44,12 @@ Rancher 内置了三个默认 Pod 安全策略 (PSP)，分别是 `restricted-nor
该策略等效于在禁用 PSP 控制器的情况下运行 Kubernetes。对于可以将哪些 Pod 部署到集群或项目中，它没有任何限制。
:::note 重要提示：
禁用 PSP 时，默认 PSP **不会**自动从集群中删除。如果不再需要它们，你必须手动删除它们。
:::
## 创建 PSP
使用 Rancher，你可以使用我们的 GUI 创建 Pod 安全策略，而不是创建 YAML 文件。
i18n/zh/docusaurus-plugin-content-docs/current/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/pod-security-standards.md
+126
View File
@@ -0,0 +1,126 @@
---
title: Pod 安全标准 (PSS) 和 Pod 安全准入 (PSA)
---
[Pod 安全标准 (PSS)](https://kubernetes.io/docs/concepts/security/pod-security-standards/) 和 [Pod 安全准入 (PSA)](https://kubernetes.io/docs/concepts/security/pod-security-admission/) 为大量工作负载定义了安全限制。
它们在 Kubernetes v1.23 中可用并默认打开，并在 Kubernetes v1.25 及更高版本中替换了 [Pod Security Policies (PSP)](https://kubernetes.io/docs/concepts/security/pod-security-policy/)。
PSS 定义了工作负载的安全级别。PSA 描述了 Pod 安全上下文和相关字段的要求。PSA 参考 PSS 级别来定义安全限制。
## 升级到 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 的更多信息，请参阅你选择的策略引擎的文档。
:::caution
必须在删除 PodSecurityPolicy 对象_之前_添加新的策略执行机制。否则，你可能会为集群内的特权升级攻击创造机会。
:::
### 从 Rancher 维护的应用程序和市场工作负载中删除 PodSecurityPolicies {#remove-psp-rancher-workloads}
Rancher v2.7.2 提供了 Rancher 维护的 Helm Chart 的新主要版本。v102.x.y 允许你删除与以前的 Chart 版本一起安装的 PSP。这个新版本使用标准化的 `global.cattle.psp.enabled` 开关（默认关闭）替换了非标准的 PSP 开关。
你必须在_仍使用 Kubernetes v1.24_ 时执行以下步骤：
1. 根据需要配置 PSA 控制器。你可以使用 Rancher 的内置 [PSA 配置模板](#psa-config-templates)，或创建自定义模板并将其应用于正在迁移的集群。
1. 将活动的 PSP 映射到 Pod 安全标准：
1. 查看集群中哪些 PSP 仍处于活动状态：
:::caution
此策略可能会错过当前未运行的工作负载，例如 CronJobs、当前缩放为零的工作负载或尚未推出的工作负载。
:::
```shell
kubectl get pods \
--all-namespaces \
--output jsonpath='{.items[*].metadata.annotations.kubernetes\.io\/psp}' \
| tr " " "\n" | sort -u
```
1. 按照[将 PSP 映射到 Pod 安全标准](https://kubernetes.io/docs/reference/access-authn-authz/psp-to-pod-security-standards/)的 Kubernetes 指南将 PSS 应用于依赖 PSP 的工作负载。有关详细信息，请参阅[从 PodSecurityPolicy 迁移到内置 PodSecurity Admission 控制器](https://kubernetes.io/docs/tasks/configure-pod-container/migrate-from-psp/)。
1. 要从 Rancher Chart 中删除 PSP，请在升级到 Kubernetes v1.25 _之前_将 Chart 升级到最新的 v102.x.y 版本。确保 **Enable PodSecurityPolicies** 选项**已禁用**。这将删除与以前的 Chart 版本一起安装的所有 PSP。
:::info 重要提示
如果你想将 Chart 升级到 v102.x.y，但不打算将集群升级到 Kubernetes v1.25 和弃用 PSP，请确保为每个要升级的 Chart 选择 **Enable PodSecurityPolicies** 选项。
:::
### 在 Kubernetes v1.25 升级后清理版本
如果你在删除 Chart 的 PSP 时遇到问题，或者 Chart 不包含用于删除 PSP 的内置机制，Chart 升级或删除可能会失败并显示如下错误消息：
```console
Error: UPGRADE FAILED: resource mapping not found for name: "<object-name>" namespace: "<object-namespace>" from "": no matches for kind "PodSecurityPolicy" in version "policy/v1beta1"
ensure CRDs are installed first
```
Helm 尝试在集群中查询存储在先前版本的数据 blob 中的对象时，就会发生这种情况。要清理这些版本并避免此错误，请使用 `helm-mapkubeapis` Helm 插件。要详细了解 `helm-mapkubeapis`、它的工作原理以及如何针对你的用例进行微调，请参阅 [Helm 官方文档](https://github.com/helm/helm-mapkubeapis#readme)。
请注意，Helm 插件安装在你运行命令的机器本地。因此，请确保从同一台机器运行安装和清理。
#### 安装 `helm-mapkubeapis`
1. 在打算使用 `helm-mapkubeapis` 的机器上打开你的终端并安装插件：
```shell
helm plugin install https://github.com/helm/helm-mapkubeapis
```
你将看到类似于以下的输出：
```console
Downloading and installing helm-mapkubeapis v0.4.1 ...
https://github.com/helm/helm-mapkubeapis/releases/download/v0.4.1/helm-mapkubeapis_0.4.1_darwin_amd64.tar.gz
Installed plugin: mapkubeapis
```
:::info 重要提示
确保 `helm-mapkubeapis` 插件至少为 v0.4.1，因为旧版本_不_支持资源删除。
:::
1. 验证插件是否已正确安装：
```shell
helm mapkubeapis --help
```
你将看到类似于以下的输出：
```console
Map release deprecated or removed Kubernetes APIs in-place
Usage:
mapkubeapis [flags] RELEASE
Flags:
--dry-run simulate a command
-h, --help help for mapkubeapis
--kube-context string name of the kubeconfig context to use
--kubeconfig string path to the kubeconfig file
--mapfile string path to the API mapping file
--namespace string namespace scope of the release
```
#### 清理损坏的版本
安装 `helm-mapkubeapis` 插件后，清理升级到 Kubernetes v1.25 后损坏的版本。
1. 打开你的首选终端并通过运行 `kubectl cluster-info` 确保终端已连接到所需集群。
1. 运行 `helm list --all-namespaces` 列出你在集群中安装的所有版本。
1. 通过运行 `helm mapkubeapis --dry-run <release-name> --namespace <release-namespace>` 为要清理的每个版本执行试运行。你可以通过此命令的结果了解要替换或删除哪些资源。
1. 最后，在查看更改后，使用 `helm mapkubeapis <release-name> --namespace <release-namespace>` 执行完整运行。
#### 将 Chart 升级到支持 Kubernetes v1.25 的版本
清理了具有 PSP 的所有版本后，你就可以继续升级了。对于 Rancher 维护的工作负载，请按照本文档[从 Rancher 维护的应用程序和市场工作负载中删除 PodSecurityPolicies](#remove-psp-rancher-workloads) 部分中的步骤进行操作。
如果工作负载不是由 Rancher 维护的，请参阅对应的提供商的文档。
:::caution
不要跳过此步骤。与 Kubernetes v1.25 不兼容的应用程序不能保证在清理后正常工作。
:::
## Pod 安全准入配置模板 {#psa-config-templates}
Rancher 提供了 PSA 配置模板。它们是可以应用到集群的预定义安全配置。Rancher 管理员（或具有权限的人员）可以[创建、管理和编辑](./psa-config-templates.md) PSA 模板。
### 受 PSA 限制的集群上的 Rancher
Rancher system 命名空间也受到 PSA 模板描述的限制性安全策略的影响。你需要在分配模板后豁免 Rancher 的 system 命名空间，否则集群将无法正常运行。有关详细信息，请参阅 [Pod 安全准入 (PSA) 配置模板](./psa-config-templates.md#豁免必须的-rancher-命名空间)。
有关运行 Rancher 所需的所有豁免的完整文件，请参阅此[准入配置示例](../../../reference-guides/rancher-security/psa-restricted-exemptions.md)。
i18n/zh/docusaurus-plugin-content-docs/current/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/psa-config-templates.md
+138
View File
@@ -0,0 +1,138 @@
---
title: Pod 安全准入 (PSA) 配置模板
---
[Pod Security admission (PSA)](./pod-security-standards.md) 配置模板是 Rancher 自定义资源 (CRD)，在 Rancher v2.7.2 及更高版本中可用。这些模板提供了可应用于集群的预定义安全配置：
- `rancher-privileged`：最宽松的配置。它不限制任何 Pod 行为，允许已知的权限升级。该策略没有豁免。
- `rancher-restricted`：严格限制的配置，遵循当前加固 pod 的最佳实践。你必须对 Rancher 组件进行[命名空间级别豁免](./pod-security-standards.md#受-psa-限制的集群上的-rancher)。
## 分配 Pod 安全准入 (PSA) 配置模板
你可以在创建下游集群的同时分配 PSA 模板。你还可以通过配置现有集群来添加模板。
### 在集群创建期间分配模板
<Tabs>
<TabItem value="RKE2 和 K3s">
1. 在左上角，单击 **☰ > 集群管理**。
1. 在**集群**页面上，单击**创建**按钮。
1. 选择提供商。
1. 在**集群: 创建**页面上，转到**基本信息 > 安全**。
1. 在 **PSA 配置模板**下拉菜单中，选择要分配的模板。
1. 单击**创建**。
### 将模板分配给现有集群
1. 在左上角，单击 **☰ > 集群管理**。
1. 在**集群**表中找到要更新的集群，点击 **⋮**。
1. 选择**编辑配置**。
1. 在 **PSA 配置模板**下拉菜单中，选择要分配的模板。
1. 单击**保存**。
### 加固集群
如果选择 **rancher-restricted** 模板但不选择 **CIS 配置文件**，你将无法满足 CIS Benchmark。有关详细信息，请参阅 [RKE2 加固指南](../../../pages-for-subheaders/rke2-hardening-guide.md)。
</TabItem>
<TabItem value="RKE1">
1. 在左上角，单击 **☰ > 集群管理**。
1. 在**集群**页面上，单击**创建**按钮。
1. 选择提供商。
1. 在**添加集群**页面上的**集群选项**下，单击 **高级选项**。
1. 在 **PSA 配置模板**下拉菜单中，选择要分配的模板。
1. 单击**创建**。
### 将模板分配给现有集群
1. 在左上角，单击 **☰ > 集群管理**。
1. 在**集群**表中找到要更新的集群，点击 **⋮**。
1. 选择**编辑配置**。
1. 在**编辑集群**页面上，转到**集群选项 > 高级选项**。
1. 在 **PSA 配置模板**中，选择要分配的模板。
1. 单击**保存**。
</TabItem>
</Tabs>
## 添加或编辑 Pod 安全准入 (PSA) 配置模板
如果你拥有管理员权限，则可以通过创建其他 PSA 模板或编辑现有模板来自定义安全限制和权限。
:::caution
如果编辑使用中的现有 PSA 模板，更改将应用​​于已分配给该模板的所有集群。
:::
1. 在左上角，单击 **☰ > 集群管理**。
1. 点击**高级选项**打开下拉菜单。
1. 选择 **Pod 安全准入**。
1. 找到要修改的模板，点击 **⋮**。
1. 选择**编辑配置**来编辑模板。
1. 完成配置编辑后，单击**保存**。
### 允许非管理员用户管理 PSA 模板
如果你想允许其他用户管理模板，你可以将该用户绑定到一个角色，并为该角色授予 `management.cattle.io/podsecurityadmissionconfigurationtemplates` 上的所有操作 (`"*"`)。
:::caution
绑定到上述权限的用户都能够更改使用该 PSA 模板的_所有_托管集群的限制级别，包括用户没有权限的集群。
:::
## 豁免必须的 Rancher 命名空间
在默认执行限制性安全策略的 Kubernetes 集群上运行 Rancher 时，你需要[豁免以下命名空间](#豁免命名空间)，否则该策略可能会阻止 Rancher system pod 正常运行。
- `calico-apiserver`
- `calico-system`
- `cattle-alerting`
- `cattle-csp-adapter-system`
- `cattle-epinio-system`
- `cattle-externalip-system`
- `cattle-fleet-local-system`
- `cattle-fleet-system`
- `cattle-gatekeeper-system`
- `cattle-global-data`
- `cattle-global-nt`
- `cattle-impersonation-system`
- `cattle-istio`
- `cattle-istio-system`
- `cattle-logging`
- `cattle-logging-system`
- `cattle-monitoring-system`
- `cattle-neuvector-system`
- `cattle-prometheus`
- `cattle-sriov-system`
- `cattle-system`
- `cattle-ui-plugin-system`
- `cattle-windows-gmsa-system`
- `cert-manager`
- `cis-operator-system`
- `fleet-default`
- `ingress-nginx`
- `istio-system`
- `kube-node-lease`
- `kube-public`
- `kube-system`
- `longhorn-system`
- `rancher-alerting-drivers`
- `security-scan`
- `tigera-operator`
Rancher、Rancher 拥有的一些 Chart 以及 RKE2 和 K3s 发行版都使用这些命名空间。列出的命名空间的一个子集已经在内置的 Rancher `rancher-restricted` 策略中被豁免，用于下游集群。有关运行 Rancher 所需的所有豁免的完整模板，请参阅此[准入配置示例](../../../reference-guides/rancher-security/psa-restricted-exemptions.md)。
## 豁免命名空间
如果你将 `rancher-restricted` 模板分配给集群，默认情况下，限制会在命名空间级别应用于整个集群。要在此高度受限的策略下豁免特定的命名空间，执行以下操作：
1. 在左上角，单击 **☰ > 集群管理**。
1. 点击**高级选项**打开下拉菜单。
1. 选择 **Pod 安全准入**。
1. 找到要修改的模板，点击 **⋮**。
1. 选择**编辑配置**。
1. 选中**豁免**下的**命名空间**复选框以编辑**命名空间**字段。
1. 豁免命名空间后，单击**保存**。
:::note
你需要更新目标集群才能让新模板在集群中生效。要触发更新，在不更改值的情况下编辑和保存集群。
:::
i18n/zh/docusaurus-plugin-content-docs/current/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md
+2
View File
@@ -158,6 +158,8 @@ Kubernetes v1.22 是 Rancher 2.6.3 的实验功能，不支持使用 apiVersion
使用与第一个集群上使用的相同版本的 Helm 来安装 Rancher：
对于 Kubernetes v1.25 或更高版本，将 `global.cattle.psp.enabled` 设置为 `false`。
```bash
helm install rancher rancher-latest/rancher \
--namespace cattle-system \
i18n/zh/docusaurus-plugin-content-docs/current/how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md
+2 -2
View File
@@ -1,8 +1,8 @@
---
title: Fleet - 大规模的 GitOps
title: 使用 Feet 进行持续交付
---
Fleet 是大规模的 GitOps。你可以使用 Fleet 管理多达一百万个集群。Fleet 非常轻量，可以很好地用于[单个集群](https://fleet.rancher.io/single-cluster-install/)，但是在你达到[大规模](https://fleet.rancher.io/multi-cluster-install/)时，它能发挥更强的实力。此处的大规模指的是大量集群、大量部署、或组织中存在大量团队的情况。
使用 Fleet 的持续交付是大规模的 GitOps。你可以使用 Fleet 管理多达一百万个集群。Fleet 非常轻量，可以很好地用于[单个集群](https://fleet.rancher.io/single-cluster-install/)，但是在你达到[大规模](https://fleet.rancher.io/multi-cluster-install/)时，它能发挥更强的实力。此处的大规模指的是大量集群、大量部署、或组织中存在大量团队的情况。
Fleet 是一个独立于 Rancher 的项目，你可以使用 Helm 将它安装在任何 Kubernetes 集群上。
i18n/zh/docusaurus-plugin-content-docs/current/how-to-guides/new-user-guides/kubernetes-cluster-setup/rke1-for-rancher.md
+4
View File
@@ -40,6 +40,8 @@ Rancher 可以运行在任何 Kubernetes 集群上，包括托管的 Kubernetes
RKE 需要通过 SSH 连接到每个节点，它会在 `~/.ssh/id_rsa`的默认位置查找私钥。如果某个节点的私钥不在默认位置中，你还需要为该节点配置 `ssh_key_path` 选项。
在选择 Kubernetes 版本时，请务必先查阅[支持矩阵](https://rancher.com/support-matrix/)，以找出已针对你的 Rancher 版本验证的最新 Kubernetes 版本。
```yaml
nodes:
- address: 165.227.114.63
@@ -67,6 +69,8 @@ ingress:
provider: nginx
options:
use-forwarded-headers: "true"
kubernetes_version: v1.25.6-rancher4-1
```
<figcaption>通用 RKE 节点选项</figcaption>
i18n/zh/docusaurus-plugin-content-docs/current/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md
+5
View File
@@ -119,6 +119,11 @@ Rancher 管理注册集群的范围取决于集群的类型。
RKE2 或 K3s 集群注册到 Rancher 后，Rancher 会识别它。Rancher UI 将开放[所有已注册集群](#所有已注册集群的功能)的功能，以及以下用于编辑和升级集群的功能：
- [升级 Kubernetes 版本](../../../getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md)的能力
:::danger
将集群导入 Rancher 后，你需要使用 Rancher 执行升级。**不**支持在 Rancher 之外升级导入的集群。
:::
- 配置能同时升级的最大节点数
- 查看集群的配置参数和用于启动集群中每个节点的环境变量的只读版本
i18n/zh/docusaurus-plugin-content-docs/current/how-to-guides/new-user-guides/kubernetes-resources-setup/load-balancer-and-ingress-controller/ingress-configuration.md
+2 -2
View File
@@ -15,9 +15,9 @@ description: Ingress 配置
如果使用此选项，Ingress 会将主机名请求路由到你指定的服务或工作负载。
1. 输入**请求主机**，你的 Ingress Controller 会为它处理请求转发。例如，`www.mysite.com`。
1. 指定类型为 `Prefix` 的路径并指定路径，例如 `/`。
1. 添加一个**目标服务**。
1. **可选**：如果你想在将请求发送到特定主机名路径时指定工作负载或服务，请为目标添加**路径**。例如，如果你希望将 `www.mysite.com/contact-us` 的请求发送到与 `www.mysite.com` 不同的服务，在**路径**中输入 `/contact-us`。通常情况下，你创建的第一条规则不包含路径。
1. **可选**：如果你想在将请求发送到特定主机名路径时指定工作负载或服务，请为目标添加**路径**。例如，如果你希望将 `www.mysite.com/contact-us` 的请求发送到与 `www.mysite.com` 不同的服务，在**路径**字段中输入 `/contact-us`。通常情况下，你创建的第一条规则不包含路径。
1. 输入每个目标操作的**端口**号。
## 证书
i18n/zh/docusaurus-plugin-content-docs/current/how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md
+5 -2
View File
@@ -47,9 +47,12 @@ Rancher 会发现并显示由 `kubectl` 创建的资源。但是在发现资源
本节旨在帮助你设置访问 [RKE 集群的替代方法](../../../../pages-for-subheaders/launch-kubernetes-with-rancher.md)。
此方法仅适用于启用了[授权集群端点](../../../../pages-for-subheaders/rancher-manager-architecture.md#4-授权集群端点)的 RKE 集群。在 Rancher 创建 RKE 集群时，Rancher 会生成一个 kubeconfig 文件，其中包含用于访问集群的额外 kubectl 上下文。该上下文允许你使用 kubectl 通过下游集群进行身份验证，而无需通过 Rancher 进行身份验证。有关授权集群端点如何工作的详细说明，请参阅[此页面](authorized-cluster-endpoint.md)。
此方法仅适用于启用了[授权集群端点](../../../../pages-for-subheaders/rancher-manager-architecture.md#4-授权集群端点)的 RKE、RKE2 和 K3s集群。在 Rancher 创建集群时，Rancher 会生成一个 kubeconfig 文件，其中包含用于访问集群的额外 kubectl 上下文。该上下文允许你使用 kubectl 通过下游集群进行身份验证，而无需通过 Rancher 进行身份验证。有关授权集群端点如何工作的详细说明，请参阅[此页面](authorized-cluster-endpoint.md)。
在 RKE2 和 K3s 集群上，你需要[手动启用](../../kubernetes-clusters-in-rancher-setup/register-existing-clusters.md#对-rke2-和-k3s-集群的授权集群端点支持)授权集群端点。
我们的最佳实践是使用此方法来访问 RKE、RKE2 和 K3s集群。这样，万一你无法连接到 Rancher，你仍然可以访问该集群。
我们的最佳实践是使用此方法来访问 RKE 集群。这样，万一你无法连接到 Rancher，你仍然可以访问该集群。
:::note 先决条件：
i18n/zh/docusaurus-plugin-content-docs/current/integrations-in-rancher/monitoring-and-alerting/rbac-for-monitoring.md
+53 -10
View File
@@ -99,7 +99,6 @@ Monitoring 还会创建其他 `Role`，这些角色默认情况下不会分配
2.4 单击 **Create**。
**结果**：新用户现在应该能够看到 monitoring 工具。
### 其他监控集群角色
@@ -108,14 +107,60 @@ Monitoring 还会创建其他 `ClusterRole`，这些角色默认情况下不会
| 角色 | 用途 |
| ------------------------------| ---------------------------|
| monitoring-ui-view | <a id="monitoring-ui-view"></a>_从 Monitoring v2 14.5.100+ 开始可用_。通过授权用户列出 Prometheus、Alertmanager 和 Grafana 端点，并通过 Rancher 代理向 Prometheus、Grafana 和 Alertmanager UI 进行 GET 请求，来允许用户对外部 Monitoring UI 进行只读访问。 |
| monitoring-ui-view | <a id="monitoring-ui-view"></a>_自 Monitoring v2 14.5.100+ 起可用_ 此 ClusterRole 允许用户在 Rancher UI 中查看指定集群的指标图。这是通过授予对外部监控 UI 的只读访问权限来实现的。具有此角色的用户有权限列出 Prometheus、Alertmanager 和 Grafana 端点，并通过 Rancher 代理向 Prometheus、Grafana 和 Alertmanager UI 发出 GET 请求。 |
### 使用 kubectl 分配 Role 和 ClusterRole
使用 Rancher 将 `Role` 或 `ClusterRole` 附加到用户或组的另一种方法，是在你创建的 YAML 文件中定义绑定。你必须首先使用 YAML 文件配置 `RoleBinding`，然后运行 `kubectl apply` 命令来应用配置更改。
#### 使用 `kubectl create`
一种方法是使用 `kubectl create clusterrolebinding` 或 `kubectl create rolebinding` 来分配一个 `Role` 或 `ClusterRole`。如以下示例所示：
* **Role**：以下 YAML 文件示例可帮助你在 Kubernetes 中配置 `RoleBinding`。你需要填写下方的 `name`（区分大小写）：
- 分配给特定用户：
<Tabs groupId="role-type">
<TabItem value="clusterrolebinding">
```plain
kubectl create clusterrolebinding my-binding --clusterrole=monitoring-ui-view --user=u-l4npx
```
</TabItem>
<TabItem value="rolebinding">
```plain
kubectl create rolebinding my-binding --clusterrole=monitoring-ui-view --user=u-l4npx --namespace=my-namespace
```
</TabItem>
</Tabs>
- 分配给所有经过身份认证的用户：
<Tabs groupId="role-type">
<TabItem value="clusterrolebinding">
```plain
kubectl create clusterrolebinding my-binding --clusterrole=monitoring-ui-view --group=system:authenticated
```
</TabItem>
<TabItem value="rolebinding">
```plain
kubectl create rolebinding my-binding --clusterrole=monitoring-ui-view --group=system:authenticated --namespace=my-namespace
```
</TabItem>
</Tabs>
#### 使用 YAML 文件
另一种方法是在你创建的 YAML 文件中定义绑定。你必须先使用 YAML 文件配置 `RoleBinding` 或 `ClusterRoleBinding`。然后，通过运行 `kubectl apply` 命令来应用配置更改。
- **Role**：以下 YAML 文件示例可帮助你在 Kubernetes 中配置 `RoleBinding`。你需要在下面填写名称。
:::note
名称区分大小写。
:::
```yaml
# monitoring-config-view-role-binding.yaml
@@ -134,10 +179,10 @@ subjects:
apiGroup: rbac.authorization.k8s.io
```
* **kubectl**：以下 `kubectl` 示例命令用于应用 YAML 文件中创建的绑定。如前所述，你需要相应地填写你的 YAML 文件名。
* `kubectl apply -f monitoring-config-view-role-binding.yaml`
- **kubectl**：以下 `kubectl` 示例命令用于应用 YAML 文件中创建的绑定。请记住相应填写你的 YAML 文件名。
```plain
kubectl apply -f monitoring-config-view-role-binding.yaml
```
## 具有 Rancher 权限的用户
@@ -184,8 +229,6 @@ Rancher 部署的默认角色（即 cluster-owner、cluster-member、project-own
| <ul><li>`secrets`</li><li>`configmaps`</li></ul> | `cattle-monitoring-system` | 是。此命名空间中的 Config 和 Secret 会影响整个监控/告警流水线。 | 用户将能够创建或编辑 Secret/ ConfigMap，例如 Alertmanager Config、Prometheus Adapter 配置、TLS 密文、其他 Grafana 数据源等。这会对所有集群监控/告警产生广泛影响。 |
| <ul><li>`secrets`</li><li>`configmaps`</li></ul> | `cattle-dashboards` | 是。此命名空间中的 Config 和 Secret 可以创建仪表板，对在集群级别收集的所有指标进行查询。 | 用户将能够创建仅保留新 Grafana 仪表板的 Secret/ConfigMap。 |
## Grafana 的 RBAC
对于经过 Kubernetes 认证并可以访问 Rancher Monitoring Chart 部署的 Grafana 服务的任何用户，Rancher 允许他们通过 Rancher Dashboard UI 访问 Grafana。默认情况下，所有能够访问 Grafana 的用户都被赋予 [Viewer](https://grafana.com/docs/grafana/latest/permissions/organization_roles/#viewer-role) 角色，能查看 Rancher 部署的任何默认仪表板。
i18n/zh/docusaurus-plugin-content-docs/current/pages-for-subheaders/authentication-config.md
+23
View File
@@ -107,3 +107,26 @@ Rancher 依赖用户和组来决定允许登录到 Rancher 的用户，以及他
如果你需要重新配置或禁用以前设置的提供程序然后再重新启用它，请确保进行此操作的用户使用外部用户身份登录 Rancher，而不是本地管理员。
:::
## 禁用认证提供程序
禁用身份认证提供程序时，Rancher 会删除与其关联的所有资源，例如：
- Secrets
- 全局角色绑定。
- 集群角色模板绑定。
- 项目角色模板绑定。
- 与提供商关联的外部用户，但是这些用户从未以本地用户身份登录到 Rancher。
由于此操作可能会导致许多资源丢失，因此你可能希望在提供程序上添加保护措施。为确保在禁用身份认证提供程序时不会运行此清理，请向相应的身份认证配置添加特殊注释。
例如，要为 Azure AD 提供程序添加安全措施，请注释 `azuread` authconfig 对象：
`kubectl annotate --overwrite authconfig azuread management.cattle.io/auth-provider-cleanup='user-locked'`
在你将注释设置为 `unlocked` 之前，Rancher 不会执行清理。
### 手动运行资源清理
即使在你配置了另一个身份认证提供程序，Rancher 也可能会保留 local 集群中已禁用的身份认证提供程序配置的资源。例如，如果你使用 Provider A，然后禁用了它并开始使用 Provider B，当你升级到新版本的 Rancher 时，你可以手动触发对 Provider A 配置的资源的清理。
要为已禁用的身份认证提供程序手动触发清理，请将带有 `unlocked` 值的 `management.cattle.io/auth-provider-cleanup` 注释添加到 auth 配置中。
i18n/zh/docusaurus-plugin-content-docs/current/pages-for-subheaders/cis-scans.md
+19 -9
View File
@@ -13,8 +13,7 @@ CIS（Center for Internet Security）是一个 501(c\)(3) 非营利组织，成
CIS Benchmark 是目标系统安全配置的最佳实践。CIS Benchmark 是由安全专家、技术供应商、公开和私人社区成员，以及 CIS Benchmark 开发团队共同志愿开发的。
你可以访问 CIS 网站获取官方的 Benchmark 文件。要通过注册来访问文件，请前往
<a href="https://learn.cisecurity.org/benchmarks" target="_blank">这里</a>。
在 CIS 网站上[注册](https://learn.cisecurity.org/benchmarks)以查看官方 Benchmark 文档。
## 关于生成的报告
@@ -31,7 +30,7 @@ Benchmark 提供两种类型的建议，分别是自动（Automated）和手动
该报告包含以下信息：
| 报告中的列 | 描述 |
|------------------|-------------|
|-------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `id` | CIS Benchmark 的 ID 号。 |
| `description` | CIS Benchmark 测试的描述。 |
| `remediation` | 为了通过测试需要修复的内容。 |
@@ -51,16 +50,27 @@ Benchmark 提供两种类型的建议，分别是自动（Automated）和手动
以下是可用的配置文件：
- Generic CIS 1.5
- Generic CIS 1.6
- RKE permissive 1.5
- RKE hardened 1.5
- Generic CIS 1.20
- Generic CIS 1.23
- RKE permissive 1.6
- RKE hardened 1.6
- RKE2 permissive 1.5
- RKE2 hardened 1.5
- RKE permissive 1.20
- RKE hardened 1.20
- RKE permissive 1.23
- RKE hardened 1.23
- RKE2 permissive 1.6
- RKE2 hardened 1.6
- RKE2 permissive 1.20
- RKE2 hardened 1.20
- RKE2 permissive 1.23
- RKE2 hardened 1.23
- K3s permissive 1.6
- K3s hardened 1.6
- K3s permissive 1.20
- K3s hardened 1.20
- K3s permissive 1.23
- K3s hardened 1.23
- AKS
- EKS
- GKE
@@ -105,4 +115,4 @@ EKS 和 GKE 集群扫描的配置文件基于这些集群类型特定的 CIS Ben
## 操作指南
请参阅[此处](../pages-for-subheaders/cis-scan-guides.md)了解 CIS 扫描的操作指南。
要了解如何运行 CIS 扫描，请参阅 [CIS 扫描指南](../pages-for-subheaders/cis-scan-guides.md)。
i18n/zh/docusaurus-plugin-content-docs/current/pages-for-subheaders/deploy-apps-across-clusters.md
+1 -1
View File
@@ -5,7 +5,7 @@ title: 跨集群部署应用
Rancher 2.5 引入了 Fleet，这是一种跨集群部署应用的新方式。
Fleet 是大规模的 GitOps。如需更多信息，请参阅 [Fleet](../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md)。
使用 Fleet 的持续交付是大规模的 GitOps。如需更多信息，请参阅 [Fleet](../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md)。
### 多集群应用
i18n/zh/docusaurus-plugin-content-docs/current/pages-for-subheaders/deploy-rancher-manager.md
+1 -1
View File
@@ -5,6 +5,7 @@ title: 部署 Rancher Server
你可使用以下指南之一，在你选择的提供商中部署和配置 Rancher 和 Kubernetes 集群。
- [AWS](../getting-started/quick-start-guides/deploy-rancher-manager/aws.md)（使用 Terraform）
- [AWS Marketplace](../getting-started/quick-start-guides/deploy-rancher-manager/aws-marketplace.md)（使用 Amazon EKS）
- [Azure](../getting-started/quick-start-guides/deploy-rancher-manager/azure.md)（使用 Terraform）
- [DigitalOcean](../getting-started/quick-start-guides/deploy-rancher-manager/digitalocean.md)（使用 Terraform）
- [GCP](../getting-started/quick-start-guides/deploy-rancher-manager/gcp.md)（使用 Terraform）
@@ -13,7 +14,6 @@ title: 部署 Rancher Server
- [Equinix Metal](../getting-started/quick-start-guides/deploy-rancher-manager/equinix-metal.md)
- [Outscale](../getting-started/quick-start-guides/deploy-rancher-manager/outscale-qs.md)（使用 Terraform）
如有需要，你可以查看以下指南以了解分步步骤。如果你需要在其他提供商中或本地运行 Rancher，或者你只是想看看它是多么容易上手，你可阅读以下指南：
- [手动安装](../getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md)
i18n/zh/docusaurus-plugin-content-docs/current/pages-for-subheaders/enable-experimental-features.md
+2
View File
@@ -34,6 +34,8 @@ Rancher 包含一些默认关闭的实验功能。在某些情况下，例如当
使用 Helm Chart 安装 Rancher 时，使用 `--set` 选项。下面的示例通过传递功能开关名称（用逗号分隔）来启用两个功能：
对于 Kubernetes v1.25 或更高版本，将 `global.cattle.psp.enabled` 设置为 `false`。
```
helm install rancher rancher-latest/rancher \
--namespace cattle-system \
i18n/zh/docusaurus-plugin-content-docs/current/pages-for-subheaders/fleet-gitops-at-scale.md
+2 -2
View File
@@ -1,8 +1,8 @@
---
title: Fleet - 大规模的 GitOps
title: 使用 Feet 进行持续交付
---
Fleet 是大规模的 GitOps。你可以使用 Fleet 管理多达一百万个集群。此外，它非常轻量，因此也非常适用于[单个集群](https://fleet.rancher.io/tut-deployment#single-cluster-examples)。但是，它在[大规模](https://fleet.rancher.io/tut-deployment#multi-cluster-examples)场景下的功能更加强大。大规模指的是大量集群、大量部署或大量团队。
使用 Fleet 的持续交付是大规模的 GitOps。你可以使用 Fleet 管理多达一百万个集群。此外，它非常轻量，因此也非常适用于[单个集群](https://fleet.rancher.io/single-cluster-install/)。但是，它在[大规模](https://fleet.rancher.io/multi-cluster-install/)场景下的功能更加强大。大规模指的是大量集群、大量部署或大量团队。
Fleet 是一个独立于 Rancher 的项目，你可以使用 Helm 将它安装在任何 Kubernetes 集群上。
i18n/zh/docusaurus-plugin-content-docs/current/pages-for-subheaders/helm-charts-in-rancher.md
+9
View File
@@ -45,6 +45,15 @@ Rancher 2.6.0 实现了功能 Chart 的新版本控制方案。变更主要是 C
- 在升级时，请确保你没有降级你正在使用的 Chart 版本。例如，如果你在 Rancher 2.5 中使用 Monitoring > `16.6.0` 版本，则不应升级到 `100.x.x+up16.6.0`。相反，你应该在下一个发行版中升级到适当的版本。
### 预发布版本
预发布版本遵循 [Semantic Versioning 2.0.0](https://semver.org/) 定义的[规范](https://semver.org/#spec-item-9)。例如，版本为 `0.1.3-dev.12ab4f` 的 Helm chart 为预发布版本。默认情况下不显示预发布版本，必须进行配置才能显示。
要显示预发布版本：
1. 单击右上角的用户头像。
1. 单击**偏好设置**。
1. 在 **Helm Chart** 下，选择**包括预发布版本**。
### Charts
i18n/zh/docusaurus-plugin-content-docs/current/pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md
+10 -1
View File
@@ -143,6 +143,12 @@ v2.6.4 兼容 cert-manager 版本 1.6.2 和 1.7.1。推荐使用 v1.7.x，因为
这些说明来自 [cert-manager 官方文档](https://cert-manager.io/docs/installation/kubernetes/#installing-with-helm)。
:::note
要查看自定义 cert-manager 安装的选项（包括集群使用 PodSecurityPolicies 的情况），请参阅 [cert-manager 文档](https://artifacthub.io/packages/helm/cert-manager/cert-manager#configuration)。
:::
```
# 如果你手动安装了CRD，而不是在 Helm 安装命令中添加了 `--set installCRDs=true` 选项，你应该在升级 Helm Chart 之前升级 CRD 资源。
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.crds.yaml
@@ -194,7 +200,8 @@ cert-manager-webhook-787858fcdb-nlzsq 1/1 Running 0 2m
- 将 `hostname` 设置为解析到你的负载均衡器的 DNS 名称。
- 将 `bootstrapPassword` 设置为 `admin` 用户独有的值。
- 如果你需要安装指定的 Rancher 版本，使用 `--version` 标志，例如 `--version 2.3.6`。
- 如果你需要安装指定的 Rancher 版本，使用 `--version` 标志，例如 `--version 2.7.0`。
- 对于 Kubernetes v1.25 或更高版本，将 `global.cattle.psp.enabled` 设置为 `false`。
```
helm install rancher rancher-<CHART_REPO>/rancher \
@@ -235,6 +242,7 @@ deployment "rancher" successfully rolled out
- 将 `ingress.tls.source` 设置为 `letsEncrypt`。
- 将 `letsEncrypt.email` 设置为可通讯的电子邮件地址，用于发送通知（例如证书到期的通知）。
- 将 `letsEncrypt.ingress.class` 设为你的 Ingress Controller（例如 `traefik`，`nginx`，`haproxy`）
- 对于 Kubernetes v1.25 或更高版本，将 `global.cattle.psp.enabled` 设置为 `false`。
```
helm install rancher rancher-<CHART_REPO>/rancher \
@@ -277,6 +285,7 @@ deployment "rancher" successfully rolled out
- 设置 `hostname`。
- 将 `bootstrapPassword` 设置为 `admin` 用户独有的值。
- 将 `ingress.tls.source` 设置为 `secret`。
- 对于 Kubernetes v1.25 或更高版本，将 `global.cattle.psp.enabled` 设置为 `false`。
```
helm install rancher rancher-<CHART_REPO>/rancher \
i18n/zh/docusaurus-plugin-content-docs/current/pages-for-subheaders/k3s-hardening-guide.md
+728
View File
@@ -0,0 +1,728 @@
---
title: K3s Hardening Guide
---
This document provides prescriptive guidance for how to harden a K3s cluster intended for production, before provisioning it with Rancher. It outlines the configurations and controls required for Center for Information Security (CIS) Kubernetes benchmark controls.
:::note
This hardening guide describes how to secure the nodes in your cluster. We recommended that you follow this guide before you install Kubernetes.
:::
This hardening guide is intended to be used for K3s clusters and is associated with the following versions of the CIS Kubernetes Benchmark, Kubernetes, and Rancher:
| Rancher Version | CIS Benchmark Version | Kubernetes Version |
|-----------------|-----------------------|------------------------------|
| Rancher v2.7 | Benchmark v1.23 | Kubernetes v1.23 up to v1.25 |
:::note
At the time of writing, the upstream CIS Kubernetes v1.25 benchmark is not yet available in Rancher. At this time Rancher is using the CIS v1.23 benchmark when scanning Kubernetes v1.25 clusters.
:::
For more details on how to evaluate a hardened K3s cluster against the official CIS benchmark, refer to the K3s self-assessment guides for specific Kubernetes and CIS benchmark versions.
K3s passes a number of the Kubernetes CIS controls without modification, as it applies several security mitigations by default. There are some notable exceptions to this that require manual intervention to fully comply with the CIS Benchmark:
1. K3s does not modify the host operating system. Any host-level modifications need to be done manually.
2. Certain CIS policy controls for `NetworkPolicies` and `PodSecurityStandards` (`PodSecurityPolicies` on v1.24 and older) restrict cluster functionality.
You must opt into having K3s configure these policies. Add the appropriate options to your command-line flags or configuration file (enable admission plugins), and manually apply the appropriate policies.
See further for more details.
The first section (1.1) of the CIS Benchmark primarily focuses on pod manifest permissions and ownership. Since everything in the distribution is packaged in a single binary, this section does not apply to the core components of K3s.
## Host-level Requirements
### Ensure `protect-kernel-defaults` is set
This is a kubelet flag that will cause the kubelet to exit if the required kernel parameters are unset or are set to values that are different from the kubelet's defaults.
The `protect-kernel-defaults` flag can be set in the cluster configuration in Rancher.
```yaml
spec:
rkeConfig:
machineSelectorConfig:
- config:
protect-kernel-defaults: true
```
### Set kernel parameters
The following `sysctl` configuration is recommended for all nodes type in the cluster. Set the following parameters in `/etc/sysctl.d/90-kubelet.conf`:
```ini
vm.panic_on_oom=0
vm.overcommit_memory=1
kernel.panic=10
kernel.panic_on_oops=1
```
Run `sudo sysctl -p /etc/sysctl.d/90-kubelet.conf` to enable the settings.
This configuration needs to be done before setting the kubelet flag, otherwise K3s will fail to start.
## Kubernetes Runtime Requirements
The CIS Benchmark runtime requirements center around pod security (via PSP or PSA), network policies and API Server auditing logs.
By default, K3s does not include any pod security or network policies. However, K3s ships with a controller that enforces any network policies you create. By default, K3s enables both the `PodSecurity` and `NodeRestriction` admission controllers, among others.
### Pod Security
<Tabs groupId="k3s-version">
<TabItem value="v1.25 and Newer" default>
K3s v1.25 and newer support [Pod Security admission (PSA)](https://kubernetes.io/docs/concepts/security/pod-security-admission/) for controlling pod security.
You can specify the PSA configuration by setting the `defaultPodSecurityAdmissionConfigurationTemplateName` field in the cluster configuration in Rancher:
```yaml
spec:
defaultPodSecurityAdmissionConfigurationTemplateName: rancher-restricted
```
The `rancher-restricted` template is provided by Rancher to enforce the highly-restrictive Kubernetes upstream [`Restricted`](https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted) profile with best practices for pod hardening.
</TabItem>
<TabItem value="v1.24 and Older">
K3s v1.24 and older support [Pod Security Policy (PSP)](https://v1-24.docs.kubernetes.io/docs/concepts/security/pod-security-policy/) for controlling pod security.
You can enable PSPs by passing the following flags in the cluster configuration in Rancher:
```yaml
spec:
rkeConfig:
machineGlobalConfig:
kube-apiserver-arg:
- enable-admission-plugins=NodeRestriction,PodSecurityPolicy,ServiceAccount
```
This maintains the `NodeRestriction` plugin and enables the `PodSecurityPolicy`.
Once you enable PSPs, you can apply a policy to satisfy the necessary controls described in section 5.2 of the CIS Benchmark.
:::note
These are manual checks in the CIS Benchmark. The CIS scan flags the results as `warning`, because manual inspection is necessary by the cluster operator.
:::
Here is an example of a compliant PSP:
```yaml
---
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: restricted-psp
spec:
privileged: false # CIS - 5.2.1
allowPrivilegeEscalation: false # CIS - 5.2.5
requiredDropCapabilities: # CIS - 5.2.7/8/9
- ALL
volumes:
- 'configMap'
- 'emptyDir'
- 'projected'
- 'secret'
- 'downwardAPI'
- 'csi'
- 'persistentVolumeClaim'
- 'ephemeral'
hostNetwork: false # CIS - 5.2.4
hostIPC: false # CIS - 5.2.3
hostPID: false # CIS - 5.2.2
runAsUser:
rule: 'MustRunAsNonRoot' # CIS - 5.2.6
seLinux:
rule: 'RunAsAny'
supplementalGroups:
rule: 'MustRunAs'
ranges:
- min: 1
max: 65535
fsGroup:
rule: 'MustRunAs'
ranges:
- min: 1
max: 65535
readOnlyRootFilesystem: false
```
For the example PSP to be effective, we need to create a `ClusterRole` and a `ClusterRoleBinding`. We also need to include a "system unrestricted policy" for system-level pods that require additional privileges, and an additional policy that allows the necessary sysctls for full functionality of ServiceLB.
```yaml
---
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: restricted-psp
spec:
privileged: false
allowPrivilegeEscalation: false
requiredDropCapabilities:
- ALL
volumes:
- 'configMap'
- 'emptyDir'
- 'projected'
- 'secret'
- 'downwardAPI'
- 'csi'
- 'persistentVolumeClaim'
- 'ephemeral'
hostNetwork: false
hostIPC: false
hostPID: false
runAsUser:
rule: 'MustRunAsNonRoot'
seLinux:
rule: 'RunAsAny'
supplementalGroups:
rule: 'MustRunAs'
ranges:
- min: 1
max: 65535
fsGroup:
rule: 'MustRunAs'
ranges:
- min: 1
max: 65535
readOnlyRootFilesystem: false
---
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: system-unrestricted-psp
annotations:
seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*'
spec:
allowPrivilegeEscalation: true
allowedCapabilities:
- '*'
fsGroup:
rule: RunAsAny
hostIPC: true
hostNetwork: true
hostPID: true
hostPorts:
- max: 65535
min: 0
privileged: true
runAsUser:
rule: RunAsAny
seLinux:
rule: RunAsAny
supplementalGroups:
rule: RunAsAny
volumes:
- '*'
---
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: svclb-psp
annotations:
seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*'
spec:
allowPrivilegeEscalation: false
allowedCapabilities:
- NET_ADMIN
allowedUnsafeSysctls:
- net.ipv4.ip_forward
- net.ipv6.conf.all.forwarding
fsGroup:
rule: RunAsAny
hostPorts:
- max: 65535
min: 0
runAsUser:
rule: RunAsAny
seLinux:
rule: RunAsAny
supplementalGroups:
rule: RunAsAny
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: psp:restricted-psp
rules:
- apiGroups:
- policy
resources:
- podsecuritypolicies
verbs:
- use
resourceNames:
- restricted-psp
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: psp:system-unrestricted-psp
rules:
- apiGroups:
- policy
resources:
- podsecuritypolicies
resourceNames:
- system-unrestricted-psp
verbs:
- use
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: psp:svclb-psp
rules:
- apiGroups:
- policy
resources:
- podsecuritypolicies
resourceNames:
- svclb-psp
verbs:
- use
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: psp:svc-local-path-provisioner-psp
rules:
- apiGroups:
- policy
resources:
- podsecuritypolicies
resourceNames:
- system-unrestricted-psp
verbs:
- use
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: psp:svc-coredns-psp
rules:
- apiGroups:
- policy
resources:
- podsecuritypolicies
resourceNames:
- system-unrestricted-psp
verbs:
- use
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: psp:svc-cis-operator-psp
rules:
- apiGroups:
- policy
resources:
- podsecuritypolicies
resourceNames:
- system-unrestricted-psp
verbs:
- use
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: default:restricted-psp
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: psp:restricted-psp
subjects:
- kind: Group
name: system:authenticated
apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: system-unrestricted-node-psp-rolebinding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: psp:system-unrestricted-psp
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: system:nodes
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: system-unrestricted-svc-acct-psp-rolebinding
namespace: kube-system
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: psp:system-unrestricted-psp
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: system:serviceaccounts
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: svclb-psp-rolebinding
namespace: kube-system
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: psp:svclb-psp
subjects:
- kind: ServiceAccount
name: svclb
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: svc-local-path-provisioner-psp-rolebinding
namespace: kube-system
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: psp:svc-local-path-provisioner-psp
subjects:
- kind: ServiceAccount
name: local-path-provisioner-service-account
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: svc-coredns-psp-rolebinding
namespace: kube-system
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: psp:svc-coredns-psp
subjects:
- kind: ServiceAccount
name: coredns
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: svc-cis-operator-psp-rolebinding
namespace: cis-operator-system
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: psp:svc-cis-operator-psp
subjects:
- kind: ServiceAccount
name: cis-operator-serviceaccount
```
The policies presented above can be placed in a file named `policy.yaml` in the `/var/lib/rancher/k3s/server/manifests` directory. Both the policy file and the its directory hierarchy must be created before starting K3s. A restrictive access permission is recommended to avoid leaking potential sensitive information.
```shell
sudo mkdir -p -m 700 /var/lib/rancher/k3s/server/manifests
```
:::note
The critical Kubernetes additions such as CNI, DNS, and Ingress are run as pods in the `kube-system` namespace. Therefore, this namespace has a less restrictive policy, so that these components can run properly.
:::
</TabItem>
</Tabs>
### Network Policies
CIS requires that all namespaces apply a network policy that reasonably limits traffic into namespaces and pods.
:::note
This is a manual check in the CIS Benchmark. The CIS scan flags the result as a `warning`, because manual inspection is necessary by the cluster operator.
:::
The network policies can be placed in the `policy.yaml` file in `/var/lib/rancher/k3s/server/manifests` directory. If the directory was not created as part of the PSP (as described above), it must be created first.
```shell
sudo mkdir -p -m 700 /var/lib/rancher/k3s/server/manifests
```
Here is an example of a compliant network policy:
```yaml
---
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: intra-namespace
namespace: kube-system
spec:
podSelector: {}
ingress:
- from:
- namespaceSelector:
matchLabels:
name: kube-system
---
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: intra-namespace
namespace: default
spec:
podSelector: {}
ingress:
- from:
- namespaceSelector:
matchLabels:
name: default
---
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: intra-namespace
namespace: kube-public
spec:
podSelector: {}
ingress:
- from:
- namespaceSelector:
matchLabels:
name: kube-public
```
The active restrictions block DNS unless purposely allowed. Below is a network policy that allows DNS-related traffic:
```yaml
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-network-dns-policy
namespace: <NAMESPACE>
spec:
ingress:
- ports:
- port: 53
protocol: TCP
- port: 53
protocol: UDP
podSelector:
matchLabels:
k8s-app: kube-dns
policyTypes:
- Ingress
```
The metrics-server and Traefik ingress controller are blocked by default if network policies are not created to allow access.
```yaml
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-all-metrics-server
namespace: kube-system
spec:
podSelector:
matchLabels:
k8s-app: metrics-server
ingress:
- {}
policyTypes:
- Ingress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-all-svclbtraefik-ingress
namespace: kube-system
spec:
podSelector:
matchLabels:
svccontroller.k3s.cattle.io/svcname: traefik
ingress:
- {}
policyTypes:
- Ingress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-all-traefik-v121-ingress
namespace: kube-system
spec:
podSelector:
matchLabels:
app.kubernetes.io/name: traefik
ingress:
- {}
policyTypes:
- Ingress
```
:::note
You must manage network policies as normal for any additional namespaces you create.
:::
### API Server audit configuration
CIS requirements 1.2.22 to 1.2.25 are related to configuring audit logs for the API Server. K3s does not create by default the log directory and audit policy, as auditing requirements are specific to each user's policies and environment.
If you need a log directory, it must be created before you start K3s. We recommend a restrictive access permission to avoid leaking sensitive information.
```bash
sudo mkdir -p -m 700 /var/lib/rancher/k3s/server/logs
```
The following is a starter audit policy to log request metadata. This policy should be written to a file named `audit.yaml` in the `/var/lib/rancher/k3s/server` directory. Detailed information about policy configuration for the API server can be found in the [official Kubernetes documentation](https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/).
```yaml
---
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata
```
Further configurations are also needed to pass CIS checks. These are not configured by default in K3s, because they vary based on your environment and needs:
- Ensure that the `--audit-log-path` argument is set.
- Ensure that the `--audit-log-maxage` argument is set to 30 or as appropriate.
- Ensure that the `--audit-log-maxbackup` argument is set to 10 or as appropriate.
- Ensure that the `--audit-log-maxsize` argument is set to 100 or as appropriate.
Combined, to enable and configure audit logs, add the following lines to the K3s cluster configuration file in Rancher:
```yaml
spec:
rkeConfig:
machineGlobalConfig:
kube-apiserver-arg:
- audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml # CIS 3.2.1
- audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log # CIS 1.2.18
- audit-log-maxage=30 # CIS 1.2.19
- audit-log-maxbackup=10 # CIS 1.2.20
- audit-log-maxsize=100 # CIS 1.2.21
```
### Controller Manager Requirements
CIS requirement 1.3.1 checks for garbage collection settings in the Controller Manager. Garbage collection is important to ensure sufficient resource availability and avoid degraded performance and availability. Based on your system resources and tests, choose an appropriate threshold value to activate garbage collection.
This can be remediated by setting the following configuration in the K3s cluster file in Rancher. The value below is only an example. The appropriate threshold value is specific to each user's environment.
```yaml
spec:
rkeConfig:
machineGlobalConfig:
kube-controller-manager-arg:
- terminated-pod-gc-threshold=10 # CIS 1.3.1
```
### Configure `default` Service Account
Kubernetes provides a `default` service account which is used by cluster workloads where no specific service account is assigned to the pod. Where access to the Kubernetes API from a pod is required, a specific service account should be created for that pod, and rights granted to that service account.
For CIS requirement 5.1.5 the `default` service account should be configured such that it does not provide a service account token and does not have any explicit rights assignments.
This can be remediated by updating the `automountServiceAccountToken` field to `false` for the `default` service account in each namespace.
For `default` service accounts in the built-in namespaces (`kube-system`, `kube-public`, `kube-node-lease`, and `default)`, K3s does not automatically do this.
Save the following configuration to a file called `account_update.yaml`.
```yaml
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: default
automountServiceAccountToken: false
```
Create a bash script file called `account_update.sh`. Be sure to `chmod +x account_update.sh` so the script has execute permissions.
```shell
#!/bin/bash -e
for namespace in $(kubectl get namespaces -A -o=jsonpath="{.items[*]['metadata.name']}"); do
kubectl patch serviceaccount default -n ${namespace} -p "$(cat account_update.yaml)"
done
```
Run the script every time a new service account is added to your cluster.
## Reference Hardened K3s Template Configuration
The following reference template configuration is used in Rancher to create a hardened K3s custom cluster based on each CIS control in this guide. This reference does not include other required **cluster configuration** directives, which vary based on your environment.
<Tabs groupId="k3s-version">
<TabItem value="v1.25 and Newer" default>
```yaml
apiVersion: provisioning.cattle.io/v1
kind: Cluster
metadata:
name: # Define cluster name
spec:
defaultPodSecurityAdmissionConfigurationTemplateName: rancher-restricted
enableNetworkPolicy: true
kubernetesVersion: # Define K3s version
rkeConfig:
machineGlobalConfig:
kube-apiserver-arg:
- enable-admission-plugins=NodeRestriction,ServiceAccount # CIS 1.2.15, 1.2.13
- audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml # CIS 3.2.1
- audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log # CIS 1.2.18
- audit-log-maxage=30 # CIS 1.2.19
- audit-log-maxbackup=10 # CIS 1.2.20
- audit-log-maxsize=100 # CIS 1.2.21
- request-timeout=300s # CIS 1.2.22
- service-account-lookup=true # CIS 1.2.24
kube-controller-manager-arg:
- terminated-pod-gc-threshold=10 # CIS 1.3.1
secrets-encryption: true
machineSelectorConfig:
- config:
kubelet-arg:
- make-iptables-util-chains=true # CIS 4.2.7
protect-kernel-defaults: true # CIS 4.2.6
```
</TabItem>
<TabItem value="v1.24 and Older">
```yaml
apiVersion: provisioning.cattle.io/v1
kind: Cluster
metadata:
name: # Define cluster name
spec:
enableNetworkPolicy: true
kubernetesVersion: # Define K3s version
rkeConfig:
machineGlobalConfig:
kube-apiserver-arg:
- enable-admission-plugins=NodeRestriction,PodSecurityPolicy,ServiceAccount # CIS 1.2.15, 5.2, 1.2.13
- audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml # CIS 3.2.1
- audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log # CIS 1.2.18
- audit-log-maxage=30 # CIS 1.2.19
- audit-log-maxbackup=10 # CIS 1.2.20
- audit-log-maxsize=100 # CIS 1.2.21
- request-timeout=300s # CIS 1.2.22
- service-account-lookup=true # CIS 1.2.24
kube-controller-manager-arg:
- terminated-pod-gc-threshold=10 # CIS 1.3.1
secrets-encryption: true
machineSelectorConfig:
- config:
kubelet-arg:
- make-iptables-util-chains=true # CIS 4.2.7
protect-kernel-defaults: true # CIS 4.2.6
```
</TabItem>
</Tabs>
## Conclusion
If you have followed this guide, your K3s custom cluster provisioned by Rancher will be configured to pass the CIS Kubernetes Benchmark. You can review our K3s self-assessment guides to understand how we verified each of the benchmarks and how you can do the same on your cluster.
i18n/zh/docusaurus-plugin-content-docs/current/pages-for-subheaders/rancher-hardening-guides.md
+52
View File
@@ -0,0 +1,52 @@
---
title: Self-Assessment and Hardening Guides for Rancher
---
Rancher provides specific security hardening guides for each supported Rancher version's Kubernetes distributions.
## Rancher Kubernetes Distributions
Rancher uses the following Kubernetes distributions:
- [**RKE**](https://rancher.com/docs/rke/latest/en/), Rancher Kubernetes Engine, is a CNCF-certified Kubernetes distribution that runs entirely within Docker containers.
- [**RKE2**](https://docs.rke2.io/) is a fully conformant Kubernetes distribution that focuses on security and compliance within the U.S. Federal Government sector.
- [**K3s**](https://docs.k3s.io/) is a fully conformant, lightweight Kubernetes distribution. It is easy to install, with half the memory requirement of upstream Kubernetes, all in a binary of less than 100 MB.
To harden a Kubernetes cluster that's running a distribution other than those listed, refer to your Kubernetes provider docs.
## Hardening Guides and Benchmark Versions
Each self-assessment guide is accompanied by a hardening guide. These guides were tested alongside the listed Rancher releases. Each self-assessment guides was tested on a specific Kubernetes version and CIS benchmark version. If a CIS benchmark has not been validated for your Kubernetes version, you can use the existing guides until a guide for your version is added.
### RKE Guides
| Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guides |
|--------------------|-----------------------|-----------------------|------------------|
| Kubernetes v1.23 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.23-k8s-v1.23.md) | [Link](rke1-hardening-guide.md) |
| Kubernetes v1.24 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.23-k8s-v1.24.md) | [Link](rke1-hardening-guide.md) |
| Kubernetes v1.25 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.23-k8s-v1.25.md) | [Link](rke1-hardening-guide.md) |
### RKE2 Guides
| Type | Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guides |
|------|--------------------|-----------------------|-----------------------|------------------|
| Rancher provisioned RKE2 | Kubernetes v1.23 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.23-k8s-v1.23.md) | [Link](rke2-hardening-guide.md) |
| Rancher provisioned RKE2 | Kubernetes v1.24 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.23-k8s-v1.24.md) | [Link](rke2-hardening-guide.md) |
| Rancher provisioned RKE2 | Kubernetes v1.25 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.23-k8s-v1.25.md) | [Link](rke2-hardening-guide.md) |
| Standalone RKE2 | Kubernetes v1.25 | CIS v1.23 | [Link](https://docs.rke2.io/security/cis_self_assessment123) | [Link](https://docs.rke2.io/security/hardening_guide) |
### K3s Guides
| Type | Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guides |
|------|--------------------|-----------------------|-----------------------|------------------|
| Rancher provisioned K3s cluster | Kubernetes v1.23 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.23-k8s-v1.23.md) | [Link](k3s-hardening-guide.md) |
| Rancher provisioned K3s cluster | Kubernetes v1.24 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.23-k8s-v1.24.md) | [Link](k3s-hardening-guide.md) |
| Rancher provisioned K3s cluster | Kubernetes v1.25 | CIS v1.23 | [Link](../reference-guides/rancher-security/hardening-guides/k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.23-k8s-v1.25.md) | [Link](k3s-hardening-guide.md) |
| Standalone K3s | Kubernetes v1.22 up to v1.24 | CIS v1.23 | [Link](https://docs.k3s.io/security/self-assessment) | [Link](https://docs.k3s.io/security/hardening-guide) |
## Rancher with SELinux
[Security-Enhanced Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) is a kernel module that adds extra access controls and security tools to Linux. Historically used by government agencies, SELinux is now industry-standard. SELinux is enabled by default on RHEL and CentOS.
To use Rancher with SELinux, we recommend [installing](../reference-guides/rancher-security/selinux-rpm/about-rancher-selinux.md) the `rancher-selinux` RPM.
i18n/zh/docusaurus-plugin-content-docs/current/pages-for-subheaders/rancher-security.md
+1 -1
View File
@@ -70,7 +70,7 @@ Rancher 每个版本的自我评估指南都对应特定的强化指南、Ranche
### 第三方渗透测试报告
Rancher 会定期聘请第三方对 Rancher 2.x 软件栈进行安全审核和渗透测试。测试环境会遵循 Rancher 提供的强化指南。测试结果会在第三方确认我们已经修复了 MEDIUM 或以上的问题后发布。
Rancher 会定期聘请第三方对 Rancher 2.x 软件栈进行安全审核和渗透测试。测试环境会遵循 Rancher 提供的强化指南。旧的渗透测试报告如下。
结果：
i18n/zh/docusaurus-plugin-content-docs/current/pages-for-subheaders/rancher-v2.6-hardening-guides.md
-51
View File
@@ -1,51 +0,0 @@
---
title: Rancher 2.6 的自我评估和强化指南
---
Rancher 为每个受支持的 Rancher Kubernetes 发行版提供了对应的安全强化指南。
## Rancher Kubernetes 发行版
Rancher 使用以下 Kubernetes 发行版：
- [**RKE**](https://rancher.com/docs/rke/latest/en/)：全称是 Rancher Kubernetes Engine，一个 CNCF 认证的 Kubernetes 发行版，能完全在 Docker 容器中运行。
- [**RKE2**](https://docs.rke2.io/)：一个完全合规的 Kubernetes 发行版，专注于安全和合规性。
- [**K3s**](https://rancher.com/docs/k3s/latest/en/)：一个完全符合要求的轻量级 Kubernetes 发行版。它易于安装，仅需要上游 Kubernetes 内存的一半，所有组件都在一个小于 100 MB 的二进制文件中。
要在 Rancher 发行版之外强化 Kubernetes 集群，请参阅你的 Kubernetes 提供商文档。
## 强化指南和 Benchmark 版本
这些指南已与 Rancher 2.6 版本一起测试。每个自我评估指南都附有强化指南，并在特定的 Kubernetes 版本和 CIS Benchmark 版本上进行了测试。如果 CIS Benchmark 测试尚未针对你的 Kubernetes 版本进行验证，你可以先使用现有指南。
### RKE 指南
| Kubernetes 版本 | CIS Benchmark 版本 | 自我评估指南 | 强化指南 |
| ------------------ | --------------------- | --------------------- | ---------------- |
| Kubernetes v1.18 到 v1.23 | CIS v1.6 | [链接](../reference-guides/rancher-security/rancher-v2.6-hardening-guides/rke1-self-assessment-guide-with-cis-v1.6-benchmark.md) | [链接](../reference-guides/rancher-security/rancher-v2.6-hardening-guides/rke1-hardening-guide-with-cis-v1.6-benchmark.md) |
:::note
- Kubernetes v1.19 和 v1.20 的 CIS v1.20 Benchmark 版本尚未作为配置文件发布在 Rancher 的 CIS Benchmark Chart 中。
:::
### RKE2 指南
| 类型 | Kubernetes 版本 | CIS Benchmark 版本 | 自我评估指南 | 强化指南 |
| ---- | ------------------ | --------------------- | --------------------- | ---------------- |
| Rancher 配置的 RKE2 集群 | Kubernetes v1.21 到 v1.23 | CIS v1.6 | [链接](../reference-guides/rancher-security/rancher-v2.6-hardening-guides/rke2-self-assessment-guide-with-cis-v1.6-benchmark.md) | [链接](../reference-guides/rancher-security/rancher-v2.6-hardening-guides/rke2-hardening-guide-with-cis-v1.6-benchmark.md) |
| 独立 RKE2 | Kubernetes v1.21 到 v1.23 | CIS v1.6 | [链接](https://docs.rke2.io/security/cis_self_assessment16/) | [链接](https://docs.rke2.io/security/hardening_guide/) |
### K3s 指南
| 类型 | Kubernetes 版本 | CIS Benchmark 版本 | 自我评估指南 | 强化指南 |
| ---- | ------------------ | --------------------- | --------------------- | ---------------- |
| 独立 K3s | Kubernetes v1.21 和 v1.22 | CIS v1.6 | [链接](https://docs.k3s.io/security/self-assessment) | [链接](https://docs.k3s.io/security/hardening-guide) |
## 使用 SELinux 的 Rancher
[安全增强型 Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) 是对 Linux 的安全增强。被政府机构使用之后，SELinux 已成为行业标准，并在 RHEL 和 CentOS 上默认启用。
要配合使用 Rancher 与 SELinux，我们建议你根据[此页面](selinux-rpm.md#安装-rancher-selinux-rpm)的安装说明安装 `rancher-selinux` RPM。
i18n/zh/docusaurus-plugin-content-docs/current/pages-for-subheaders/rancher-v2.7-hardening-guides.md
-52
View File
@@ -1,52 +0,0 @@
---
title: Rancher v2.7 的自我评估和强化指南
---
Rancher 为每个受支持的 Rancher Kubernetes 发行版提供了对应的安全强化指南。
## Rancher Kubernetes 发行版
Rancher 使用以下 Kubernetes 发行版：
- [**RKE**](https://rancher.com/docs/rke/latest/en/)：全称是 Rancher Kubernetes Engine，一个 CNCF 认证的 Kubernetes 发行版，能完全在 Docker 容器中运行。
- [**RKE2**](https://docs.rke2.io/)：一个完全合规的 Kubernetes 发行版，专注于安全和合规性。
- [**K3s**](https://rancher.com/docs/k3s/latest/en/)：一个完全符合要求的轻量级 Kubernetes 发行版。它易于安装，仅需要上游 Kubernetes 内存的一半，所有组件都在一个小于 100 MB 的二进制文件中。
要在 Rancher 发行版之外强化 Kubernetes 集群，请参阅你的 Kubernetes 提供商文档。
## 强化指南和 Benchmark 版本
这些指南已与 Rancher 2.7 版本一起测试。每个自我评估指南都附有强化指南，并在特定的 Kubernetes 版本和 CIS Benchmark 版本上进行了测试。如果 CIS Benchmark 测试尚未针对你的 Kubernetes 版本进行验证，你可以先使用现有指南。
### RKE 指南
| Kubernetes 版本 | CIS Benchmark 版本 | 自我评估指南 | 强化指南 |
| ------------------ | --------------------- | --------------------- | ---------------- |
| Kubernetes v1.18 到 v1.23 | CIS v1.6 | [链接](../reference-guides/rancher-security/rancher-v2.6-hardening-guides/rke1-self-assessment-guide-with-cis-v1.6-benchmark.md) | [链接](../reference-guides/rancher-security/rancher-v2.6-hardening-guides/rke1-hardening-guide-with-cis-v1.6-benchmark.md) |
:::note
- Kubernetes v1.19 和 v1.20 的 CIS v1.20 Benchmark 版本尚未作为配置文件发布在 Rancher 的 CIS Benchmark Chart 中。
:::
### RKE2 指南
| 类型 | Kubernetes 版本 | CIS Benchmark 版本 | 自我评估指南 | 强化指南 |
| ---- | ------------------ | --------------------- | --------------------- | ---------------- |
| Rancher 配置的 RKE2 集群 | Kubernetes v1.21 到 v1.23 | CIS v1.6 | [链接](../reference-guides/rancher-security/rancher-v2.6-hardening-guides/rke2-self-assessment-guide-with-cis-v1.6-benchmark.md) | [链接](../reference-guides/rancher-security/rancher-v2.6-hardening-guides/rke2-hardening-guide-with-cis-v1.6-benchmark.md) |
| 独立 RKE2 | Kubernetes v1.21 到 v1.23 | CIS v1.6 | [链接](https://docs.rke2.io/security/cis_self_assessment16/) | [链接](https://docs.rke2.io/security/hardening_guide/) |
### K3s 指南
| 类型 | Kubernetes 版本 | CIS Benchmark 版本 | 自我评估指南 | 强化指南 |
| ---- | ------------------ | --------------------- | --------------------- | ---------------- |
| Rancher 配置的 K3s 集群 | Kubernetes v1.21 到 v1.24 | CIS v1.20 和 v1.23 | [CIS v1.20](../reference-guides/rancher-security/rancher-v2.7-hardening-guides/k3s-self-assessment-guide-with-cis-v1.20-benchmark.md) 和 [CIS v1.23](../reference-guides/rancher-security/rancher-v2.7-hardening-guides/k3s-self-assessment-guide-with-cis-v1.23-benchmark.md) | [链接](../reference-guides/rancher-security/rancher-v2.7-hardening-guides/k3s-hardening-guide-with-cis-benchmark.md) |
| 独立 K3s | Kubernetes v1.21 和 v1.22 | CIS v1.6 | [链接](https://docs.k3s.io/security/self-assessment) | [链接](https://docs.k3s.io/security/hardening-guide) |
## 使用 SELinux 的 Rancher
[安全增强型 Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) 是对 Linux 的安全增强。被政府机构使用之后，SELinux 已成为行业标准，并在 RHEL 和 CentOS 上默认启用。
要配合使用 Rancher 与 SELinux，我们建议你根据[此页面](selinux-rpm.md#安装-rancher-selinux-rpm)的安装说明安装 `rancher-selinux` RPM。
i18n/zh/docusaurus-plugin-content-docs/current/pages-for-subheaders/rke1-hardening-guide.md
+504
View File
@@ -0,0 +1,504 @@
---
title: RKE Hardening Guide
---
This document provides prescriptive guidance for how to harden an RKE cluster intended for production, before provisioning it with Rancher. It outlines the configurations and controls required for Center for Information Security (CIS) Kubernetes benchmark controls.
:::note
This hardening guide describes how to secure the nodes in your cluster. We recommended that you follow this guide before you install Kubernetes.
:::
This hardening guide is intended to be used for RKE clusters and is associated with the following versions of the CIS Kubernetes Benchmark, Kubernetes, and Rancher:
| Rancher Version | CIS Benchmark Version | Kubernetes Version |
|-----------------|-----------------------|------------------------------|
| Rancher v2.7 | Benchmark v1.23 | Kubernetes v1.23 up to v1.25 |
:::note
At the time of writing, the upstream CIS Kubernetes v1.25 benchmark is not yet available in Rancher. At this time Rancher is using the CIS v1.23 benchmark when scanning Kubernetes v1.25 clusters. Due to that, the CIS checks 5.2.3, 5.2.4, 5.2.5 and 5.2.6 might fail.
:::
For more details on how to evaluate a hardened RKE cluster against the official CIS benchmark, refer to the RKE self-assessment guides for specific Kubernetes and CIS benchmark versions.
## Host-level requirements
### Configure Kernel Runtime Parameters
The following `sysctl` configuration is recommended for all nodes types in the cluster. Set the following parameters in `/etc/sysctl.d/90-kubelet.conf`:
```ini
vm.overcommit_memory=1
vm.panic_on_oom=0
kernel.panic=10
kernel.panic_on_oops=1
```
Run `sysctl -p /etc/sysctl.d/90-kubelet.conf` to enable the settings.
### Configure `etcd` user and group
A user account and group for the **etcd** service is required to be set up before installing RKE.
#### Create `etcd` user and group
To create the **etcd** user and group run the following console commands.
The commands below use `52034` for **uid** and **gid** for example purposes.
Any valid unused **uid** or **gid** could also be used in lieu of `52034`.
```bash
groupadd --gid 52034 etcd
useradd --comment "etcd service account" --uid 52034 --gid 52034 etcd --shell /usr/sbin/nologin
```
When deploying RKE through its cluster configuration `config.yml` file, update the `uid` and `gid` of the `etcd` user:
```yaml
services:
etcd:
gid: 52034
uid: 52034
```
## Kubernetes runtime requirements
### Configure `default` Service Account
#### Set `automountServiceAccountToken` to `false` for `default` service accounts
Kubernetes provides a default service account which is used by cluster workloads where no specific service account is assigned to the pod.
Where access to the Kubernetes API from a pod is required, a specific service account should be created for that pod, and rights granted to that service account.
The default service account should be configured such that it does not provide a service account token and does not have any explicit rights assignments.
For each namespace including `default` and `kube-system` on a standard RKE install, the `default` service account must include this value:
```yaml
automountServiceAccountToken: false
```
Save the following configuration to a file called `account_update.yaml`.
```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: default
automountServiceAccountToken: false
```
Create a bash script file called `account_update.sh`.
Be sure to `chmod +x account_update.sh` so the script has execute permissions.
```bash
#!/bin/bash -e
for namespace in $(kubectl get namespaces -A -o=jsonpath="{.items[*]['metadata.name']}"); do
kubectl patch serviceaccount default -n ${namespace} -p "$(cat account_update.yaml)"
done
```
Execute this script to apply the `account_update.yaml` configuration to `default` service account in all namespaces.
### Configure Network Policy
#### Ensure that all Namespaces have Network Policies defined
Running different applications on the same Kubernetes cluster creates a risk of one compromised application attacking a neighboring application. Network segmentation is important to ensure that containers can communicate only with those they are supposed to. A network policy is a specification of how selections of pods are allowed to communicate with each other and other network endpoints.
Network Policies are namespace scoped. When a network policy is introduced to a given namespace, all traffic not allowed by the policy is denied. However, if there are no network policies in a namespace all traffic will be allowed into and out of the pods in that namespace. To enforce network policies, a container network interface (CNI) plugin must be enabled. This guide uses [Canal](https://github.com/projectcalico/canal) to provide the policy enforcement. Additional information about CNI providers can be found [here](https://www.suse.com/c/rancher_blog/comparing-kubernetes-cni-providers-flannel-calico-canal-and-weave/).
Once a CNI provider is enabled on a cluster a default network policy can be applied. For reference purposes a **permissive** example is provided below. If you want to allow all traffic to all pods in a namespace (even if policies are added that cause some pods to be treated as “isolated”), you can create a policy that explicitly allows all traffic in that namespace. Save the following configuration as `default-allow-all.yaml`. Additional [documentation](https://kubernetes.io/docs/concepts/services-networking/network-policies/) about network policies can be found on the Kubernetes site.
:::caution
This network policy is just an example and is not recommended for production use.
:::
```yaml
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-allow-all
spec:
podSelector: {}
ingress:
- {}
egress:
- {}
policyTypes:
- Ingress
- Egress
```
Create a bash script file called `apply_networkPolicy_to_all_ns.sh`. Be sure to `chmod +x apply_networkPolicy_to_all_ns.sh` so the script has execute permissions.
```bash
#!/bin/bash -e
for namespace in $(kubectl get namespaces -A -o=jsonpath="{.items[*]['metadata.name']}"); do
kubectl apply -f default-allow-all.yaml -n ${namespace}
done
```
Execute this script to apply the `default-allow-all.yaml` configuration with the **permissive** `NetworkPolicy` to all namespaces.
## Known Limitations
- Rancher **exec shell** and **view logs** for pods are **not** functional in a hardened setup when only a public IP is provided when registering custom nodes. This functionality requires a private IP to be provided when registering the custom nodes.
- When setting `default_pod_security_policy_template_id:` to `restricted` or `restricted-noroot`, based on the pod security policies (PSP) [provided](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md) by Rancher, Rancher creates `RoleBindings` and `ClusterRoleBindings` on the `default` service accounts. The CIS check 5.1.5 requires that the `default` service accounts have no roles or cluster roles bound to it apart from the defaults. In addition, the `default` service accounts should be configured such that it does not provide a service account token and does not have any explicit rights assignments.
## Reference Hardened RKE `cluster.yml` Configuration
The reference `cluster.yml` is used by the RKE CLI that provides the configuration needed to achieve a hardened installation of RKE. RKE [documentation](https://rancher.com/docs/rke/latest/en/installation/) provides additional details about the configuration items. This reference `cluster.yml` does not include the required `nodes` directive which will vary depending on your environment. Documentation for node configuration in RKE can be found [here](https://rancher.com/docs/rke/latest/en/config-options/nodes/).
The example `cluster.yml` configuration file contains an Admission Configuration policy in the `services.kube-api.admission_configuration` field. This [sample](../reference-guides/rancher-security/psa-restricted-exemptions.md) policy contains the namespace exemptions necessary for an imported RKE cluster to run properly in Rancher, similar to Rancher's pre-defined [`rancher-restricted`](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/psa-config-templates.md) policy.
If you prefer to use RKE's default `restricted` policy, then leave the `services.kube-api.admission_configuration` field empty and set `services.pod_security_configuration` to `restricted`. See [the RKE docs](https://rke.docs.rancher.com/config-options/services/pod-security-admission) for more information.
<Tabs groupId="rke1-version">
<TabItem value="v1.25 and Newer" default>
:::note
If you intend to import an RKE cluster into Rancher, please consult the [documentation](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/psa-config-templates.md) for how to configure the PSA to exempt Rancher system namespaces.
:::
```yaml
# If you intend to deploy Kubernetes in an air-gapped environment,
# please consult the documentation on how to configure custom RKE images.
nodes: []
kubernetes_version: # Define RKE version
services:
etcd:
uid: 52034
gid: 52034
kube-api:
secrets_encryption_config:
enabled: true
audit_log:
enabled: true
event_rate_limit:
enabled: true
# Leave `pod_security_configuration` out if you are setting a
# custom policy in `admission_configuration`. Otherwise set
# it to `restricted` to use RKE's pre-defined restricted policy,
# and remove everything inside `admission_configuration` field.
#
# pod_security_configuration: restricted
#
admission_configuration:
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: PodSecurity
configuration:
apiVersion: pod-security.admission.config.k8s.io/v1
kind: PodSecurityConfiguration
defaults:
enforce: "restricted"
enforce-version: "latest"
audit: "restricted"
audit-version: "latest"
warn: "restricted"
warn-version: "latest"
exemptions:
usernames: []
runtimeClasses: []
namespaces: [ calico-apiserver,
calico-system,
cattle-alerting,
cattle-csp-adapter-system,
cattle-epinio-system,
cattle-externalip-system,
cattle-fleet-local-system,
cattle-fleet-system,
cattle-gatekeeper-system,
cattle-global-data,
cattle-global-nt,
cattle-impersonation-system,
cattle-istio,
cattle-istio-system,
cattle-logging,
cattle-logging-system,
cattle-monitoring-system,
cattle-neuvector-system,
cattle-prometheus,
cattle-sriov-system,
cattle-system,
cattle-ui-plugin-system,
cattle-windows-gmsa-system,
cert-manager,
cis-operator-system,
fleet-default,
ingress-nginx,
istio-system,
kube-node-lease,
kube-public,
kube-system,
longhorn-system,
rancher-alerting-drivers,
security-scan,
tigera-operator ]
kube-controller:
extra_args:
feature-gates: RotateKubeletServerCertificate=true
kubelet:
extra_args:
feature-gates: RotateKubeletServerCertificate=true
protect-kernel-defaults: "true"
generate_serving_certificate: true
addons: |
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-allow-all
spec:
podSelector: {}
ingress:
- {}
egress:
- {}
policyTypes:
- Ingress
- Egress
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: default
automountServiceAccountToken: false
```
</TabItem>
<TabItem value="v1.24 and Older">
```yaml
# If you intend to deploy Kubernetes in an air-gapped environment,
# please consult the documentation on how to configure custom RKE images.
nodes: []
kubernetes_version: # Define RKE version
services:
etcd:
uid: 52034
gid: 52034
kube-api:
secrets_encryption_config:
enabled: true
audit_log:
enabled: true
event_rate_limit:
enabled: true
pod_security_policy: true
kube-controller:
extra_args:
feature-gates: RotateKubeletServerCertificate=true
kubelet:
extra_args:
feature-gates: RotateKubeletServerCertificate=true
protect-kernel-defaults: true
generate_serving_certificate: true
addons: |
# Upstream Kubernetes restricted PSP policy
# https://github.com/kubernetes/website/blob/564baf15c102412522e9c8fc6ef2b5ff5b6e766c/content/en/examples/policy/restricted-psp.yaml
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: restricted-noroot
spec:
privileged: false
# Required to prevent escalations to root.
allowPrivilegeEscalation: false
requiredDropCapabilities:
- ALL
# Allow core volume types.
volumes:
- 'configMap'
- 'emptyDir'
- 'projected'
- 'secret'
- 'downwardAPI'
# Assume that ephemeral CSI drivers & persistentVolumes set up by the cluster admin are safe to use.
- 'csi'
- 'persistentVolumeClaim'
- 'ephemeral'
hostNetwork: false
hostIPC: false
hostPID: false
runAsUser:
# Require the container to run without root privileges.
rule: 'MustRunAsNonRoot'
seLinux:
# This policy assumes the nodes are using AppArmor rather than SELinux.
rule: 'RunAsAny'
supplementalGroups:
rule: 'MustRunAs'
ranges:
# Forbid adding the root group.
- min: 1
max: 65535
fsGroup:
rule: 'MustRunAs'
ranges:
# Forbid adding the root group.
- min: 1
max: 65535
readOnlyRootFilesystem: false
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: psp:restricted-noroot
rules:
- apiGroups:
- extensions
resourceNames:
- restricted-noroot
resources:
- podsecuritypolicies
verbs:
- use
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: psp:restricted-noroot
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: psp:restricted-noroot
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: system:serviceaccounts
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: system:authenticated
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-allow-all
spec:
podSelector: {}
ingress:
- {}
egress:
- {}
policyTypes:
- Ingress
- Egress
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: default
automountServiceAccountToken: false
```
</TabItem>
</Tabs>
## Reference Hardened RKE Cluster Template Configuration
The reference RKE cluster template provides the minimum required configuration to achieve a hardened installation of Kubernetes. RKE templates are used to provision Kubernetes and define Rancher settings. Follow the Rancher [documentation](installation-and-upgrade.md) for additional information about installing RKE and its template details.
<Tabs groupId="rke1-version">
<TabItem value="v1.25 and Newer" default>
```yaml
#
# Cluster Config
#
default_pod_security_admission_configuration_template_name: rancher-restricted
enable_network_policy: true
local_cluster_auth_endpoint:
enabled: true
name: # Define cluster name
#
# Rancher Config
#
rancher_kubernetes_engine_config:
addon_job_timeout: 45
authentication:
strategy: x509|webhook
kubernetes_version: # Define RKE version
services:
etcd:
uid: 52034
gid: 52034
kube-api:
audit_log:
enabled: true
event_rate_limit:
enabled: true
pod_security_policy: false
secrets_encryption_config:
enabled: true
kube-controller:
extra_args:
feature-gates: RotateKubeletServerCertificate=true
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
kubelet:
extra_args:
feature-gates: RotateKubeletServerCertificate=true
protect-kernel-defaults: true
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
generate_serving_certificate: true
scheduler:
extra_args:
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
```
</TabItem>
<TabItem value="v1.24 and Older">
```yaml
#
# Cluster Config
#
default_pod_security_policy_template_id: restricted-noroot
enable_network_policy: true
local_cluster_auth_endpoint:
enabled: true
name: # Define cluster name
#
# Rancher Config
#
rancher_kubernetes_engine_config:
addon_job_timeout: 45
authentication:
strategy: x509|webhook
kubernetes_version: # Define RKE version
services:
etcd:
uid: 52034
gid: 52034
kube-api:
audit_log:
enabled: true
event_rate_limit:
enabled: true
pod_security_policy: true
secrets_encryption_config:
enabled: true
kube-controller:
extra_args:
feature-gates: RotateKubeletServerCertificate=true
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
kubelet:
extra_args:
feature-gates: RotateKubeletServerCertificate=true
protect-kernel-defaults: true
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
generate_serving_certificate: true
scheduler:
extra_args:
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
```
</TabItem>
</Tabs>
## Conclusion
If you have followed this guide, your RKE custom cluster provisioned by Rancher will be configured to pass the CIS Kubernetes Benchmark. You can review our RKE self-assessment guides to understand how we verified each of the benchmarks and how you can do the same on your cluster.
i18n/zh/docusaurus-plugin-content-docs/current/pages-for-subheaders/rke2-hardening-guide.md
+259
View File
@@ -0,0 +1,259 @@
---
title: RKE2 Hardening Guide
---
This document provides prescriptive guidance for how to harden an RKE2 cluster intended for production, before provisioning it with Rancher. It outlines the configurations and controls required for Center for Information Security (CIS) Kubernetes benchmark controls.
:::note
This hardening guide describes how to secure the nodes in your cluster. We recommended that you follow this guide before you install Kubernetes.
:::
This hardening guide is intended to be used for RKE2 clusters and is associated with the following versions of the CIS Kubernetes Benchmark, Kubernetes, and Rancher:
| Rancher Version | CIS Benchmark Version | Kubernetes Version |
|-----------------|-----------------------|------------------------------|
| Rancher v2.7 | Benchmark v1.23 | Kubernetes v1.23 up to v1.25 |
:::note
At the time of writing, the upstream CIS Kubernetes v1.25 benchmark is not yet available in Rancher. At this time Rancher is using the CIS v1.23 benchmark when scanning Kubernetes v1.25 clusters. Due to that, the CIS checks 5.2.2, 5.2.3, 5.2.5, 5.2.6, 5.2.7 and 5.2.8 might fail.
:::
For more details on how to evaluate a hardened RKE2 cluster against the official CIS benchmark, refer to the RKE2 self-assessment guides for specific Kubernetes and CIS benchmark versions.
RKE2 passes a number of the Kubernetes CIS controls without modification, as it applies several security mitigations by default. There are some notable exceptions to this that require manual intervention to fully comply with the CIS Benchmark:
1. RKE2 will not modify the host operating system. Therefore, you, the operator, must make a few host-level modifications.
2. Certain CIS controls for Network Policies and Pod Security Standards (or Pod Security Policies (PSP) on RKE2 versions prior to v1.25) will restrict the functionality of the cluster. You must opt into having RKE2 configure these for you. To help ensure these requirements are met, RKE2 can be started with the profile flag set to `cis-1.23` for v1.25 and newer or `cis-1.6` for v1.24 and older.
## Host-level requirements
There are two areas of host-level requirements: kernel parameters and etcd process/directory configuration. These are outlined in this section.
### Set kernel parameters
The following `sysctl` configuration is recommended for all nodes type in the cluster. Set the following parameters in `/etc/sysctl.d/90-kubelet.conf`:
```ini
vm.panic_on_oom=0
vm.overcommit_memory=1
kernel.panic=10
kernel.panic_on_oops=1
```
Run `sudo sysctl -p /etc/sysctl.d/90-kubelet.conf` to enable the settings.
### Ensure etcd is configured properly
The CIS Benchmark requires that the etcd data directory be owned by the `etcd` user and group. This implicitly requires the etcd process run as the host-level `etcd` user. To achieve this, RKE2 takes several steps when started with a valid `cis-1.xx` profile:
1. Check that the `etcd` user and group exists on the host. If they don't, exit with an error.
2. Create etcd's data directory with `etcd` as the user and group owner.
3. Ensure the etcd process is ran as the `etcd` user and group by setting the etcd static pod's `SecurityContext` appropriately.
To meet the above requirements, you must:
#### Create the etcd user
On some Linux distributions, the `useradd` command will not create a group. The `-U` flag is included below to account for that. This flag tells `useradd` to create a group with the same name as the user.
```bash
sudo useradd -r -c "etcd user" -s /sbin/nologin -M etcd -U
```
## Kubernetes runtime requirements
The runtime requirements to pass the CIS Benchmark are centered around pod security, network policies and kernel parameters. Most of this is automatically handled by RKE2 when using a valid `cis-1.xx` profile, but some additional operator intervention is required. These are outlined in this section.
### Ensure `protect-kernel-defaults` is set
This is a kubelet flag that will cause the kubelet to exit if the required kernel parameters are unset or are set to values that are different from the kubelet's defaults.
Both `protect-kernel-defaults` and `profile` flags can be set in the RKE2 template configuration file.
When the `profile` flag is set, RKE2 will set the flag to `true` if it is unset.
```yaml
spec:
rkeConfig:
machineSelectorConfig:
- config:
profile: # use cis-1.23 or cis-1.6
protect-kernel-defaults: true
```
### PodSecurity
RKE2 always runs with some amount of pod security.
<Tabs groupId="rke2-version">
<TabItem value="v1.25 and Newer" default>
On v1.25 and newer, [Pod Security Admissions (PSAs)](https://kubernetes.io/docs/concepts/security/pod-security-admission/) are used for pod security.
Below is the minimum necessary configuration needed for hardening RKE2 to pass CIS v1.23 hardened profile `rke2-cis-1.23-hardened` available in Rancher.
```yaml
spec:
defaultPodSecurityAdmissionConfigurationTemplateName: rancher-restricted
rkeConfig:
machineSelectorConfig:
- config:
profile: cis-1.23
```
When both the `defaultPodSecurityAdmissionConfigurationTemplateName` and `profile` flags are set, Rancher and RKE2 does the following:
1. Checks that host-level requirements have been met. If they haven't, RKE2 will exit with a fatal error describing the unmet requirements.
2. Applies network policies that allow the cluster to pass associated controls.
3. Configures the Pod Security Admission Controller with the PSA configuration template `rancher-restricted`, to enforce restricted mode in all namespaces, except the ones in the template's exemption list.
These namespaces are exempted to allow system pods to run without restrictions, which is required for proper operation of the cluster.
:::note
If you intend to import an RKE cluster into Rancher, please consult the [documentation](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/psa-config-templates.md) for how to configure the PSA to exempt Rancher system namespaces.
:::
</TabItem>
<TabItem value="v1.24 and Older">
On Kubernetes v1.24 and older, the `PodSecurityPolicy` admission controller is always enabled.
Below is the minimum necessary configuration needed for hardening RKE2 to pass CIS v1.23 hardened profile `rke2-cis-1.23-hardened` available in Rancher.
:::note
In the following example the profile is set to `cis-1.6` which is the value defined in the upstream RKE2, but the cluster is actually configured to pass the CIS v1.23 hardened profile
:::
```yaml
spec:
defaultPodSecurityPolicyTemplateName: restricted-noroot
rkeConfig:
machineSelectorConfig:
- config:
profile: cis-1.6
```
When both the `defaultPodSecurityPolicyTemplateName` and `profile` flags are set, Rancher and RKE2 does the following:
1. Checks that host-level requirements have been met. If they haven't, RKE2 will exit with a fatal error describing the unmet requirements.
2. Applies network policies that allow the cluster to pass associated controls.
3. Configures runtime pod security policies that allow the cluster to pass associated controls.
</TabItem>
</Tabs>
:::note
The Kubernetes control plane components and critical additions such as CNI, DNS, and Ingress are ran as pods in the `kube-system` namespace. Therefore, this namespace will have a policy that is less restrictive so that these components can run properly.
:::
### NetworkPolicies
When ran with a valid `cis-1.xx` profile, RKE2 will put `NetworkPolicies` in place that passes the CIS Benchmark for Kubernetes' built-in namespaces. These namespaces are: `kube-system`, `kube-public`, `kube-node-lease`, and `default`.
The `NetworkPolicy` used will only allow pods within the same namespace to talk to each other. The notable exception to this is that it allows DNS requests to be resolved.
:::note
Operators must manage network policies as normal for additional namespaces that are created.
:::
### Configure `default` service account
**Set `automountServiceAccountToken` to `false` for `default` service accounts**
Kubernetes provides a `default` service account which is used by cluster workloads where no specific service account is assigned to the pod. Where access to the Kubernetes API from a pod is required, a specific service account should be created for that pod, and rights granted to that service account. The `default` service account should be configured such that it does not provide a service account token and does not have any explicit rights assignments.
For each namespace including `default` and `kube-system` on a standard RKE2 install, the `default` service account must include this value:
```yaml
automountServiceAccountToken: false
```
For namespaces created by the cluster operator, the following script and configuration file can be used to configure the `default` service account.
The configuration bellow must be saved to a file called `account_update.yaml`.
```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: default
automountServiceAccountToken: false
```
Create a bash script file called `account_update.sh`. Be sure to `sudo chmod +x account_update.sh` so the script has execute permissions.
```bash
#!/bin/bash -e
for namespace in $(kubectl get namespaces -A -o=jsonpath="{.items[*]['metadata.name']}"); do
echo -n "Patching namespace $namespace - "
kubectl patch serviceaccount default -n ${namespace} -p "$(cat account_update.yaml)"
done
```
Execute this script to apply the `account_update.yaml` configuration to `default` service account in all namespaces.
### API Server audit configuration
CIS requirements 1.2.19 to 1.2.22 are related to configuring audit logs for the API Server. When RKE2 is started with the `profile` flag set, it will automatically configure hardened `--audit-log-` parameters in the API Server to pass those CIS checks.
RKE2's default audit policy is configured to not log requests in the API Server. This is done to allow cluster operators flexibility to customize an audit policy that suits their auditing requirements and needs, as these are specific to each users' environment and policies.
A default audit policy is created by RKE2 when started with the `profile` flag set. The policy is defined in `/etc/rancher/rke2/audit-policy.yaml`.
```yaml
apiVersion: audit.k8s.io/v1
kind: Policy
metadata:
creationTimestamp: null
rules:
- level: None
```
## Reference Hardened RKE2 Template Configuration
The reference template configuration is used in Rancher to create a hardened RKE2 custom cluster. This reference does not include other required **cluster configuration** directives which will vary depending on your environment.
<Tabs groupId="rke2-version">
<TabItem value="v1.25 and Newer" default>
```yaml
apiVersion: provisioning.cattle.io/v1
kind: Cluster
metadata:
name: # Define cluster name
spec:
defaultPodSecurityAdmissionConfigurationTemplateName: rancher-restricted
kubernetesVersion: # Define RKE2 version
rkeConfig:
machineSelectorConfig:
- config:
profile: cis-1.23
protect-kernel-defaults: true
```
</TabItem>
<TabItem value="v1.24 and Older">
```yaml
apiVersion: provisioning.cattle.io/v1
kind: Cluster
metadata:
name: # Define cluster name
spec:
defaultPodSecurityPolicyTemplateName: restricted-noroot
kubernetesVersion: # Define RKE2 version
rkeConfig:
machineSelectorConfig:
- config:
profile: cis-1.6
protect-kernel-defaults: true
```
</TabItem>
</Tabs>
## Conclusion
If you have followed this guide, your RKE2 custom cluster provisioned by Rancher will be configured to pass the CIS Kubernetes Benchmark. You can review our RKE2 self-assessment guides to understand how we verified each of the benchmarks and how you can do the same on your cluster.
i18n/zh/docusaurus-plugin-content-docs/current/reference-guides/best-practices/rancher-server/on-premises-rancher-in-vsphere.md
+1 -1
View File
@@ -39,7 +39,7 @@ title: 在 vSphere 环境中安装 Rancher
### 根据 Rancher 文档确定虚拟机的大小
请参见[安装要求](https://rancher.com/docs/rancher/v2.6/en/installation/requirements/)来确定虚拟机的大小。
请参阅[安装要求](../../../pages-for-subheaders/installation-requirements.md)。
### 利用虚拟机模板来构建环境
i18n/zh/docusaurus-plugin-content-docs/current/reference-guides/cli-with-rancher/rancher-cli.md
+1 -1
View File
@@ -7,7 +7,7 @@ Rancher CLI（命令行界面）是一个命令行工具，可用于与 Rancher
### 下载 Rancher CLI
你可以直接 UI 下载二进制文件。链接位于 UI 页脚的右侧。我们提供用于 Windows、Mac 和 Linux 的二进制文件。你还可以访问我们的 CLI [发布页面](https://github.com/rancher/cli/releases)直接下载二进制文件。
你可以直接 UI 下载二进制文件。
1. 点击左上角的 **☰**。
1. 单击底部的 **v2.6.x**，**v2.6.x** 是一个超链接文本，表示已安装的 Rancher 版本。
i18n/zh/docusaurus-plugin-content-docs/current/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/amazon-ec2.md
+1
View File
@@ -3,6 +3,7 @@ title: EC2 节点模板配置
---
有关 EC2 和节点的更多详细信息，请参阅 [EC2 管理控制台](https://aws.amazon.com/ec2)的官方文档。
### 区域
在**区域**字段中，选择创建云凭证时使用的同一区域。
i18n/zh/docusaurus-plugin-content-docs/current/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/azure.md
+12 -3
View File
@@ -10,15 +10,24 @@ title: Azure 节点模板配置
- **Network** 配置集群中使用的网络。
- **Instance** 自定义你的 VM 配置。
:::note
:::note
如果在与 VM 不同的资源组中使用 VNet，则 VNet 名称需要以资源组名称作为前缀。例如，`<resource group>:<vnet>`。
如果在与 VM 不同的资源组中使用 VNet，则 VNet 名称需要以资源组名称作为前缀。例如，`<resource group>:<vnet>`。
:::
:::
如果你使用 Docker，[Docker daemon](https://docs.docker.com/engine/docker-overview/#the-docker-daemon) 配置选项包括：
- **标签**：有关标签的信息，请参阅 [Docker 对象标签文档](https://docs.docker.com/config/labels-custom-metadata/)。
- **Docker 引擎安装 URL**：确定要在实例上安装的 Docker 版本。
:::note
如果要配置 Red Hat Enterprise Linux (RHEL) 或 CentOS 节点，请将 **Docker Install URL** 字段保留为默认值，或选择 **none**。由于 Docker 已经安装在这些节点上，因此将绕过 Docker 安装检查。
如果没有将 **Docker Install URL** 设置为默认值或 **none**，你可能会看到错误消息：`Error creating machine: RHEL ssh command error: command: sudo -E yum install -y curl err: exit status 1 output: Updating Subscription Management repositories`。
:::
- **镜像仓库 mirror**：Docker daemon 使用的 Docker 镜像仓库镜像。
- **其他高级选项**：参见 [Docker daemon 选项参考](https://docs.docker.com/engine/reference/commandline/dockerd/)。
i18n/zh/docusaurus-plugin-content-docs/current/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/nutanix.md
+10
View File
@@ -54,3 +54,13 @@ title: Nutanix 节点模板配置
不建议使用基于 cloud-init 的网络配置，仅支持使用用户数据 `runcmd`，不支持 NoCloud 或其他网络配置数据源。
建议使用 Nutanix IP Address Management（IPAM) 或其他 DHCP 服务。
## 引擎选项
在节点模板的**引擎选项**中，你可以配置容器 daemon。你可能需要指定容器版本或容器镜像仓库 Mirror。
:::note
如果要配置 Red Hat Enterprise Linux (RHEL) 或 CentOS 节点，请将 **Docker Install URL** 字段保留为默认值，或选择 **none**。由于 Docker 已经安装在这些节点上，因此将绕过 Docker 安装检查。
如果没有将 **Docker Install URL** 设置为默认值或 **none**，你可能会看到错误消息：`Error creating machine: RHEL ssh command error: command: sudo -E yum install -y curl err: exit status 1 output: Updating Subscription Management repositories`。
:::
i18n/zh/docusaurus-plugin-content-docs/current/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere.md
+10
View File
@@ -83,3 +83,13 @@ title: vSphere 节点模板配置
要使用 cloud-init 初始化，请使用有效的 YAML 语法创建一个 cloud config 文件，并将文件内容粘贴到 **Cloud Init** 字段中。要获取支持的 cloud config 指令的注释示例集，请参阅 [cloud-init 文档](https://cloudinit.readthedocs.io/en/latest/topics/examples.html)。
请注意，使用 ISO 创建方法时不支持 cloud-init。
## 引擎选项
在节点模板的**引擎选项**中，你可以配置容器 daemon。你可能需要指定容器版本或容器镜像仓库 Mirror。
:::note
如果要配置 Red Hat Enterprise Linux (RHEL) 或 CentOS 节点，请将 **Docker Install URL** 字段保留为默认值，或选择 **none**。由于 Docker 已经安装在这些节点上，因此将绕过 Docker 安装检查。
如果没有将 **Docker Install URL** 设置为默认值或 **none**，你可能会看到错误消息：`Error creating machine: RHEL ssh command error: command: sudo -E yum install -y curl err: exit status 1 output: Updating Subscription Management repositories`。
:::
i18n/zh/docusaurus-plugin-content-docs/current/reference-guides/rancher-manager-architecture/rancher-server-and-components.md
+12 -2
View File
@@ -20,6 +20,16 @@ title: Rancher Server 和 Components
Rancher 的 Docker 安装仅推荐用于开发和测试环境中。Rancher 版本决定了能否将 Rancher 迁移到高可用集群。
Rancher backup operator 可将 Rancher 从单个 Docker 容器迁移到高可用 Kubernetes 集群上。详情请参见[把 Rancher 迁移到新集群](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md)。
要查看已部署的资源，运行以下命令：
不管 Rancher Server 是如何安装的，它都应该运行在与其管理的下游集群不同节点上。如果 Rancher 安装在高可用的 Kubernetes 集群上，它需要运行在与其管理的集群不同的集群上。
```bash
kubectl get all -n <namespace>
```
如果你具有管理员权限，你还可以在 Rancher UI 中看到列出的资源：
1. 单击 **☰** 并选择一个集群。
1. 从侧面导航菜单中选择**更多资源**，从而按类型查看已部署的资源。
1. 从侧面导航菜单中选择**集群** > **项目/命名空间**，然后选择一个命名空间，从而按命名空间查看已部署的资源。
Rancher backup operator 可将 Rancher 从单个 Docker 容器迁移到高可用 Kubernetes 集群上。有关详细信息，请参阅[将 Rancher 迁移到新集群](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md)。
不管 Rancher Server 是如何安装的，它都应该运行在与其管理的下游集群不同节点上。如果 Rancher 安装在高可用的 Kubernetes 集群上，它需要运行在与其管理的集群不同的集群上。
i18n/zh/docusaurus-plugin-content-docs/current/reference-guides/rancher-security/hardening-guides/k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.23-k8s-v1.23.md
+3148
View File
File diff suppressed because it is too large Load Diff
i18n/zh/docusaurus-plugin-content-docs/current/reference-guides/rancher-security/hardening-guides/k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.23-k8s-v1.24.md
+3148
View File
File diff suppressed because it is too large Load Diff
i18n/zh/docusaurus-plugin-content-docs/current/reference-guides/rancher-security/hardening-guides/k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.23-k8s-v1.25.md
+3148
View File
File diff suppressed because it is too large Load Diff
i18n/zh/docusaurus-plugin-content-docs/current/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.23-k8s-v1.23.md
+3083
View File
File diff suppressed because one or more lines are too long
i18n/zh/docusaurus-plugin-content-docs/current/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.23-k8s-v1.24.md
+3084
View File
File diff suppressed because one or more lines are too long
i18n/zh/docusaurus-plugin-content-docs/current/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.23-k8s-v1.25.md
+3085
View File
File diff suppressed because one or more lines are too long
i18n/zh/docusaurus-plugin-content-docs/current/reference-guides/rancher-security/hardening-guides/rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.23-k8s-v1.23.md
+3196
View File
File diff suppressed because one or more lines are too long
i18n/zh/docusaurus-plugin-content-docs/current/reference-guides/rancher-security/hardening-guides/rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.23-k8s-v1.24.md
+3196
View File
File diff suppressed because one or more lines are too long
i18n/zh/docusaurus-plugin-content-docs/current/reference-guides/rancher-security/hardening-guides/rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.23-k8s-v1.25.md
+3196
View File
File diff suppressed because one or more lines are too long
i18n/zh/docusaurus-plugin-content-docs/current/reference-guides/rancher-security/psa-restricted-exemptions.md
+62
View File
@@ -0,0 +1,62 @@
---
title: PodSecurityConfiguration 示例
---
以下 PodSecurityConfiguration 包含了 `rancher-restricted` 集群正常运行所需的 Rancher 命名空间豁免。
```yaml
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: PodSecurity
configuration:
apiVersion: pod-security.admission.config.k8s.io/v1
kind: PodSecurityConfiguration
defaults:
enforce: "restricted"
enforce-version: "latest"
audit: "restricted"
audit-version: "latest"
warn: "restricted"
warn-version: "latest"
exemptions:
usernames: []
runtimeClasses: []
namespaces: [calico-apiserver,
calico-system,
cattle-alerting,
cattle-csp-adapter-system,
cattle-elemental-system,
cattle-epinio-system,
cattle-externalip-system,
cattle-fleet-local-system,
cattle-fleet-system,
cattle-gatekeeper-system,
cattle-global-data,
cattle-global-nt,
cattle-impersonation-system,
cattle-istio,
cattle-istio-system,
cattle-logging,
cattle-logging-system,
cattle-monitoring-system,
cattle-neuvector-system,
cattle-prometheus,
cattle-resources-system,
cattle-sriov-system,
cattle-system,
cattle-ui-plugin-system,
cattle-windows-gmsa-system,
cert-manager,
cis-operator-system,
fleet-default,
ingress-nginx,
istio-system,
kube-node-lease,
kube-public,
kube-system,
longhorn-system,
rancher-alerting-drivers,
security-scan,
tigera-operator]
```
i18n/zh/docusaurus-plugin-content-docs/current/reference-guides/rancher-security/rancher-v2.6-hardening-guides/rke1-hardening-guide-with-cis-v1.6-benchmark.md
-644
View File
@@ -1,644 +0,0 @@
---
title: 使用 CIS 1.6 Benchmark 的 RKE 强化指南
---
本文档提供了用于强化 RKE 集群（使用 Rancher 2.6 进行配置）生产安装的说明。此处概述了遵循 CIS 的 Kubernetes Benchmark 管控所需的配置和控制。
:::note
本强化指南介绍了如何保护集群中的节点。建议你在安装 Kubernetes 之前参考本指南。
:::
本强化指南适用于 RKE 集群，并对应以下 CIS Kubernetes Benchmark、Kubernetes 和 Rancher 版本：
| Rancher 版本 | CIS Benchmark 版本 | Kubernetes 版本 |
| --------------- | --------------------- | ------------------ |
| Rancher v2.6 | Benchmark v1.6 | Kubernetes v1.18 到 v1.23 |
[点击此处下载本文档的 PDF 版本](https://releases.rancher.com/documents/security/2.6/Rancher_v2-6_CIS_v1-6_Hardening_Guide.pdf)。
### 概述
本文档介绍了强化 RKE 集群的说明，该集群使用 Kubernetes 1.18 至 1.23 版本安装 Rancher 2.6，或在 Rancher 2.6 中配置使用 Kubernetes 1.18 至 1.23 版本的 RKE 集群。此处概述了遵循 CIS 的 Kubernetes Benchmark 管控所需的配置。
有关根据官方 CIS Benchmark 评估强化集群的更多详细信息，请参阅 [CIS 1.6 Benchmark - 自我评估指南 - Rancher 2.6](./rke1-self-assessment-guide-with-cis-v1.6-benchmark.md)。
#### 已知问题
- 如果注册自定义节点时仅提供公共 IP，CIS 1.6 强化设置中用于 Pod 的 Rancher **exec shell** 和 **view logs** 将**不起作用**。此功能要求在注册自定义节点时提供私有 IP。
- 如果把 `default_pod_security_policy_template_id:` 设置为 `restricted` 或 `restricted-noroot`，根据 Rancher 提供的 [Pod 安全策略 (PSP)](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md)，Rancher 会在默认 ServiceAccount 上创建 **RoleBindings** 和 **ClusterRoleBindings**。CIS 1.6 检查 5.1.5 时会要求默认 ServiceAccount 除了默认值之外没有绑定到其他角色或集群角色。此外，你还需要配置默认 ServiceAccount，使其不提供 ServiceAccount 令牌并且没有显式分配任何权限。
### 配置内核运行时参数
建议为集群中所有类型的节点使用以下 `sysctl` 配置。在 `/etc/sysctl.d/90-kubelet.conf` 中设置如下参数：
```ini
vm.overcommit_memory=1
vm.panic_on_oom=0
kernel.panic=10
kernel.panic_on_oops=1
kernel.keys.root_maxbytes=25000000
```
运行 `sysctl -p /etc/sysctl.d/90-kubelet.conf` 以启用设置。
### 配置 `etcd` 用户和组
在安装 RKE 之前，你需要设置 **etcd** 服务的用户账号和组。在安装期间，**etcd** 用户的 **uid** 和 **gid** 将用于在 RKE **config.yml** 中设置适当的文件和目录权限。
#### 创建 `etcd` 用户和组
要创建 **etcd** 用户和组，请运行以下控制台命令。下面的命令使用 `52034` 作为 **uid** 和 **gid**。该值只是一个示例。你可以使用有效且未被使用的 **uid** 或 **gid** 来代替 `52034`。
```bash
groupadd --gid 52034 etcd
useradd --comment "etcd service account" --uid 52034 --gid 52034 etcd --shell /usr/sbin/nologin
```
使用 **etcd** 用户的 **uid** 和 **gid** 来更新 RKE **config.yml**：
```yaml
services:
etcd:
gid: 52034
uid: 52034
```
### 配置 `default` ServiceAccount
#### 将 `default` ServiceAccount 的 `automountServiceAccountToken` 设置为 `false`
Kubernetes 为集群工作负载提供了一个 default ServiceAccount，但没有为 pod 分配特定 ServiceAccount。如果需要从 pod 访问 Kubernetes API，则需要为该 pod 创建一个特定的 ServiceAccount 并授予权限。你还需要配置 default ServiceAccount，使其不提供 ServiceAccount 令牌并且没有任何显式的权限分配。
对于标准 RKE 中的每个命名空间（包括 **default** 和 **kube-system**），**default** ServiceAccount 必须包含以下值：
```yaml
automountServiceAccountToken: false
```
将以下配置保存到名为 `account_update.yaml` 的文件中:
```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: default
automountServiceAccountToken: false
```
创建一个名为 `account_update.sh` 的 bash 脚本文件。确保为脚本设置了 `chmod +x account_update.sh`，使脚本具有执行权限：
```bash
#!/bin/bash -e
for namespace in $(kubectl get namespaces -A -o=jsonpath="{.items[*]['metadata.name']}"); do
kubectl patch serviceaccount default -n ${namespace} -p "$(cat account_update.yaml)"
done
```
### 配置网络策略
#### 确保所有命名空间都定义了网络策略
如果你在同一个 Kubernetes 集群上运行不同的应用程序，被感染的应用程序可能会攻击相邻的应用程序。要确保容器只进行所需的通信，网络分段非常重要。网络策略指的是如何允许 Pod 与其他 Pod 以及与其他网络端点进行通信。
网络策略是命名空间范围的。为某个命名空间配置网络策略后，该策略不允许的所有其他流量都会被拒绝。但是，如果命名空间没有配置网络策略，则所有流量都会允许进出该命名空间中的 Pod。要执行网络策略，你必须启用 CNI（容器网络接口）插件。本指南使用 [Canal](https://github.com/projectcalico/canal) 来执行策略。有关 CNI 网络插件的更多信息，请参阅[这里](https://www.suse.com/c/rancher_blog/comparing-kubernetes-cni-providers-flannel-calico-canal-and-weave/)。
在集群上启用了 CNI 网络插件后，你就可以应用默认网络策略了。以下提供了一个供参考的 **permissive** 示例。如果要允许所有流量发送到命名空间中的所有 pod（即使添加了导致某些 pod 被“隔离”的策略），你可以显式创建一个策略来允许该命名空间中的所有流量。将以下配置保存为 `default-allow-all.yaml`。如需查看网络策略相关的其他[文档](https://kubernetes.io/docs/concepts/services-networking/network-policies/)，请前往 Kubernetes 网站。
:::note
此 `NetworkPolicy` 只是一个示例，不建议用于生产环境。
:::
```yaml
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-allow-all
spec:
podSelector: {}
ingress:
- {}
egress:
- {}
policyTypes:
- Ingress
- Egress
```
创建一个名为 `apply_networkPolicy_to_all_ns.sh` 的 bash 脚本文件。确保为脚本设置了 `chmod +x apply_networkPolicy_to_all_ns.sh`，使脚本具有执行权限：
```bash
#!/bin/bash -e
for namespace in $(kubectl get namespaces -A -o=jsonpath="{.items[*]['metadata.name']}"); do
kubectl apply -f default-allow-all.yaml -n ${namespace}
done
```
执行此脚本能将具有 **permissive** `NetworkPolicy` 的 `default-allow-all.yaml` 配置应用于所有命名空间。
### 强化 RKE `cluster.yml` 配置参考
RKE CLI 能使用 `cluster.yml` 配置参考，该文件提供了实现 Rancher Kubernetes Engine (RKE) 的强化安装所需的配置。RKE 的[安装文档](https://rancher.com/docs/rke/latest/en/installation/)介绍了有关配置项的其他详细信息。此 `cluster.yml` 参考不包括所需的 **nodes** 参数，该参数会因你的环境而异。如需查看 RKE 中节点配置的文档，请参阅[此处](https://rancher.com/docs/rke/latest/en/config-options/nodes/)。
:::note 重要提示：
对于 Kubernetes 1.18 集群，请从 `PodSecurityPolicy` 中删除 `spec.volumes: 'ephemeral'` 配置，因为此 Kubernetes 版本不支持它。
:::
```yaml
# 如果你打算在离线环境中部署 Kubernetes，
# 请查阅配置自定义 RKE 镜像的文档。
# https://rancher.com/docs/rke/latest/en/installation/
# nodes 参数是必需的，并且会根据你的环境而有所不同。
# 节点配置的文档可以在这里找到：
# https://rancher.com/docs/rke/latest/en/config-options/nodes/
nodes: []
services:
etcd:
image: ""
extra_args: {}
extra_binds: []
extra_env: []
win_extra_args: {}
win_extra_binds: []
win_extra_env: []
external_urls: []
ca_cert: ""
cert: ""
key: ""
path: ""
uid: 52034
gid: 52034
snapshot: false
retention: ""
creation: ""
backup_config: null
kube-api:
image: ""
extra_args: {}
extra_binds: []
extra_env: []
win_extra_args: {}
win_extra_binds: []
win_extra_env: []
service_cluster_ip_range: ""
service_node_port_range: ""
pod_security_policy: true
always_pull_images: false
secrets_encryption_config:
enabled: true
custom_config: null
audit_log:
enabled: true
configuration: null
admission_configuration: null
event_rate_limit:
enabled: true
configuration: null
kube-controller:
image: ""
extra_args:
feature-gates: RotateKubeletServerCertificate=true
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
bind-address: 127.0.0.1
extra_binds: []
extra_env: []
win_extra_args: {}
win_extra_binds: []
win_extra_env: []
cluster_cidr: ""
service_cluster_ip_range: ""
scheduler:
image: ""
extra_args:
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
bind-address: 127.0.0.1
extra_binds: []
extra_env: []
win_extra_args: {}
win_extra_binds: []
win_extra_env: []
kubelet:
image: ""
extra_args:
feature-gates: RotateKubeletServerCertificate=true
protect-kernel-defaults: true
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
extra_binds: []
extra_env: []
win_extra_args: {}
win_extra_binds: []
win_extra_env: []
cluster_domain: cluster.local
infra_container_image: ""
cluster_dns_server: ""
fail_swap_on: false
generate_serving_certificate: true
kubeproxy:
image: ""
extra_args: {}
extra_binds: []
extra_env: []
win_extra_args: {}
win_extra_binds: []
win_extra_env: []
network:
plugin: ""
options: {}
mtu: 0
node_selector: {}
update_strategy: null
authentication:
strategy: ""
sans: []
webhook: null
addons: |
# Upstream Kubernetes restricted PSP policy
# https://github.com/kubernetes/website/blob/564baf15c102412522e9c8fc6ef2b5ff5b6e766c/content/en/examples/policy/restricted-psp.yaml
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: restricted-noroot
spec:
privileged: false
# Required to prevent escalations to root.
allowPrivilegeEscalation: false
requiredDropCapabilities:
- ALL
# Allow core volume types.
volumes:
- 'configMap'
- 'emptyDir'
- 'projected'
- 'secret'
- 'downwardAPI'
# Assume that ephemeral CSI drivers & persistentVolumes set up by the cluster admin are safe to use.
- 'csi'
- 'persistentVolumeClaim'
- 'ephemeral'
hostNetwork: false
hostIPC: false
hostPID: false
runAsUser:
# Require the container to run without root privileges.
rule: 'MustRunAsNonRoot'
seLinux:
# This policy assumes the nodes are using AppArmor rather than SELinux.
rule: 'RunAsAny'
supplementalGroups:
rule: 'MustRunAs'
ranges:
# Forbid adding the root group.
- min: 1
max: 65535
fsGroup:
rule: 'MustRunAs'
ranges:
# Forbid adding the root group.
- min: 1
max: 65535
readOnlyRootFilesystem: false
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: psp:restricted-noroot
rules:
- apiGroups:
- extensions
resourceNames:
- restricted-noroot
resources:
- podsecuritypolicies
verbs:
- use
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: psp:restricted-noroot
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: psp:restricted-noroot
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: system:serviceaccounts
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: system:authenticated
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-allow-all
spec:
podSelector: {}
ingress:
- {}
egress:
- {}
policyTypes:
- Ingress
- Egress
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: default
automountServiceAccountToken: false
addons_include: []
system_images:
etcd: ""
alpine: ""
nginx_proxy: ""
cert_downloader: ""
kubernetes_services_sidecar: ""
kubedns: ""
dnsmasq: ""
kubedns_sidecar: ""
kubedns_autoscaler: ""
coredns: ""
coredns_autoscaler: ""
nodelocal: ""
kubernetes: ""
flannel: ""
flannel_cni: ""
calico_node: ""
calico_cni: ""
calico_controllers: ""
calico_ctl: ""
calico_flexvol: ""
canal_node: ""
canal_cni: ""
canal_controllers: ""
canal_flannel: ""
canal_flexvol: ""
weave_node: ""
weave_cni: ""
pod_infra_container: ""
ingress: ""
ingress_backend: ""
metrics_server: ""
windows_pod_infra_container: ""
ssh_key_path: ""
ssh_cert_path: ""
ssh_agent_auth: false
authorization:
mode: ""
options: {}
ignore_docker_version: false
kubernetes_version: ""
private_registries: []
ingress:
provider: ""
options: {}
node_selector: {}
extra_args: {}
dns_policy: ""
extra_envs: []
extra_volumes: []
extra_volume_mounts: []
update_strategy: null
http_port: 0
https_port: 0
network_mode: ""
cluster_name:
cloud_provider:
name: ""
prefix_path: ""
win_prefix_path: ""
addon_job_timeout: 0
bastion_host:
address: ""
port: ""
user: ""
ssh_key: ""
ssh_key_path: ""
ssh_cert: ""
ssh_cert_path: ""
monitoring:
provider: ""
options: {}
node_selector: {}
update_strategy: null
replicas: null
restore:
restore: false
snapshot_name: ""
dns: null
upgrade_strategy:
max_unavailable_worker: ""
max_unavailable_controlplane: ""
drain: null
node_drain_input: null
```
### 强化 RKE 模板配置参考
RKE 模板参考提供了实现 Kubernetes 强化安装所需的配置。RKE 模板用于配置 Kubernetes 和定义 Rancher 设置。如需了解安装以及 RKE 模板的详细信息，请参阅 Rancher [文档](../../../pages-for-subheaders/installation-and-upgrade.md)。
```yaml
#
# Cluster Config
#
default_pod_security_policy_template_id: restricted-noroot
docker_root_dir: /var/lib/docker
enable_cluster_alerting: false
enable_cluster_monitoring: false
enable_network_policy: true
local_cluster_auth_endpoint:
enabled: true
name: ''
#
# Rancher Config
#
rancher_kubernetes_engine_config:
addon_job_timeout: 45
authentication:
strategy: x509
dns:
nodelocal:
ip_address: ''
node_selector: null
update_strategy: {}
enable_cri_dockerd: false
ignore_docker_version: true
#
# # 目前仅支持 Nginx ingress provider
# # 要禁用 Ingress controller，设置 `provider: none`
# # 要在指定节点上禁用 Ingress，使用 node_selector，例如：
# provider: nginx
# node_selector:
# app: ingress
#
ingress:
default_backend: false
default_ingress_class: true
http_port: 0
https_port: 0
provider: nginx
kubernetes_version: v1.21.8-rancher1-1
monitoring:
provider: metrics-server
replicas: 1
#
# 如果你在 AWS 使用 Calico
#
# network:
# plugin: calico
# calico_network_provider:
# cloud_provider: aws
#
# # 要指定 Flannel 接口
#
# network:
# plugin: flannel
# flannel_network_provider:
# iface: eth1
#
# # 要为 Canal 插件指定 Flannel 接口
#
# network:
# plugin: canal
# canal_network_provider:
# iface: eth1
#
network:
mtu: 0
options:
flannel_backend_type: vxlan
plugin: canal
rotate_encryption_key: false
#
# services:
# kube-api:
# service_cluster_ip_range: 10.43.0.0/16
# kube-controller:
# cluster_cidr: 10.42.0.0/16
# service_cluster_ip_range: 10.43.0.0/16
# kubelet:
# cluster_domain: cluster.local
# cluster_dns_server: 10.43.0.10
#
services:
scheduler:
extra_args:
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
bind-address: 127.0.0.1
etcd:
backup_config:
enabled: true
interval_hours: 12
retention: 6
safe_timestamp: false
timeout: 300
creation: 12h
extra_args:
election-timeout: 5000
heartbeat-interval: 500
retention: 72h
snapshot: false
uid: 52034
gid: 52034
kube_api:
always_pull_images: false
audit_log:
enabled: true
event_rate_limit:
enabled: true
pod_security_policy: true
secrets_encryption_config:
enabled: true
service_node_port_range: 30000-32767
kube-controller:
extra_args:
feature-gates: RotateKubeletServerCertificate=true
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
bind-address: 127.0.0.1
kubelet:
extra_args:
feature-gates: RotateKubeletServerCertificate=true
protect-kernel-defaults: true
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
fail_swap_on: false
generate_serving_certificate: true
ssh_agent_auth: false
upgrade_strategy:
max_unavailable_controlplane: '1'
max_unavailable_worker: 10%
windows_prefered_cluster: false
```
### 强化 `cloud-config` 配置参考
**cloud-config** 配置文件通常用于云基础设施环境中，能让你管理计算实例的配置。此参考 config 配置了安装 Kubernetes 之前所需的 SUSE Linux Enterprise Server (SLES)、openSUSE Leap、Red Hat Enterprise Linux (RHEL) 和 Ubuntu 操作系统级别的设置。
#### 针对 SUSE Linux Enterprise Server 15 (SLES 15) 和 openSUSE Leap 15 的强化 **cloud-config** 参考
```yaml
#cloud-config
system_info:
default_user:
groups:
- docker
write_files:
- path: "/etc/sysctl.d/90-kubelet.conf"
owner: root:root
permissions: '0644'
content: |
vm.overcommit_memory=1
vm.panic_on_oom=0
kernel.panic=10
kernel.panic_on_oops=1
kernel.keys.root_maxbytes=25000000
package_update: true
ssh_pwauth: false
runcmd:
# Docker 应该已在 SLES 15 SP3 中安装
- zypper install docker containerd
- systemctl daemon-reload
- systemctl enable docker.service
- systemctl start --no-block docker.service
- sysctl -p /etc/sysctl.d/90-kubelet.conf
- groupadd --gid 52034 etcd
- useradd --comment "etcd service account" --uid 52034 --gid 52034 etcd --shell /usr/sbin/nologin
```
#### 针对 Red Hat Enterprise Linux 8 (RHEL 8) 和 Ubuntu 20.04 LTS 的强化 **cloud-config** 参考
```yaml
#cloud-config
system_info:
default_user:
groups:
- docker
write_files:
- path: "/etc/sysctl.d/90-kubelet.conf"
owner: root:root
permissions: '0644'
content: |
vm.overcommit_memory=1
vm.panic_on_oom=0
kernel.panic=10
kernel.panic_on_oops=1
kernel.keys.root_maxbytes=25000000
package_update: true
ssh_pwauth: false
runcmd:
# 使用 Rancher 的 Docker 安装脚本来安装 Docker - github.com/rancher/install-docker
- curl https://releases.rancher.com/install-docker/20.10.sh | sh
- sysctl -p /etc/sysctl.d/90-kubelet.conf
- groupadd --gid 52034 etcd
- useradd --comment "etcd service account" --uid 52034 --gid 52034 etcd --shell /usr/sbin/nologin
```
i18n/zh/docusaurus-plugin-content-docs/current/reference-guides/rancher-security/rancher-v2.6-hardening-guides/rke1-self-assessment-guide-with-cis-v1.6-benchmark.md
-2953
View File
File diff suppressed because it is too large Load Diff
i18n/zh/docusaurus-plugin-content-docs/current/reference-guides/rancher-security/rancher-v2.6-hardening-guides/rke2-hardening-guide-with-cis-v1.6-benchmark.md
-409
View File
@@ -1,409 +0,0 @@
---
title: 使用 CIS 1.6 Benchmark 的 RKE2 强化指南
---
本文档提供了用于强化 RKE2 集群（使用 Rancher 2.6.5 进行配置）生产安装的说明。此处概述了遵循 CIS 的 Kubernetes Benchmark 管控所需的配置和控制。
:::note
本强化指南介绍了如何保护集群中的节点。建议你在安装 Kubernetes 之前参考本指南。
:::
本强化指南适用于 RKE2 集群，并对应以下 CIS Kubernetes Benchmark、Kubernetes 和 Rancher 版本：
| Rancher 版本 | CIS Benchmark 版本 | Kubernetes 版本 |
| --------------- | --------------------- | ------------------ |
| Rancher v2.6.5+ | Benchmark v1.6 | Kubernetes v1.21 到 v1.23 |
[点击此处下载本文档的 PDF 版本](https://releases.rancher.com/documents/security/2.6/Rancher_RKE2_v2-6_CIS_v1-6_Hardening_Guide.pdf)。
### 概述
本文档提供了强化使用了 Rancher 2.6.5+ 和 Kubernetes 1.21 到 1.23 版本的 RKE2 集群的说明。此处概述了遵循 CIS 的 Kubernetes Benchmark 管控所需的配置。
有关根据官方 CIS Benchmark 评估强化 RKE2 集群的更多详细信息，请参阅 [RKE2 - CIS 1.6 Benchmark - 自我评估指南 - Rancher 2.6](rke2-self-assessment-guide-with-cis-v1.6-benchmark.md)。
RKE2 是“默认强化”的，因此无需进行修改即可通过大部分 Kubernetes CIS 管控。但是也有一些例外情况是需要人工干预才能完全通过 CIS Benchmark：
1. RKE2 不会修改主机操作系统。因此，操作人员必须进行一些主机级别的修改。
2. `PodSecurityPolicies` 和 `NetworkPolicies` 的某些 CIS 策略会限制集群功能。你必须让 RKE2 开箱即用地配置它们。
要满足上述要求，你可以在 `profile` 标志设置为 `cis-1.6` 的情况下启动 RKE2。该标志通常执行以下两个操作：
1. 检查是否满足主机级别的要求。如果没有，RKE2 将退出并显示未满足要求的致命错误描述。
2. 配置能让集群通过相关管控的运行时 pod 安全策略和网络策略。
:::note
配置文件标志的有效值是 `cis-1.5` 或 `cis-1.6`。它接受一个字符串值以允许以后使用其他配置文件。
:::
以下概述了当 `profile` 标志设置为 `cis-1.6` 时采取的具体操作。
### 主机级别要求
主机级别的要求有两个方面，分别是内核参数和 etcd 进程/目录配置。本节会概述这些内容。
#### 确保设置了 `protect-kernel-defaults`
这是一个 kubelet 标志，如果所需的内核参数未设置或设置为与 kubelet 默认值不同的值，它会导致 kubelet 退出。
如果设置了 `profile` 标志，RKE2 会将标志设置为 `true`。
:::caution
`protect-kernel-defaults` 作为 RKE2 的配置标志公开。如果你已将 `profile` 设置为 `cis-1.x` 并将 `protect-kernel-defaults` 设置为 `false`，则 RKE2 将退出并提示错误。
:::
RKE2 还将检查与 kubelet 相同的内核参数，并按照 kubelet 相同的规则退出并提示错误。这样，操作人员可以更快、更轻松地识别出与 kubelet 默认值不一致的内核参数。
`protect-kernel-defaults` 和 `profile` 标志都可以在 RKE2 模板配置文件中设置。
```yaml
spec:
rkeConfig:
machineSelectorConfig:
- config:
profile: cis-1.6
protect-kernel-defaults: true
```
#### 确保 etcd 配置正确
CIS Benchmark 要求 etcd 数据目录由 `etcd` 用户和组拥有。换言之，它要求 etcd 进程由主机级别的 `etcd` 用户运行。为了实现这一点，RKE2 在使用有效的 `cis-1.x` 配置文件启动时采取了几个步骤：
1. 检查主机上是否存在 `etcd` 用户和组。如果没有，则退出并提示错误。
2. 以 `etcd` 作为用户和组所有者来创建 etcd 的数据目录。
3. 正确设置 etcd 静态 pod 的 `SecurityContext`，从而确保 etcd 进程以 `etcd` 用户和组的身份运行。
### 设置主机
本节提供了满足上述要求所需的主机配置命令。
#### 设置内核参数
建议为集群中所有类型的节点使用以下 `sysctl` 配置。在 `/etc/sysctl.d/90-kubelet.conf` 中设置如下参数：
```ini
vm.panic_on_oom=0
vm.overcommit_memory=1
kernel.panic=10
kernel.panic_on_oops=1
```
运行 `sudo sysctl -p /etc/sysctl.d/90-kubelet.conf` 以启用设置。
在通过 Rancher 实际部署 RKE2 之前，请仅在全新安装上执行此步骤。
#### 创建 etcd 用户
在某些 Linux 发行版上，`useradd` 命令不会创建组。以下命令使用了 `-U` 标志来解决这一问题。这个标志能让 `useradd` 创建一个与用户同名的组。
```bash
sudo useradd -r -c "etcd user" -s /sbin/nologin -M etcd -U
```
### Kubernetes 运行时要求
如果运行时要通过 CIS Benchmark，则需要重视 pod 安全和网络策略。本节会概述这些内容。
#### `PodSecurityPolicies`
RKE2 总是在 `PodSecurityPolicy` 准入控制器打开的情况下运行。但是，当它**不是**使用有效的 `cis-1.x` 配置文件启动时，RKE2 将设置一个不受限制的策略，该策略允许 Kubernetes 像 `PodSecurityPolicy` 准入控制器未启用一样运行。
使用有效的 `cis-1.x` 配置文件运行时，RKE2 将设置一组更具限制性的策略。这些策略符合 CIS Benchmark 5.2 节中的要求。
> Kubernetes controlplane 组件和关键附加组件（例如 CNI、DNS 和 Ingress）在 `kube-system` 命名空间中作为 pod 运行。因此，此命名空间的策略限制会更低，以便这些组件可以正常运行。
#### `NetworkPolicies`
使用有效的 `cis-1.x` 配置文件运行时，RKE2 将设置 `NetworkPolicies` 以通过 Kubernetes 内置命名空间的 CIS Benchmark。这些命名空间是分别是 `kube-system`、`kube-public`、`kube-node-lease` 和 `default`。
使用的 `NetworkPolicy` 只允许同一命名空间内的 Pod 相互通信。一个例外情况是它允许解析 DNS 请求。
:::note
操作人员需要照常管理其他命名空间的网络策略。
:::
#### 配置 `default` ServiceAccount
**将 `default` ServiceAccount 的 `automountServiceAccountToken` 设置为 `false`**
Kubernetes 为集群工作负载提供了一个 `default` ServiceAccount，但没有为 pod 分配特定 ServiceAccount 。如果需要从 pod 访问 Kubernetes API，则需要为该 pod 创建一个特定的 ServiceAccount 并授予权限。你还需要配置 `default` ServiceAccount，使其不提供 ServiceAccount 令牌并且没有任何显式的权限分配。
对于标准 RKE2 中的每个命名空间（包括 `default` 和 `kube-system`），`default` ServiceAccount 必须包含以下值：
```yaml
automountServiceAccountToken: false
```
对于集群操作人员创建的命名空间，你可以使用以下脚本和配置文件来配置 `default` ServiceAccount。
请将下面的配置保存到名为 `account_update.yaml` 的文件中：
```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: default
automountServiceAccountToken: false
```
创建一个名为 `account_update.sh` 的 bash 脚本文件。确保为脚本设置了 `sudo chmod +x account_update.sh`，使脚本具有执行权限：
```bash
#!/bin/bash -e
for namespace in $(kubectl get namespaces -A -o=jsonpath="{.items[*]['metadata.name']}"); do
echo -n "Patching namespace $namespace - "
kubectl patch serviceaccount default -n ${namespace} -p "$(cat account_update.yaml)"
done
```
执行此脚本，将 `account_update.yaml` 配置应用到所有命名空间中的 `default` ServiceAccount。
### API Server 审计配置
CIS 1.2.22 到 1.2.25 要求为 API Server 配置审计日志。如果 RKE2 在 `profile` 标志设置为 `cis-1.6` 的情况下启动，它会自动在 API Server 中配置强化的 `--audit-log-` 参数来通过这些 CIS 检查。
RKE2 的默认审计策略不会在 API Server 中记录请求。这样，集群操作人员就能灵活地定制符合其审计要求和需求的审计策略，从而满足不同用户的不同环境和策略需求。
如果启动时 `profile` 标志设置为 `cis-1.6`，RKE2 会创建默认审计策略。该策略在 `/etc/rancher/rke2/audit-policy.yaml` 中定义。
```yaml
apiVersion: audit.k8s.io/v1
kind: Policy
metadata:
creationTimestamp: null
rules:
- level: None
```
要开始记录对 API Server 的请求，你至少必须修改 `level` 参数，例如将其修改为 `Metadata`。有关 API Server 策略配置的详细信息，请参阅 [Kubernetes 文档](https://kubernetes.io/docs/tasks/debug-application-cluster/audit/)。
调整审计策略后，RKE2 必须重新启动才能加载新配置。
```shell
sudo systemctl restart rke2-server.service
```
API Server 审计日志将写入 `/var/lib/rancher/rke2/server/logs/audit.log`。
### 已知问题
以下是 RKE2 目前没有通过的管控。此处将解释各个差距，以及这些差距是否可以通过手动干预或在未来的版本中解决。
#### 管控 1.1.12
确保 etcd 数据目录所有权设置为 `etcd:etcd`
**原因**
etcd 是 Kubernetes deployment 使用的高可用键值存储，用于持久存储其所有 REST API 对象。你需要保护此数据目录，避免任何未经授权的读取或写入。它的所有者应该是 `etcd:etcd`。
**修正措施**
创建如上所述的 `etcd` 用户和组。
#### 管控 5.1.5
确保未主动使用默认 ServiceAccount
**原因**：Kubernetes 为集群工作负载提供了一个 `default` ServiceAccount，但没有为 pod 分配特定 ServiceAccount 。
如果需要从 pod 访问 Kubernetes API，则需要为该 pod 创建一个特定的 ServiceAccount 并授予权限。
你还需要配置 `default` ServiceAccount，使其不提供 ServiceAccount 令牌并且没有任何显式的权限分配。
可以通过将每个命名空间中 `default` ServiceAccount 的 `automountServiceAccountToken` 字段更新为 `false` 来解决此问题。
**修正措施**
手动更新集群中服务账户上的此字段。
#### 管控 5.3.2
确保所有命名空间都定义了网络策略
**原因**
如果你在同一个 Kubernetes 集群上运行不同的应用程序，被感染的应用程序可能会攻击相邻的应用程序。要确保容器只进行所需的通信，网络分段非常重要。网络策略指的是如何允许 Pod 与其他 Pod 以及与其他网络端点进行通信。
网络策略是命名空间范围的。为某个命名空间配置网络策略后，该策略不允许的所有其他流量都会被拒绝。但是，如果命名空间没有配置网络策略，则所有流量都会允许进出该命名空间中的 Pod。
**修正措施**
在 RKE2 模板配置文件中设置 `profile: "cis-1.6"`。你可以在下方找到示例。
### 强化 RKE2 模板配置参考
模板配置参考可用于在 Rancher 中创建强化的 RKE2 自定义集群。此参考不包括其他必需的**集群配置**参数，该参数会因你的环境而异。
```yaml
apiVersion: provisioning.cattle.io/v1
kind: Cluster
metadata:
name: <replace_with_cluster_name>
annotations:
{}
# key: string
labels:
{}
# key: string
namespace: fleet-default
spec:
defaultPodSecurityPolicyTemplateName: ''
kubernetesVersion: <replace_with_kubernetes_version>
localClusterAuthEndpoint:
caCerts: ''
enabled: false
fqdn: ''
rkeConfig:
chartValues:
rke2-canal:
{}
etcd:
disableSnapshots: false
s3:
# bucket: string
# cloudCredentialName: string
# endpoint: string
# endpointCA: string
# folder: string
# region: string
# skipSSLVerify: boolean
snapshotRetention: 5
snapshotScheduleCron: 0 */5 * * *
machineGlobalConfig:
cni: canal
machinePools:
# - cloudCredentialSecretName: string
# controlPlaneRole: boolean
# displayName: string
# drainBeforeDelete: boolean
# etcdRole: boolean
# labels:
# key: string
# machineConfigRef:
# apiVersion: string
# fieldPath: string
# kind: string
# name: string
# namespace: string
# resourceVersion: string
# uid: string
# machineDeploymentAnnotations:
# key: string
# machineDeploymentLabels:
# key: string
# machineOS: string
# maxUnhealthy: string
# name: string
# nodeStartupTimeout: string
# paused: boolean
# quantity: int
# rollingUpdate:
# maxSurge: string
# maxUnavailable: string
# taints:
# - effect: string
# key: string
# timeAdded: string
# value: string
# unhealthyNodeTimeout: string
# unhealthyRange: string
# workerRole: boolean
machineSelectorConfig:
- config:
profile: cis-1.6
protect-kernel-defaults: true
# - config:
#
# machineLabelSelector:
# matchExpressions:
# - key: string
# operator: string
# values:
# - string
# matchLabels:
# key: string
registries:
configs:
{}
#authConfigSecretName: string
# caBundle: string
# insecureSkipVerify: boolean
# tlsSecretName: string
mirrors:
{}
#endpoint:
# - string
# rewrite:
# key: string
upgradeStrategy:
controlPlaneConcurrency: 10%
controlPlaneDrainOptions:
# deleteEmptyDirData: boolean
# disableEviction: boolean
# enabled: boolean
# force: boolean
# gracePeriod: int
# ignoreDaemonSets: boolean
# ignoreErrors: boolean
# postDrainHooks:
# - annotation: string
# preDrainHooks:
# - annotation: string
# skipWaitForDeleteTimeoutSeconds: int
# timeout: int
workerConcurrency: 10%
workerDrainOptions:
# deleteEmptyDirData: boolean
# disableEviction: boolean
# enabled: boolean
# force: boolean
# gracePeriod: int
# ignoreDaemonSets: boolean
# ignoreErrors: boolean
# postDrainHooks:
# - annotation: string
# preDrainHooks:
# - annotation: string
# skipWaitForDeleteTimeoutSeconds: int
# timeout: int
# additionalManifest: string
# etcdSnapshotCreate:
# generation: int
# etcdSnapshotRestore:
# generation: int
# name: string
# restoreRKEConfig: string
# infrastructureRef:
# apiVersion: string
# fieldPath: string
# kind: string
# name: string
# namespace: string
# resourceVersion: string
# uid: string
# provisionGeneration: int
# rotateCertificates:
# generation: int
# services:
# - string
# rotateEncryptionKeys:
# generation: int
machineSelectorConfig:
- config: {}
# agentEnvVars:
# - name: string
# value: string
# cloudCredentialSecretName: string
# clusterAPIConfig:
# clusterName: string
# defaultClusterRoleForProjectMembers: string
# enableNetworkPolicy: boolean
# redeploySystemAgentGeneration: int
__clone: true
```
### 结论
如果你遵循本指南，Rancher 配置的 RKE2 自定义集群将能通过 CIS Kubernetes Benchmark。如需了解我们验证 Benchmark 的方式，以及你如何在集群上执行相同的操作，请参阅 Rancher 的 [RKE2 CIS Benchmark 自我评估指南 1.6](rke2-self-assessment-guide-with-cis-v1.6-benchmark.md)。
i18n/zh/docusaurus-plugin-content-docs/current/reference-guides/rancher-security/rancher-v2.6-hardening-guides/rke2-self-assessment-guide-with-cis-v1.6-benchmark.md
-3164
View File
File diff suppressed because it is too large Load Diff
i18n/zh/docusaurus-plugin-content-docs/current/reference-guides/rancher-security/rancher-v2.7-hardening-guides/k3s-hardening-guide-with-cis-benchmark.md
-549
View File
@@ -1,549 +0,0 @@
---
title: K3s Hardening Guide with CIS Benchmark
---
This document provides prescriptive guidance for hardening a production installation of a K3s cluster to be provisioned with Rancher v2.7. It outlines the configurations and controls required to address Kubernetes benchmark controls from the Center for Information Security (CIS).
:::note
This hardening guide describes how to secure the nodes in your cluster, and it is recommended to follow this guide before installing Kubernetes.
:::
This hardening guide is intended to be used for K3s clusters and associated with specific versions of the CIS Kubernetes Benchmark, Kubernetes, and Rancher:
| Rancher Version | CIS Benchmark Version | Kubernetes Version |
| --------------- | --------------------- | ------------------ |
| Rancher v2.7 | Benchmark v1.20 | Kubernetes v1.21 |
| Rancher v2.7 | Benchmark v1.23 | Kubernetes v1.22 up to v1.24 |
### Overview
For more details about evaluating a hardened K3s cluster against the official CIS benchmark, refer to K3s - CIS Benchmark - Self-Assessment Guide - Rancher v2.7 for [CIS v1.20](k3s-self-assessment-guide-with-cis-v1.20-benchmark.md) and [CIS v1.23](k3s-self-assessment-guide-with-cis-v1.23-benchmark.md).
K3s has a number of security mitigations applied and turned on by default and will pass a number of the Kubernetes CIS controls without modification. There are some notable exceptions to this that require manual intervention to fully comply with the CIS Benchmark:
1. K3s will not modify the host operating system. Any host-level modifications will need to be done manually.
2. Certain CIS policy controls for `PodSecurityPolicies` and `NetworkPolicies` will restrict the functionality of the cluster. You must opt into having K3s configure these by adding the appropriate options (enabling of admission plugins) to your command-line flags or configuration file as well as manually applying appropriate policies. Further details are presented in the sections below.
The first section (1.1) of the CIS Benchmark concerns itself primarily with pod manifest permissions and ownership. K3s doesn't utilize these for the core components since everything is packaged into a single binary.
## Host-level Requirements
### Ensure `protect-kernel-defaults` is set (control 4.2.6)
This is a kubelet flag that will cause the kubelet to exit if the required kernel parameters are unset or are set to values that are different from the kubelet's defaults.
This can be remediated by adding the following argument line to K3s cluster configuration file:
```yaml
spec:
rkeConfig:
machineSelectorConfig:
- config:
protect-kernel-defaults: true # Control 4.2.6
```
#### Set kernel parameters
Create a file called `/etc/sysctl.d/90-kubelet.conf` and add the snippet below. Then run `sysctl -p /etc/sysctl.d/90-kubelet.conf`.
```bash
vm.panic_on_oom=0
vm.overcommit_memory=1
kernel.panic=10
kernel.panic_on_oops=1
```
This configuration needs to be done before setting the kubelet flag, otherwise K3s will fail to start.
## Kubernetes Runtime Requirements
The runtime requirements to comply with the CIS Benchmark are centered around pod security policies (PSPs) and its admission control plugin, network policies and API Server auditing logs. These are outlined in this section. K3s doesn't apply any default PSPs or network policies. However, K3s ships with a controller that is meant to apply a given set of network policies. By default, K3s runs with the `NodeRestriction` admission controller. To enable PSPs, add the following line to K3s cluster configuration file:
```yaml
spec:
rkeConfig:
machineGlobalConfig:
kube-apiserver-arg:
- enable-admission-plugins=NodeRestriction,PodSecurityPolicy # CIS 1.2.16 and CIS 5.2
```
This will have the effect of maintaining the `NodeRestriction` plugin as well as enabling the `PodSecurityPolicy`.
### Pod Security Policies (control 5.2)
When PSPs are enabled, a policy can be applied to satisfy the necessary controls described in section 5.2 of the CIS Benchmark.
Here is an example of a compliant PSP.
```yaml
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: restricted-psp
spec:
privileged: false # CIS - 5.2.1
allowPrivilegeEscalation: false # CIS - 5.2.5
requiredDropCapabilities: # CIS - 5.2.7/8/9
- ALL
volumes:
- 'configMap'
- 'emptyDir'
- 'projected'
- 'secret'
- 'downwardAPI'
- 'csi'
- 'persistentVolumeClaim'
- 'ephemeral'
hostNetwork: false # CIS - 5.2.4
hostIPC: false # CIS - 5.2.3
hostPID: false # CIS - 5.2.2
runAsUser:
rule: 'MustRunAsNonRoot' # CIS - 5.2.6
seLinux:
rule: 'RunAsAny'
supplementalGroups:
rule: 'MustRunAs'
ranges:
- min: 1
max: 65535
fsGroup:
rule: 'MustRunAs'
ranges:
- min: 1
max: 65535
readOnlyRootFilesystem: false
```
For the above PSP to be effective, we need to create a `ClusterRole` and a `ClusterRoleBinding`. We also need to include a "system unrestricted policy" which is needed for system-level pods that require additional privileges, as exemplified below.
```yaml
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: restricted-psp
spec:
privileged: false
allowPrivilegeEscalation: false
requiredDropCapabilities:
- ALL
volumes:
- 'configMap'
- 'emptyDir'
- 'projected'
- 'secret'
- 'downwardAPI'
- 'csi'
- 'persistentVolumeClaim'
- 'ephemeral'
hostNetwork: false
hostIPC: false
hostPID: false
runAsUser:
rule: 'MustRunAsNonRoot'
seLinux:
rule: 'RunAsAny'
supplementalGroups:
rule: 'MustRunAs'
ranges:
- min: 1
max: 65535
fsGroup:
rule: 'MustRunAs'
ranges:
- min: 1
max: 65535
readOnlyRootFilesystem: false
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: psp:restricted-psp
labels:
addonmanager.kubernetes.io/mode: EnsureExists
rules:
- apiGroups: ['extensions']
resources: ['podsecuritypolicies']
verbs: ['use']
resourceNames:
- restricted-psp
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: default:restricted-psp
labels:
addonmanager.kubernetes.io/mode: EnsureExists
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: psp:restricted-psp
subjects:
- kind: Group
name: system:authenticated
apiGroup: rbac.authorization.k8s.io
---
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: system-unrestricted-psp
spec:
allowPrivilegeEscalation: true
allowedCapabilities:
- '*'
fsGroup:
rule: RunAsAny
hostIPC: true
hostNetwork: true
hostPID: true
hostPorts:
- max: 65535
min: 0
privileged: true
runAsUser:
rule: RunAsAny
seLinux:
rule: RunAsAny
supplementalGroups:
rule: RunAsAny
volumes:
- '*'
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: system-unrestricted-node-psp-rolebinding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: system-unrestricted-psp-role
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: system:nodes
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: system-unrestricted-psp-role
rules:
- apiGroups:
- policy
resourceNames:
- system-unrestricted-psp
resources:
- podsecuritypolicies
verbs:
- use
```
The policy file `policy.yaml` can be placed in the `/var/lib/rancher/k3s/server/manifests` directory. Both the policy file and the its directory hierarchy, ideally, must be created before starting K3s. A restrictive access permission is recommended to avoid leaking potential sensitive information.
```bash
sudo mkdir -p -m 700 /var/lib/rancher/k3s/server/manifests
```
### Network Policies (control 5.3.2)
CIS requires that all namespaces have a network policy applied that reasonably limits traffic into namespaces and pods.
:::note
This is a manual check in the CIS Benchmark. The CIS scan will flag the result as `warning`, because manual inspection is necessary by the cluster operator.
:::
Here is an example of a compliant network policy.
```yaml
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: intra-namespace
namespace: kube-system
spec:
podSelector: {}
ingress:
- from:
- namespaceSelector:
matchLabels:
name: kube-system
```
:::note
Kubernetes' additions such as CNI, DNS, and Ingress are ran as pods in the `kube-system` namespace. Therefore, this namespace will have a policy that is less restrictive so that these components can run properly.
:::
With the applied restrictions, DNS will be blocked unless purposely allowed. Below is a network policy that will allow DNS related traffic.
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-network-dns-policy
namespace: <NAMESPACE>
spec:
ingress:
- ports:
- port: 53
protocol: TCP
- port: 53
protocol: UDP
podSelector:
matchLabels:
k8s-app: kube-dns
policyTypes:
- Ingress
```
The metrics-server and Traefik ingress controller will be blocked by default if network policies are not created to allow access.
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-all-metrics-server
namespace: kube-system
spec:
podSelector:
matchLabels:
k8s-app: metrics-server
ingress:
- {}
policyTypes:
- Ingress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-all-svclbtraefik-ingress
namespace: kube-system
spec:
podSelector:
matchLabels:
svccontroller.k3s.cattle.io/svcname: traefik
ingress:
- {}
policyTypes:
- Ingress
```
:::note
Operators must manage network policies as normal for additional namespaces that are created.
:::
The network policies can be added in the same policy file used for PSPs in `/var/lib/rancher/k3s/server/manifests/policy.yaml` or on its own file.
### API Server audit configuration
CIS requirements v1.20 - 1.2.22 to 1.2.25 and v1.23 - 1.2.19 to 1.2.22 are related to configuring audit logs for the API Server. K3s doesn't create by default the log directory and audit policy, as auditing requirements are specific to each user's policies and environment.
The log directory, ideally, must be created before starting K3s. A restrictive access permission is recommended to avoid leaking potential sensitive information.
```bash
sudo mkdir -p -m 700 /var/lib/rancher/k3s/server/logs
```
A starter audit policy to log request metadata is provided below. The policy should be written to a file named `audit.yaml` in `/var/lib/rancher/k3s/server` directory. Detailed information about policy configuration for the API server can be found in the Kubernetes [documentation](https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/).
```yaml
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata
```
Further configurations, as described below, are also needed to pass CIS checks and are not configured by default in K3s, because they vary depending on the users' environment and needs:
- Ensure that the `--audit-log-path` argument is set.
- Ensure that the `--audit-log-maxage` argument is set to 30 or as appropriate.
- Ensure that the `--audit-log-maxbackup` argument is set to 10 or as appropriate.
- Ensure that the `--audit-log-maxsize` argument is set to 100 or as appropriate.
To enable and configure audit logs, add the following line to K3s cluster configuration file:
```yaml
spec:
rkeConfig:
machineGlobalConfig:
kube-apiserver-arg:
- audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml # CIS v1.20/v1.23 3.2.1
- audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log # CIS v1.20 1.2.21 and CIS v1.23 1.2.19
- audit-log-maxage=30 # CIS v1.20 1.2.22 and CIS v1.23 1.2.20
- audit-log-maxbackup=10 # CIS v1.20 1.2.23 and CIS v1.23 1.2.21
- audit-log-maxsize=100 # CIS v1.20 1.2.24 and CIS v1.23 1.2.22
```
## Known Issues
The following are controls that K3s currently does not pass by default. Each gap will be explained, along with a note clarifying whether it can be passed through manual operator intervention, or if it will be addressed in a future release of K3s.
### Control CIS v1.20 - 1.2.13 / CIS v1.23 - 1.2.14
Ensure that the admission control plugin `ServiceAccount` is set
<details>
<summary>Rationale</summary>
Follow the documentation and create `ServiceAccount` objects as per your environment. Then, edit the API server pod specification file $apiserverconf
on the control plane node and ensure that the `--disable-admission-plugins` parameter is set to a value that does not include `ServiceAccount`.
This can be remediated by adding the following argument line to K3s cluster configuration file:
```yaml
spec:
rkeConfig:
machineGlobalConfig:
kube-apiserver-arg:
kube-apiserver-arg:
- enable-admission-plugins=ServiceAccount # CIS v1.20 - 1.2.13 / CIS v1.23 - 1.2.14
```
</details>
### Control CIS v1.20 1.2.26 and CIS v1.23 1.2.23
Ensure that the `--request-timeout` argument is set as appropriate.
<details>
<summary>Rationale</summary>
Setting global request timeout allows extending the API server request timeout limit to a duration appropriate to the user's connection speed. By default, it is set to 60 seconds which might be problematic on slower connections making cluster resources inaccessible once the data volume for requests exceeds what can be transmitted in 60 seconds. But, setting this timeout limit to be too large can exhaust the API server resources making it prone to Denial-of-Service attack. Hence, it is recommended to set this limit as appropriate and change the default limit of 60 seconds only if needed.
This can be remediated by adding the following argument line to K3s cluster configuration file:
```yaml
spec:
rkeConfig:
machineGlobalConfig:
kube-apiserver-arg:
- request-timeout=300s # Control CIS v1.20 1.2.26 and CIS v1.23 1.2.23
```
</details>
### Control CIS v1.23 1.2.24
Ensure that the `--service-account-lookup` argument is set to true.
<details>
<summary>Rationale</summary>
If `--service-account-lookup` is not enabled, the apiserver only verifies that the authentication token is valid, and does not validate that the service account token mentioned in the request is actually present in etcd. This allows using a service account token even after the corresponding service account is deleted. This is an example of time of check to time of use security issue.
This can be remediated by adding the following argument line to K3s cluster configuration file:
```yaml
spec:
rkeConfig:
machineGlobalConfig:
kube-apiserver-arg:
- service-account-lookup=true # Control CIS v1.23 1.2.24
```
</details>
### CIS v1.20 1.2.32 and CIS v1.23 1.2.30
Ensure that the `--encryption-provider-config` argument is set as appropriate.
<details>
<summary>Rationale</summary>
`etcd` is a highly available key-value store used by Kubernetes deployments for persistent storage of all of its REST API objects. These objects are sensitive in nature and should be encrypted at rest to avoid any disclosures.
Detailed steps on how to configure secrets encryption in K3s are available in [K3s Secrets Encryption Config](https://docs.k3s.io/security/secrets-encryption).
</details>
### Control CIS v1.20 1.2.33 and CIS v1.23 1.2.31
Ensure that encryption providers are appropriately configured.
<details>
<summary>Rationale</summary>
Where `etcd` encryption is used, it is important to ensure that the appropriate set of encryption providers is used. Currently, the `aescbc`, `kms` and `secretbox` are likely to be appropriate options.
This can be remediated by passing a valid configuration to `k3s` as outlined above. Detailed steps on how to configure secrets encryption in K3s are available in [K3s Secrets Encryption Config](https://docs.k3s.io/security/secrets-encryption).
</details>
### Control 4.2.7
Ensure that the `--make-iptables-util-chains` argument is set to true.
<details>
<summary>Rationale</summary>
Kubelets can automatically manage the required changes to iptables based on how you choose your networking options for the pods. It is recommended to let kubelets manage the changes to iptables. This ensures that the iptables configuration remains in sync with pods networking configuration. Manually configuring iptables with dynamic pod network configuration changes might hamper the communication between pods/containers and to the outside world. You might have iptables rules too restrictive or too open.
This can be remediated by adding the following argument line to K3s cluster configuration file:
```yaml
spec:
rkeConfig:
machineSelectorConfig:
- config:
kubelet-arg:
- make-iptables-util-chains=true # Control 4.2.7
```
</details>
### Control 5.1.5
Ensure that default service accounts are not actively used
<details>
<summary>Rationale</summary>
Kubernetes provides a `default` service account which is used by cluster workloads where no specific service account is assigned to the pod.
Where access to the Kubernetes API from a pod is required, a specific service account should be created for that pod, and rights granted to that service account.
The default service account should be configured such that it does not provide a service account token and does not have any explicit rights assignments.
This can be remediated by updating the `automountServiceAccountToken` field to `false` for the `default` service account in each namespace.
For `default` service accounts in the built-in namespaces (`kube-system`, `kube-public`, `kube-node-lease`, and `default`), K3s does not automatically do this. You can manually update this field on these service accounts to pass the control or use the script below to automate this task.
Save the follow configuration to a file called `account_update.yaml`.
```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: default
automountServiceAccountToken: false
```
Create a bash script file called `account_update.sh`. Be sure to `sudo chmod +x account_update.sh` so the script has execute permissions.
```bash
#!/bin/bash -e
for namespace in $(kubectl get namespaces -A -o=jsonpath="{.items[*]['metadata.name']}"); do
echo -n "Patching namespace $namespace - "
kubectl patch serviceaccount default -n ${namespace} -p "$(cat account_update.yaml)"
done
```
Execute the script to update the default service account in each namespace.
</details>
### Reference Hardened K3s Template Configuration
The reference template configuration below is used in Rancher to create a hardened K3s custom cluster based on each CIS control presented in this guide. This reference does not include other required **cluster configuration** directives which will vary depending on your environment.
```yaml
apiVersion: provisioning.cattle.io/v1
kind: Cluster
metadata:
name: # Define cluster name
annotations:
spec:
defaultPodSecurityPolicyTemplateName: '' # Define the PSP policy to use
enableNetworkPolicy: true
kubernetesVersion: # Define K3s version
rkeConfig:
machineGlobalConfig:
kube-apiserver-arg:
- enable-admission-plugins=NodeRestriction,PodSecurityPolicy,ServiceAccount # CIS 1.2.16, CIS 5.2 and CIS v1.20 - 1.2.13 / CIS v1.23 - 1.2.14
- audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml # CIS v1.20/v1.23 3.2.1
- audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log # CIS v1.20 1.2.21 and CIS v1.23 1.2.19
- audit-log-maxage=30 # CIS v1.20 1.2.22 and CIS v1.23 1.2.20
- audit-log-maxbackup=10 # CIS v1.20 1.2.23 and CIS v1.23 1.2.21
- audit-log-maxsize=100 # CIS v1.20 1.2.24 and CIS v1.23 1.2.22
- request-timeout=300s # Control CIS v1.20 1.2.26 and CIS v1.23 1.2.23
- service-account-lookup=true # Control CIS v1.23 1.2.24
secrets-encryption: true
machineSelectorConfig:
- config:
kubelet-arg:
- make-iptables-util-chains=true # Control 4.2.7
protect-kernel-defaults: true # Control 4.2.6
```
### Conclusion
If you have followed this guide, your K3s custom cluster provisioned by Rancher will be configured to pass the CIS Kubernetes Benchmark. You can review our K3s CIS Benchmark Self-Assessment Guide for [CIS v1.20](k3s-self-assessment-guide-with-cis-v1.20-benchmark.md) and [CIS v1.23](k3s-self-assessment-guide-with-cis-v1.23-benchmark.md) to understand how we verified each of the benchmarks and how you can do the same on your cluster.
i18n/zh/docusaurus-plugin-content-docs/current/reference-guides/rancher-security/rancher-v2.7-hardening-guides/k3s-self-assessment-guide-with-cis-v1.20-benchmark.md
-3133
View File
File diff suppressed because it is too large Load Diff
i18n/zh/docusaurus-plugin-content-docs/current/reference-guides/rancher-security/rancher-v2.7-hardening-guides/k3s-self-assessment-guide-with-cis-v1.23-benchmark.md
-3143
View File
File diff suppressed because it is too large Load Diff
i18n/zh/docusaurus-plugin-content-docs/current/reference-guides/rancher-security/security-advisories-and-cves.md
+1
View File
@@ -6,6 +6,7 @@ Rancher 致力于向社区披露我们产品的安全问题。我们会针对已
| ID | 描述 | 日期 | 解决 |
|----|-------------|------|------------|
| [CVE-2023-22651](https://github.com/rancher/rancher/security/advisories/GHSA-6m9f-pj6w-w87g) | 由于 webhook 的更新逻辑失败，Rancher 准入 webhook 可能会配置错误。准入 webhook 在资源允许进入 Kubernetes 集群之前会强制执行验证规则和安全检查。webhook 在降级状态下运行时将不再验证任何资源，这可能导致严重的权限提升和数据损坏。 | 2023 年 4 月 24 日 | Rancher [v2.7.3](https://github.com/rancher/rancher/releases/tag/v2.7.3) |
| [CVE-2022-43758](https://github.com/rancher/rancher/security/advisories/GHSA-34p5-jp77-fcrc) | 在 Rancher 2.5.0 至 2.5.16、2.6.0 至 2.6.9 和 2.7.0 版本中发现了一个问题，Rancher Git 包中存在命令注入漏洞。这个包使用 Rancher 容器镜像中可用的底层 Git 二进制文件来执行 Git 操作。特制的命令如果没有消除歧义，可能会在通过 Git 执行时造成混淆，导致在底层 Rancher 主机中进行命令注入。 | 2023 年 1 月 24 日 | Rancher [v2.7.1](https://github.com/rancher/rancher/releases/tag/v2.7.1)、[v2.6.10](https://github.com/rancher/rancher/releases/tag/v2.6.10) 和 [v2.5.17](https://github.com/rancher/rancher/releases/tag/v2.5.17) |
| [CVE-2022-43757](https://github.com/rancher/rancher/security/advisories/GHSA-cq4p-vp5q-4522) | 此问题影响 Rancher 2.5.0 到 2.5.16，2.6.0 至 2.6.9 和 2.7.0。我们发现 Rancher 之前发布的安全公告 [CVE-2021-36782](https://github.com/advisories/GHSA-g7j7-h4q8-8w2f) 没有解决某些敏感字段、Secret Token、加密密钥和 SSH 密钥，这些字段仍然以明文形式直接存储在 Kubernetes 上 `Clusters` 之类的对象。在 Rancher 中，集群中已认证的 `Cluster Owners`、`Cluster Members`、`Project Owners` 和 `Project Members` 可以看到公开的凭证。 | 2023 年 1 月 24 日 | Rancher [v2.7.1](https://github.com/rancher/rancher/releases/tag/v2.7.1)、[v2.6.10](https://github.com/rancher/rancher/releases/tag/v2.6.10) 和 [v2.5.17](https://github.com/rancher/rancher/releases/tag/v2.5.17) |
| [CVE-2022-43755](https://github.com/rancher/rancher/security/advisories/GHSA-8c69-r38j-rpfj) | 在 Rancher 2.6.9 和 2.7.0 之前的版本中发现了一个问题，即 `cattle-cluster-agent` 使用的 `cattle-token` Secret 是可预测的。重新生成 Token 之后，Token 的值依然相同。如果 Token 被泄露并且出于安全目的需要重新创建，这可能会造成严重的问题。Rancher 的 `cattle-cluster-agent` 使用 `cattle-token` 来连接到 Rancher 配置的下游集群 Kubernetes API。 | 2023 年 1 月 24 日 | Rancher [v2.7.1](https://github.com/rancher/rancher/releases/tag/v2.7.1) 和 [v2.6.10](https://github.com/rancher/rancher/releases/tag/v2.6.10) |
i18n/zh/docusaurus-plugin-content-docs/current/reference-guides/user-settings/user-preferences.md
+50 -5
View File
@@ -2,16 +2,61 @@
title: 用户偏好
---
每个用户都可以设置自己的偏好，从而按照自己的喜好调整 Rancher UI 界面。要更改偏好设置，请打开**用户设置**菜单，然后选择**偏好设置**。
你可以通过偏好设置来个性化你的 Rancher 体验。要更改偏好设置：
1. 单击右上角的用户头像。
1. 单击**偏好设置**。
## 语言
选择 Rancher UI 显示的语言。选项包括：
- English
- 简体中文
## 主题
选择 Rancher UI 的背景颜色。如果选择**自动**，背景颜色会在下午 6 点从浅色变为深色，然后在早上 6 点变回浅色。
## 我的账号
## 登录页面
此部分显示用于会话的**名称**（你的显示名称）和**用户名**（你的登录名）。要更改你当前的密码，请单击**更改密码**按钮。
选择登录后显示的页面。选项包括：
## 每页表格行
- 主页。
- 上次访问的页面。
- 你选择的特定集群。
在使用表格来显示系统对象（如集群或 deployment）的页面中，你可以设置每页显示的最大对象数量。默认设置为 `50`。
## 显示设置
选择信息的显示方式：
- 日期格式
- 时间格式
- 每页行数
- 在侧边栏显示的集群数量
## 确认设置
_从 v2.7.2 起可用_
选择缩减节点池时是否要求确认。
## 高级功能
- 启用“在 API 中查看”。
- 显示由 Rancher 管理的 system 命名空间（不要编辑或删除）。
- 使用快捷键（shift+T）来切换深色/浅色主题。
- 隐藏所有类型描述。
- 启用扩展开发者功能。
![](/img/user-preferences-2-7.png)
## YAML 编辑器
- 默认
- Emacs
- Vim
## Helm Chart
选择仅显示已发布的 Helm Chart 还是同时包含预发布版本。如果版本符合 [Semantic Versioning 2.0.0](https://semver.org/) 定义的[规范](https://semver.org/#spec-item-9)，则那么该版本为预发布版本。例如，要显示版本为 `0.1.3-dev.12ab4f` 的 Helm chart，你需要先选择`包括预发布版本`。
i18n/zh/docusaurus-plugin-content-docs/version-2.6.json
+4 -4
View File
@@ -335,10 +335,6 @@
"message": "CIS 扫描",
"description": "The label for category CIS Scans in sidebar tutorialSidebar"
},
"sidebar.tutorialSidebar.category.Fleet - GitOps at Scale": {
"message": "Fleet - 大规模的 GitOps",
"description": "The label for category Fleet - GitOps at Scale in sidebar tutorialSidebar"
},
"sidebar.tutorialSidebar.category.Istio": {
"message": "Istio",
"description": "The label for category Istio in sidebar tutorialSidebar"
@@ -374,5 +370,9 @@
"sidebar.tutorialSidebar.category.Other Troubleshooting Tips": {
"message": "其他故障排除提示",
"description": "The label for category Other Troubleshooting Tips in sidebar tutorialSidebar"
},
"sidebar.tutorialSidebar.category.Continuous Delivery with Fleet": {
"message": "使用 Feet 进行持续交付",
"description": "The label for category Continuous Delivery with Fleet in sidebar tutorialSidebar"
}
}
i18n/zh/docusaurus-plugin-content-docs/version-2.6/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-aks.md
+13 -3
View File
@@ -50,7 +50,7 @@ az group create --name rancher-rg --location eastus
:::note
如果 Kubernetes 的版本更新到 v1.22 或更高版本，则 ingress-nginx 的版本也需要[更新](https://kubernetes.github.io/ingress-nginx/user-guide/k8s-122-migration/)。
如果你要从旧的 Kubernetes 版本更新到 Kubernetes v1.22 或更高版本，你还需要[更新](https://kubernetes.github.io/ingress-nginx/user-guide/k8s-122-migration/) ingress-nginx。
:::
@@ -79,16 +79,26 @@ az aks get-credentials --resource-group rancher-rg --name rancher-server
集群需要一个 Ingress，以从集群外部访问 Rancher。要 Ingress，你需要分配一个公共 IP 地址。请确保你有足够的配额，否则它将无法分配 IP 地址。公共 IP 地址的限制在每个订阅的区域级别生效。
以下命令安装了带有 Kubernetes 负载均衡器服务的 `nginx-ingress-controller`。
为确保你选择了正确的 Ingress-NGINX Helm Chart，首先在 [Kubernetes/ingress-nginx 支持表](https://github.com/kubernetes/ingress-nginx#supported-versions-table)中找到与你的 Kubernetes 版本兼容的 `Ingress-NGINX 版本`。
然后，运行以下命令列出可用的 Helm Chart：
```
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
helm search repo ingress-nginx -l
```
`helm search` 命令的输出包含一个 `APP VERSION` 列。此列下的版本等同于你之前选择的 `Ingress-NGINX 版本`。使用应用程序版本，选择一个 Chart 版本，该版本打包了与你的 Kubernetes 兼容的应用程序。例如，如果使用的是 Kubernetes v1.23，则可以选择 4.5.2 Helm Chart，因为 Ingress-NGINX v1.6.4 与该 Chart 打包在一起，而 v1.6.4 与 Kubernetes v1.23 兼容。如有疑问，请选择最新的兼容版本。
了解你需要的 Helm chart `版本`后，运行以下命令。它安装一个带有 Kubernetes 负载均衡器服务的 `nginx-ingress-controller`：
```
helm upgrade --install \
ingress-nginx ingress-nginx/ingress-nginx \
--namespace ingress-nginx \
--set controller.service.type=LoadBalancer \
--version 4.0.18 \
--version 4.5.2 \
--create-namespace
```
i18n/zh/docusaurus-plugin-content-docs/version-2.6/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks.md
+13 -3
View File
@@ -79,7 +79,7 @@ aws configure
运行以下命令创建一个 EKS 集群。使用适用于你的用例的 AWS 区域。在选择 Kubernetes 版本时，请务必先查阅[支持矩阵](https://rancher.com/support-matrix/)，以找出已针对你的 Rancher 版本验证的最新 Kubernetes 版本。
**注意**：如果 Kubernetes 的版本更新到 v1.22 或更高版本，则 ingress-nginx 的版本也需要[更新](https://kubernetes.github.io/ingress-nginx/user-guide/k8s-122-migration/)。
**注意**：如果你要从旧的 Kubernetes 版本更新到 Kubernetes v1.22 或更高版本，你还需要[更新](https://kubernetes.github.io/ingress-nginx/user-guide/k8s-122-migration/) ingress-nginx。
```
eksctl create cluster \
@@ -117,16 +117,26 @@ rancher-server-cluster us-west-2 True
集群需要一个 Ingress，以从集群外部访问 Rancher。
以下命令安装了一个 `nginx-ingress-controller`和一个 LoadBalancer 服务。因此，NGINX 前面会有一个 ELB（Elastic Load Balancer）：
为确保你选择了正确的 Ingress-NGINX Helm Chart，首先在 [Kubernetes/ingress-nginx 支持表](https://github.com/kubernetes/ingress-nginx#supported-versions-table)中找到与你的 Kubernetes 版本兼容的 `Ingress-NGINX 版本`。
然后，运行以下命令列出可用的 Helm Chart：
```
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
helm search repo ingress-nginx -l
```
`helm search` 命令的输出包含一个 `APP VERSION` 列。此列下的版本等同于你之前选择的 `Ingress-NGINX 版本`。使用应用程序版本，选择一个 Chart 版本，该版本打包了与你的 Kubernetes 兼容的应用程序。例如，如果使用的是 Kubernetes v1.23，则可以选择 4.5.2 Helm Chart，因为 Ingress-NGINX v1.6.4 与该 Chart 打包在一起，而 v1.6.4 与 Kubernetes v1.23 兼容。如有疑问，请选择最新的兼容版本。
了解你需要的 Helm chart `版本`后，运行以下命令。它安装一个带有 Kubernetes 负载均衡器服务的 `nginx-ingress-controller`：
```
helm upgrade --install \
ingress-nginx ingress-nginx/ingress-nginx \
--namespace ingress-nginx \
--set controller.service.type=LoadBalancer \
--version 4.0.18 \
--version 4.5.2 \
--create-namespace
```
i18n/zh/docusaurus-plugin-content-docs/version-2.6/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-gke.md
+1 -1
View File
@@ -120,7 +120,7 @@ Your active configuration is: [default]
要使用 Rancher 成功创建 GKE 集群，GKE 必须处于 Standard 模式。GKE 在创建 Kubernetes 集群时有两种运行模式，分别是 Autopilot 和 Standard 模式。Autopilot 模式的集群配置对编辑 kube-system 命名空间有限制。但是，Rancher 在安装时需要在 kube-system 命名空间中创建资源。因此，你将无法在以 Autopilot 模式创建的 GKE 集群上安装 Rancher。如需详细了解 GKE Autopilot 模式和 Standard 模式之间的差异，请访问[比较 GKE Autopilot 和 Standard ](https://cloud.google.com/kubernetes-engine/docs/resources/autopilot-standard-feature-comparison)。
**注意**：如果 Kubernetes 的版本更新到 v1.22 或更高版本，则 ingress-nginx 的版本也需要[更新](https://kubernetes.github.io/ingress-nginx/user-guide/k8s-122-migration/)。
**注意**：如果你要从旧的 Kubernetes 版本更新到 Kubernetes v1.22 或更高版本，你还需要[更新](https://kubernetes.github.io/ingress-nginx/user-guide/k8s-122-migration/) ingress-nginx。
```
gcloud container clusters create cluster-name --num-nodes=3 --cluster-version=<VERSION>
i18n/zh/docusaurus-plugin-content-docs/version-2.6/getting-started/installation-and-upgrade/installation-references/feature-flags.md
+24 -28
View File
@@ -2,42 +2,38 @@
title: 功能开关
---
为了让你试用默认关闭的实验功能，我们引入了功能开关（feature flag）。
使用功能开关（Feature Flag），你可以试用可选或实验性的功能并启用正在逐步淘汰的旧版功能。
如需了解功能的值以及如何启用功能，请参阅[此处](../../../pages-for-subheaders/enable-experimental-features.md)。
要了解功能的值以及如何启用它们，请参阅[启用实验性功能](../../../pages-for-subheaders/enable-experimental-features.md)。
:::note
某些功能需要重启 Rancher Server 容器才能生效。我们在文档的表格和 UI 中对这些功能进行了标记。
某些功能要求重新启动 Rancher 容器。Rancher UI 中标记了要求重启的功能。
:::
以下是 Rancher 中可用的功能开关列表：
以下是 Rancher 中可用的功能开关列表。如果你是从旧 Rancher 版本升级的，你可能会在 Rancher UI 中看到其他功能，例如 `proxy` 或 `dashboard`（均[已中断](/versioned_docs/version-2.5/reference-guides/installation-references/feature-flags.md)）：
- `harvester`：从 2.6.1 开始可用。Harvester 用于管理 Virtualization Management 页面的访问。用户可以在该页面直接导航到 Harvester 集群并访问 Harvester UI。详情请参见[本页](../../../integrations-in-rancher/harvester.md#功能开关)。
- `rke2`：用于启用配置 RKE2 集群的功能。这个功能开关默认开启，即允许用户尝试配置此类集群。
- `fleet`：由于 Fleet 功能已应用到新的配置框架中，因此我们需要启用先前的 `fleet` 功能开关。如果你在早期版本中禁用了此功能开关，升级到 Rancher 2.6 后，该功能开关会自动启用。详情请参见[此页](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md)。
- `continuous-delivery`：在 Rancher v2.5.x 中，Fleet 带有 GitOps 功能，该功能不能与 Fleet 分开禁用。在 Rancher 2.6 中，我们引入了 `continuous-delivery` 功能开关，让你可以单独禁用 Fleet 的 GitOps 功能。如需更多信息，请参阅[此页面](../../../how-to-guides/advanced-user-guides/enable-experimental-features/continuous-delivery.md)。
- `legacy`：Rancher 会逐渐淘汰之前版本中的某些功能，以实现功能迭代。此处包括已弃用，以及之后会转移到其他地方的功能。默认情况下，新安装会禁用此功能开关。如果你从先前的版本升级，此功能开关会启用。
- `token-hashing`：用于启动新的 token-hashing 功能。启用后，会使用 SHA256 算法对现有 Token 和所有新 Token 进行哈希处理。一旦对 Token 进行哈希处理，就无法撤消操作。该功能开关启用后无法被禁用。详情请参见[哈西处理 Token](../../../reference-guides/about-the-api/api-tokens.md)。
- `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](../../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md)。
- `harvester`：从 2.6.1 开始可用。管理 Virtualization Management 页面的访问。用户可以在该页面直接导航到 Harvester 集群并访问 Harvester UI。有关详细信息，请参阅 [Harvester 集成](../../../integrations-in-rancher/harvester.md)。
- `istio-virtual-service-ui`：启用[可视界面](../../../how-to-guides/advanced-user-guides/enable-experimental-features/istio-traffic-management-features.md)来创建、读取、更新和删除 Istio 虚拟服务和目标规则，这些都是 Istio 流量管理功能。
- `legacy`：启用 2.5.x 及更早版本的一组功能，这些功能正逐渐被新的实现淘汰。它们是已弃用以及后续可用于新版本的功能组合。新的 Rancher 安装会默认禁用此标志。如果你从以前版本的 Rancher 升级，此标志会启用。
- `multi-cluster-management`：允许配置和管理多个 Kubernetes 集群。此标志只能在安装时设置。后续无法启用或禁用它。
- `rke2`：启用配置 RKE2 集群。此标志默认启用。
- `token-hashing`：启用令牌哈希。启用后，会使用 SHA256 算法对现有 Token 和所有新 Token 进行哈希处理。一旦对 Token 进行哈希处理，就无法撤消操作。此标志在启用后无法禁用。有关详细信息，请参阅 [API 令牌](../../../reference-guides/about-the-api/api-tokens.md#令牌哈希)。
- `unsupported-storage-drivers`：该功能[允许使用不支持的存储驱动](../../../how-to-guides/advanced-user-guides/enable-experimental-features/unsupported-storage-drivers.md)。换言之，此功能允许你使用默认情况下未启用的存储提供商和卷插件。
- `istio-virtual-service-ui`：此功能让你[启动用于管理 Istio 流量的 UI，其中包括创建、读取、更新和删除 Istio 虚拟服务（Virtual Service）和目标规则（Destination Rule）](../../../how-to-guides/advanced-user-guides/enable-experimental-features/istio-traffic-management-features.md)。
- `multi-cluster-management`：用于配置和管理多个 Kubernetes 集群。此功能开关只能在安装时设置，之后不能更改。
下表介绍了 Rancher 中功能开关的可用版本和默认值：
下表介绍了 Rancher 中功能开关的可用性和默认值。标记为“GA”的功能已普遍可用：
| 功能开关名称 | 默认值 | 状态 | 可用于 | 是否需要重启 Rancher |
| ----------------------------- | ------------- | ------------ | --------------- |---|
| `istio-virtual-service-ui` | `false` | 实验功能 | v2.3.0 | |
| `istio-virtual-service-ui` | `true` | GA* | v2.3.2 | |
| `unsupported-storage-drivers` | `false` | 实验功能 | v2.3.0 | |
| `fleet` | `true` | GA* | v2.5.0 | |
| `fleet` | `true` | 不能禁用 | v2.6.0 | N/A |
| `continuous-delivery` | `true` | GA* | v2.6.0 | |
| `token-hashing` | 新安装：`false`；升级：`true` | GA* | v2.6.0 | |
| `legacy` | 新安装：`false`；升级：`true` | GA* | v2.6.0 | |
| `multi-cluster-management` | `false` | GA* | v2.5.0 | |
| `harvester` | `true` | 实验功能 | v2.6.1 | |
| `rke2` | `true` | 实验功能 | v2.6.0 | |
\* 一般情况下可用。此功能包含在 Rancher 中，不是实验功能的。
| 功能开关名称 | 默认值 | 状态 | 可用于 |
| ----------------------------- | ------------- | ------------ | --------------- |
| `continuous-delivery` | `true` | GA | v2.6.0 |
| `fleet` | `true` | 不能禁用 | v2.6.0 |
| `fleet` | `true` | GA | v2.5.0 |
| `harvester` | `true` | 实验功能 | v2.6.1 |
| `legacy` | 新安装：`false`；升级：`true` | GA | v2.6.0 |
| `multi-cluster-management` | `false` | GA | v2.5.0 |
| `rke2` | `true` | 实验功能 | v2.6.0 |
| `token-hashing` | 新安装：`false`；升级：`true` | GA | v2.6.0 |
| `unsupported-storage-drivers` | `false` | 实验功能 | v2.3.0 |
i18n/zh/docusaurus-plugin-content-docs/version-2.6/getting-started/installation-and-upgrade/installation-references/helm-chart-options.md
+42 -7
View File
@@ -89,13 +89,19 @@ kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{
### 额外设置环境变量
你可以使用 `extraEnv` 为 Rancher Server 额外设置环境变量。该列表使用与容器清单定义相同的 `name` 和 `value` 键。记住需要给值加上引号。
你可以使用 `extraEnv` 为 Rancher Server 额外设置环境变量。该列表以 YAML 格式传递给 Rancher 部署，它嵌入在 Rancher 容器的 `env` 下。你可以参考 Kubernetes 文档设置容器环境变量。`extraEnv` 可以使用 [Define Environment Variables for a Container](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/#define-an-environment-variable-for-a-container) 中引用的任何键。
使用 `name` 和 `value` 键的示例：
```plain
--set 'extraEnv[0].name=CATTLE_TLS_MIN_VERSION'
--set 'extraEnv[0].value=1.0'
```
如果将敏感数据（例如代理认证凭证）作为环境变量的值传递，则强烈建议使用 Secret 引用。这将防止敏感数据在 Helm 或 Rancher 部署中暴露。
你可以参考使用 `name`、`valueFrom.secretKeyRef.name` 和 `valueFrom.secretKeyRef.key` 键的示例。详见 [HTTP 代理](#http-代理)中的示例。
### TLS 设置
当你在 Kubernetes 集群内安装 Rancher 时，TLS 会在集群的 Ingress Controller 上卸载。支持的 TLS 设置取决于使用的 Ingress Controller。
@@ -122,7 +128,7 @@ kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{
### 自定义 Ingress
要自定义或使用 Rancher Server 的其他 Ingress，你可以设置自己的 Ingress annotations。
要自定义或使用 Rancher Server 的其他 Ingress，你可以设置自己的 Ingress 注释。
设置自定义证书颁发者的示例：
@@ -130,7 +136,7 @@ kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{
--set ingress.extraAnnotations.'cert-manager\.io/cluster-issuer'=issuer-name
```
以下是使用 `ingress.configurationSnippet`设置静态代理头的实例。该值像模板一样进行解析，因此可以使用变量。
以下是使用 `ingress.configurationSnippet`设置静态代理标头的示例。该值像模板一样进行解析，因此可以使用变量。
```plain
--set ingress.configurationSnippet='more_set_input_headers X-Forwarded-Host {{ .Values.hostname }};'
@@ -138,15 +144,44 @@ kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{
### HTTP 代理
Rancher 的一些功能（Helm Chart）需要使用互联网才能使用。使用 `proxy` 来设置你的代理服务器。
Rancher 的一些功能（Helm Chart）需要使用互联网才能使用。你可以使用 `proxy` 设置代理服务器，或使用 `extraEnv` 设置 `HTTPS_PROXY` 环境变量来指向代理服务器。
在 `noProxy` 列表中添加例外的 IP。确保你已添加了 Pod 集群 IP 范围（默认：`10.42.0.0/16`），服务集群 IP 范围（默认：`10.43.0.0/16`），内部集群域名（默认：`.svc,.cluster.local`）和所有 worker 集群 `controlplane` 节点。Rancher 支持在此列表中使用 CIDR 表示法范围。
将要排除的 IP 使用逗号分隔列表添加到 `noProxy` Chart value 中。确保添加了以下值：
- Pod 集群 IP 范围（默认值：`10.42.0.0/16`）。
- Service Cluster IP 范围（默认值：`10.43.0.0/16`）。
- 内部集群域（默认值：`.svc,.cluster.local`）。
- 任何 Worker 集群 `controlplane` 节点。
Rancher 支持在此列表中使用 CIDR 表示法来表示范围。
不包括敏感数据时，可以使用 `proxy` 或 `extraEnv` Chart 选项。使用 `extraEnv` 时将忽略 `noProxy` Helm 选项。因此，`NO_PROXY` 环境变量也必须设置为 `extraEnv`。
以下是使用 `extraEnv` Chart 选项设置代理的示例：
```plain
--set proxy="http://<username>:<password>@<proxy_url>:<proxy_port>/"
--set noProxy="127.0.0.0/8\,10.0.0.0/8\,172.16.0.0/12\,192.168.0.0/16\,.svc\,.cluster.local"
--set proxy="http://<proxy_url:proxy_port>/"
```
使用 `extraEnv` Chart 选项设置代理的示例：
```plain
--set extraEnv[1].name=HTTPS_PROXY
--set extraEnv[1].value="http://<proxy_url>:<proxy_port>/"
--set extraEnv[2].name=NO_PROXY
--set extraEnv[2].value="127.0.0.0/8\,10.0.0.0/8\,172.16.0.0/12\,192.168.0.0/16\,.svc\,.cluster.local"
```
包含敏感数据（例如代理认证凭证）时，请使用 `extraEnv` 选项和 `valueFrom.secretRef` 来防止敏感数据在 Helm 或 Rancher 部署中暴露。
下面是使用 `extraEnv` 配置代理的示例。此示例 Secret 在 Secret 的 `"https-proxy-url"` 键中包含 `"http://<username>:<password>@<proxy_url>:<proxy_port>/"` 值：
```plain
--set extraEnv[1].name=HTTPS_PROXY
--set extraEnv[1].valueFrom.secretKeyRef.name=secret-name
--set extraEnv[1].valueFrom.secretKeyRef.key=https-proxy-url
--set extraEnv[2].name=NO_PROXY
--set extraEnv[2].value="127.0.0.0/8\,10.0.0.0/8\,172.16.0.0/12\,192.168.0.0/16\,.svc\,.cluster.local"
```
有关如何配置环境变量的更多信息，请参阅[为容器定义环境变量](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/#define-an-environment-variable-for-a-container)。
### 额外的授信 CA
如果你有私有镜像仓库（registries）、应用商店（catalogs）或拦截证书的代理，则可能需要向 Rancher 添加额外的授信 CA。
i18n/zh/docusaurus-plugin-content-docs/version-2.6/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha.md
+6 -13
View File
@@ -80,15 +80,8 @@ Rancher Server 默认设计为安全的，并且需要 SSL/TLS 配置。
#### 选项 A：使用 Rancher 默认的自签名证书
默认情况下，Rancher 会生成一个 CA 并使用 cert-manager 颁发证书以访问 Rancher Server 界面。
:::note
由于 cert-manager 的最新改动，你需要升级 cert-manager 版本。如果你需要升级 Rancher 并使用低于 0.11.0 的 cert-manager 版本，请参见 [cert-manager 升级文档](../../resources/upgrade-cert-manager.md)。
:::
##### 1. 添加 cert-manager 仓库
在可以连接互联网的系统中，将 cert-manager 仓库添加到 Helm：
@@ -102,12 +95,6 @@ helm repo update
从 [Helm Chart 仓库](https://artifacthub.io/packages/helm/cert-manager/cert-manager)中获取最新可用的 cert-manager Chart：
:::note
v2.6.4 兼容 cert-manager 版本 1.6.2 和 1.7.1。推荐使用 v1.7.x，因为 v 1.6.x 将在 2022 年 3 月 30 日结束生命周期。
:::
```plain
helm fetch jetstack/cert-manager --version v1.11.0
```
@@ -128,6 +115,12 @@ curl -L -o cert-manager-crd.yaml https://github.com/cert-manager/cert-manager/re
使用要用于安装 Chart 的选项来安装 cert-manager。记住要设置 `image.repository` 选项，以从你的私有镜像仓库拉取镜像。此操作会创建一个包含 Kubernetes manifest 文件的 `cert-manager` 目录。
:::note
要查看自定义 cert-manager 安装的选项（包括集群使用 PodSecurityPolicies 的情况），请参阅 [cert-manager 文档](https://artifacthub.io/packages/helm/cert-manager/cert-manager#configuration)。
:::
<details id="install-cert-manager">
<summary>单击展开</summary>
i18n/zh/docusaurus-plugin-content-docs/version-2.6/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/publish-images.md
-6
View File
@@ -64,12 +64,6 @@ v2.6.4 兼容 cert-manager 版本 1.6.2 和 1.7.1。推荐使用 v1.7.x，因为
1. 获取最新的 `cert-manager` Helm Chart，并解析模板以获取镜像的详情信息：
:::note
由于 cert-manager 的最新改动，你需要升级 cert-manager 版本。如果你需要升级 Rancher 并使用低于 0.12.0 的 cert-manager 版本，请参见[升级文档](../../resources/upgrade-cert-manager.md)。
:::
```plain
helm repo add jetstack https://charts.jetstack.io
helm repo update
i18n/zh/docusaurus-plugin-content-docs/version-2.6/getting-started/installation-and-upgrade/other-installation-methods/rancher-behind-an-http-proxy/install-rancher.md
+6
View File
@@ -38,6 +38,12 @@ kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/
使用 Helm 安装 cert-manager。请注意，cert-manager 还需要你配置代理，以防它需要与 Let's Encrypt 或其他外部证书颁发商进行通信：
:::note
要查看自定义 cert-manager 安装的选项（包括集群使用 PodSecurityPolicies 的情况），请参阅 [cert-manager 文档](https://artifacthub.io/packages/helm/cert-manager/cert-manager#configuration)。
:::
```
helm upgrade --install cert-manager jetstack/cert-manager \
--namespace cert-manager --version v1.11.0 \
i18n/zh/docusaurus-plugin-content-docs/version-2.6/getting-started/quick-start-guides/deploy-rancher-manager/aws.md
+1 -1
View File
@@ -52,7 +52,7 @@ AWS 模块只创建一个 EC2 密钥对、一个 EC2 安全组和一个 EC2 实
- `aws_access_key` - 替换为 Amazon AWS 访问密钥
- `aws_secret_key` - 替换为 Amazon AWS Secret 密钥
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码（最少 12 字符）
5. **可选**：修改 `terraform.tfvars` 中的可选参数。参见 [Quickstart Readme](https://github.com/rancher/quickstart) 以及 [AWS Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/aws) 了解更多信息。
建议包括：
i18n/zh/docusaurus-plugin-content-docs/version-2.6/getting-started/quick-start-guides/deploy-rancher-manager/azure.md
+1 -1
View File
@@ -39,7 +39,7 @@ description: 阅读此分步 Rancher Azure 指南，以快速部署带有单节
- `azure_client_id` - 替换为 Microsoft Azure 客户端 ID。
- `azure_client_secret` - 替换为 Microsoft Azure 客户端密文。
- `azure_tenant_id` - 替换为 Microsoft Azure 租户 ID。
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码（最少 12 字符）
5. **可选**：修改 `terraform.tfvars` 中的可选参数。
参见 [Quickstart Readme](https://github.com/rancher/quickstart) 以及 [Azure Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/azure) 了解更多信息。建议包括：
i18n/zh/docusaurus-plugin-content-docs/version-2.6/getting-started/quick-start-guides/deploy-rancher-manager/digitalocean.md
+1 -1
View File
@@ -33,7 +33,7 @@ description: 阅读此分步 Rancher DigitalOcean 指南，以快速部署带有
4. 编辑 `terraform.tfvars` 文件，并替换以下变量：
- `do_token` - 替换为 DigitalOcean 访问密钥
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码（最少 12 字符）
5. **可选**：修改 `terraform.tfvars` 中的可选参数。
参见 [Quickstart Readme](https://github.com/rancher/quickstart) 以及 [DO Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/do) 了解更多信息。建议包括：
i18n/zh/docusaurus-plugin-content-docs/version-2.6/getting-started/quick-start-guides/deploy-rancher-manager/gcp.md
+1 -1
View File
@@ -34,7 +34,7 @@ description: 阅读此分步 Rancher GCP 指南，以快速部署带有单节点
4. 编辑 `terraform.tfvars` 文件，并替换以下变量：
- `gcp_account_json` - 替换为 GCP ServiceAccount 文件路径和文件名。
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码（最少 12 字符）
5. **可选**：修改 `terraform.tfvars` 中的可选参数。
参见 [Quickstart Readme](https://github.com/rancher/quickstart) 以及 [GCP Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/gcp) 了解更多信息。
i18n/zh/docusaurus-plugin-content-docs/version-2.6/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md
+8
View File
@@ -90,6 +90,12 @@ notepad.exe $env:USERPROFILE\.kube\config
从本地工作站运行以下命令。你需要先安装 [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) 和 [helm](https://helm.sh/docs/intro/install/)：
:::note
要查看自定义 cert-manager 安装的选项（包括集群使用 PodSecurityPolicies 的情况），请参阅 [cert-manager 文档](https://artifacthub.io/packages/helm/cert-manager/cert-manager#configuration)。
:::
```
helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
@@ -117,6 +123,8 @@ helm install cert-manager jetstack/cert-manager `
要安装特定的 Rancher 版本，请使用 `--version` 标志（例如，`--version 2.6.6`）。否则，默认安装最新的 Rancher。请参阅[选择 Rancher 版本](../../installation-and-upgrade/resources/choose-a-rancher-version.md)。
请注意，密码至少需要 12 个字符。
```
helm install rancher rancher-latest/rancher \
--namespace cattle-system \
i18n/zh/docusaurus-plugin-content-docs/version-2.6/getting-started/quick-start-guides/deploy-rancher-manager/hetzner-cloud.md
+1 -1
View File
@@ -33,7 +33,7 @@ description: 阅读此分步 Rancher Hetzner Cloud 指南，以快速部署带
4. 编辑 `terraform.tfvars` 文件，并替换以下变量：
- `hcloud_token` - 替换为 Hetzner API 访问密钥。
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码（最少 12 字符）
5. **可选**：修改 `terraform.tfvars` 中的可选参数。
参见 [Quickstart Readme](https://github.com/rancher/quickstart) 以及 [Hetzner Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/hcloud) 了解更多信息。
i18n/zh/docusaurus-plugin-content-docs/version-2.6/getting-started/quick-start-guides/deploy-rancher-manager/outscale-qs.md
+1 -1
View File
@@ -34,7 +34,7 @@ description: 阅读此分步 Rancher Outscale 指南，以快速部署带有单
4. 编辑 `terraform.tfvars` 文件，并替换以下变量：
- `access_key_id` - 替换为 Outscale 访问密钥
- `secret_key_id` - 替换为 Outscale 密文密钥
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码
- `rancher_server_admin_password` - 替换为创建 Rancher Server 的 admin 账号的密码（最少 12 字符）
5. **可选**：修改 `terraform.tfvars` 中的可选参数。
参见 [Quickstart Readme](https://github.com/rancher/quickstart) 以及 [Outscale Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/outscale) 了解更多信息。
i18n/zh/docusaurus-plugin-content-docs/version-2.6/getting-started/quick-start-guides/deploy-rancher-manager/vagrant.md
+1 -1
View File
@@ -31,7 +31,7 @@ title: Vagrant 快速入门
3. **可选**：编辑 `config.yaml` 文件：
- 根据需要更改节点数和内存分配（`node.count`, `node.cpus`, `node.memory`）
- 更改 `admin` 的密码以登录 Rancher。(`admin_password`)
- 更改 `admin` 的密码以登录 Rancher。（`admin_password`，最少 12 个字符）
4. 执行 `vagrant up --provider=virtualbox` 以初始化环境。
i18n/zh/docusaurus-plugin-content-docs/version-2.6/how-to-guides/advanced-user-guides/monitoring-alerting-guides/prometheus-federator-guides/enable-prometheus-federator.md
+6 -1
View File
@@ -75,7 +75,12 @@ matchLabels:
1. 单击 **Prometheus Federator** Chart。
1. 单击**安装**。
1. 在**元数据**页面，点击**下一步**。
1. 在**项目 Release 命名空间项目 ID** 字段中，`System 项目`是默认值，但你可以使用具有类似[有限访问权限](#确保-cattle-monitoring-system-命名空间位于-system-项目中（或者位于一个锁定并能访问集群中其他项目的项目中）)的另一个项目覆盖它。<!-- add info on retrieving project IDs >
1. 在**项目 Release 命名空间项目 ID** 字段中，`System 项目`是默认值，但你可以使用具有类似[有限访问权限](#确保-cattle-monitoring-system-命名空间位于-system-项目中（或者位于一个锁定并能访问集群中其他项目的项目中）)的另一个项目覆盖它。你可以在 local 上游集群中运行以下命令来找到项目 ID：
```plain
kubectl get projects -A -o custom-columns="NAMESPACE":.metadata.namespace,"ID":.metadata.name,"NAME":.spec.displayName
```
1. 单击**安装**。
**结果**：Prometheus Federator 应用程序已部署在 `cattle-monitoring-system` 命名空间中。
i18n/zh/docusaurus-plugin-content-docs/version-2.6/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/manage-rke1-templates.md
+1 -1
View File
@@ -146,7 +146,7 @@ title: 创建和修改 RKE 模板
你可以将现有集群的设置保存为 RKE 模板。
这将把集群的设置导出为新的 RKE 模板，并且将集群绑定到该模板。然后，只有[更新了模板](manage-rke1-templates.md#更新模板)并且集群升级到**使用更新版本的模板**时，集群才能改变。
这将把集群的设置导出为新的 RKE 模板，并且将集群绑定到该模板。然后，只有[更新了模板](#更新模板)并且集群升级到[使用更新版本的模板](#升级集群以使用新的模板修订版)时，集群才能改变。
要将现有集群转换为使用 RKE 模板：
i18n/zh/docusaurus-plugin-content-docs/version-2.6/how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md
+2 -2
View File
@@ -1,8 +1,8 @@
---
title: Fleet - 大规模的 GitOps
title: 使用 Feet 进行持续交付
---
Fleet 是大规模的 GitOps。你可以使用 Fleet 管理多达一百万个集群。Fleet 非常轻量，可以很好地用于[单个集群](https://fleet.rancher.io/single-cluster-install/)，但是在你达到[大规模](https://fleet.rancher.io/multi-cluster-install/)时，它能发挥更强的实力。此处的大规模指的是大量集群、大量部署、或组织中存在大量团队的情况。
使用 Fleet 的持续交付是大规模的 GitOps。你可以使用 Fleet 管理多达一百万个集群。Fleet 非常轻量，可以很好地用于[单个集群](https://fleet.rancher.io/single-cluster-install/)，但是在你达到[大规模](https://fleet.rancher.io/multi-cluster-install/)时，它能发挥更强的实力。此处的大规模指的是大量集群、大量部署、或组织中存在大量团队的情况。
Fleet 是一个独立于 Rancher 的项目，你可以使用 Helm 将它安装在任何 Kubernetes 集群上。
i18n/zh/docusaurus-plugin-content-docs/version-2.6/how-to-guides/new-user-guides/kubernetes-cluster-setup/rke1-for-rancher.md
+4
View File
@@ -40,6 +40,8 @@ Rancher 可以运行在任何 Kubernetes 集群上，包括托管的 Kubernetes
RKE 需要通过 SSH 连接到每个节点，它会在 `~/.ssh/id_rsa`的默认位置查找私钥。如果某个节点的私钥不在默认位置中，你还需要为该节点配置 `ssh_key_path` 选项。
在选择 Kubernetes 版本时，请务必先查阅[支持矩阵](https://rancher.com/support-matrix/)，以找出已针对你的 Rancher 版本验证的最新 Kubernetes 版本。
```yaml
nodes:
- address: 165.227.114.63
@@ -67,6 +69,8 @@ ingress:
provider: nginx
options:
use-forwarded-headers: "true"
kubernetes_version: v1.24.13-rancher2-1
```
<figcaption>通用 RKE 节点选项</figcaption>
i18n/zh/docusaurus-plugin-content-docs/version-2.6/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md
+6 -1
View File
@@ -136,7 +136,12 @@ Rancher 管理注册集群的范围取决于集群的类型。
K3s 集群注册到 Rancher 后，Rancher 会将它识别为 K3s。Rancher UI 将开放[所有已注册集群](#所有已注册集群的功能)的功能，以及以下用于编辑和升级集群的功能：
- [升级 K3s 版本](../../../getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md)
- [升级 K3s 版本](../../../getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md)的能力
:::danger
将集群导入 Rancher 后，你需要使用 Rancher 执行升级。**不**支持在 Rancher 之外升级导入的集群。
:::
- 配置能同时升级的最大节点数
- 查看 K3s 集群的配置参数和用于启动集群中每个节点的环境变量的只读版本
i18n/zh/docusaurus-plugin-content-docs/version-2.6/how-to-guides/new-user-guides/kubernetes-resources-setup/load-balancer-and-ingress-controller/ingress-configuration.md
+3 -3
View File
@@ -23,9 +23,9 @@ description: Ingress 配置
1. 输入**请求主机**，你的 Ingress Controller 会为它处理请求转发。例如，`www.mysite.com`。
1. 指定类型为 `Prefix` 的路径并指定路径，例如 `/`。
2. 添加一个**目标服务**。
3. **可选**：如果你想在将请求发送到特定主机名路径时指定工作负载或服务，请为目标添加**路径**。例如，如果你希望将 `www.mysite.com/contact-us` 的请求发送到与 `www.mysite.com` 不同的服务，在**路径**字段中输入 `/contact-us`。通常情况下，你创建的第一条规则不包含路径。
4. 输入每个目标操作的**端口**号。
1. 添加一个**目标服务**。
1. **可选**：如果你想在将请求发送到特定主机名路径时指定工作负载或服务，请为目标添加**路径**。例如，如果你希望将 `www.mysite.com/contact-us` 的请求发送到与 `www.mysite.com` 不同的服务，在**路径**字段中输入 `/contact-us`。通常情况下，你创建的第一条规则不包含路径。
1. 输入每个目标操作的**端口**号。
## 证书

Some files were not shown because too many files have changed in this diff Show More