mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-26 21:18:04 +00:00
Merge branch 'rancher:main' into update-directories
This commit is contained in:
Sunil Singh
@@ -1,25 +0,0 @@
|
||||
---
|
||||
title: Rancher 弃用的功能
|
||||
---
|
||||
|
||||
## Rancher 的弃用策略是什么？
|
||||
|
||||
我们在支持[服务条款](https://rancher.com/support-maintenance-terms)中发布了官方弃用策略。
|
||||
|
||||
## 在哪里可以找到 Rancher 已弃用的功能？
|
||||
|
||||
Rancher 会在 GitHub 上的[发行说明](https://github.com/rancher/rancher/releases)中公布已弃用的功能。请参阅以下补丁版本了解已弃用的功能：
|
||||
|
||||
| 补丁版本 | 发布日期 |
|
||||
|---------------|---------------|
|
||||
| [2.6.0](https://github.com/rancher/rancher/releases/tag/v2.6.0) | 2021 年 8 月 31 日 |
|
||||
| [2.6.1](https://github.com/rancher/rancher/releases/tag/v2.6.1) | 2021 年 10 月 11 日 |
|
||||
| [2.6.2](https://github.com/rancher/rancher/releases/tag/v2.6.2) | 2021 年 10 月 19 日 |
|
||||
| [2.6.3](https://github.com/rancher/rancher/releases/tag/v2.6.3) | 2021 年 12 月 21 日 |
|
||||
| [2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) | 2022 年 3 月 31 日 |
|
||||
| [2.6.5](https://github.com/rancher/rancher/releases/tag/v2.6.5) | 2022 年 5 月 12 日 |
|
||||
| [2.6.6](https://github.com/rancher/rancher/releases/tag/v2.6.6) | 2022 年 6 月 30 日 |
|
||||
|
||||
## 如果某个功能标记为弃用，我要怎么做？
|
||||
|
||||
如果某个发行版将某功能标记为"Deprecated"（已弃用），该功能仍然可用并受支持，从而允许用户按照常规流程进行升级。在升级到该功能被标记为"已删除"的发行版前，用户/管理员应该计划剥离该功能。对于新部署，我们建议不要使用已弃用的功能。
|
||||
@@ -14,12 +14,10 @@ title: Rancher 中已弃用的功能
|
||||
|
||||
Rancher 将在 GitHub 上发布的 Rancher 的[发版说明](https://github.com/rancher/rancher/releases)中发布已弃用的功能。有关已弃用的功能，请参阅以下的补丁版本：
|
||||
|
||||
| Patch 版本 | 发布时间 |
|
||||
| --------------------------------------------------------------- | ------------------ |
|
||||
| [2.8.3](https://github.com/rancher/rancher/releases/tag/v2.8.3) | 2024 年 3 月 28 日 |
|
||||
| [2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2) | 2024 年 2 月 8 日 |
|
||||
| [2.8.1](https://github.com/rancher/rancher/releases/tag/v2.8.1) | 2024 年 1 月 22 日 |
|
||||
| [2.8.0](https://github.com/rancher/rancher/releases/tag/v2.8.0) | 2023 年 12 月 6 日 |
|
||||
| Patch 版本 | 发布时间 |
|
||||
| ----------------------------------------------------------------- | ------------------ |
|
||||
| [2.11.1](https://github.com/rancher/rancher/releases/tag/v2.11.1) | 2024 年 4 月 24 日 |
|
||||
| [2.11.0](https://github.com/rancher/rancher/releases/tag/v2.11.0) | 2024 年 3 月 31 日 |
|
||||
|
||||
## 当一个功能被标记为弃用我可以得到什么样的预期？
|
||||
|
||||
|
||||
+1
-1
@@ -30,7 +30,7 @@ kubeconfig 也可以通过 `--kubeconfig` 标签（详情请参见 https://helm.
|
||||
|
||||
<DeprecationHelm2 />
|
||||
|
||||
如果你使用 Helm 2，请参见 [Helm 2 迁移到 Helm 3 文档](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/)。如果你不能升级到 Helm 3，[Helm 2 升级页面](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md)提供了使用 Helm 2 升级的旧升级指南。
|
||||
如果你使用 Helm 2，请参见 [Helm 2 迁移到 Helm 3 文档](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/)。如果你不能升级到 Helm 3，[Helm 2 升级页面](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md) 提供了使用 Helm 2 升级的旧升级指南。
|
||||
|
||||
### 离线安装：推送镜像到私有镜像仓库
|
||||
|
||||
|
||||
+7
-1
@@ -12,8 +12,9 @@ title: 功能开关
|
||||
|
||||
:::
|
||||
|
||||
以下是 Rancher 中可用的功能开关列表。如果你是从旧 Rancher 版本升级的，你可能会在 Rancher UI 中看到其他功能，例如 `proxy` 或 `dashboard`（均[已中断](/versioned_docs/version-2.5/reference-guides/installation-references/feature-flags.md)）：
|
||||
以下是 Rancher 中可用的功能开关列表。如果你是从旧 Rancher 版本升级的，你可能会在 Rancher UI 中看到其他功能，例如 `proxy` 或 `dashboard`（均[已中断](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.5/reference-guides/installation-references/feature-flags.md)）：
|
||||
|
||||
- `clean-stale-secrets`: Removes stale secrets from the `cattle-impersonation-system` namespace. This slowly cleans up old secrets which are no longer being used by the impersonation system.
|
||||
- `continuous-delivery`：允许从 Fleet 中单独禁用 Fleet GitOps。有关详细信息，请参阅[持续交付](../../../how-to-guides/advanced-user-guides/enable-experimental-features/continuous-delivery.md)。
|
||||
- `fleet`：v2.6 及更高版本的 Rancher 配置框架需要 Fleet。即使你在旧 Rancher 版本中禁用了该标志，该标志也将在升级时自动启用。有关详细信息，请参阅 [Fleet - GitOps at Scale](../../../integrations-in-rancher/fleet/fleet.md)。
|
||||
- `harvester`：管理 Virtualization Management 页面的访问。用户可以在该页面直接导航到 Harvester 集群并访问 Harvester UI。有关详细信息，请参阅 [Harvester 集成](../../../integrations-in-rancher/harvester/overview.md)。
|
||||
@@ -23,12 +24,15 @@ title: 功能开关
|
||||
- `rke1-custom-node-cleanup`：清除已删除的 RKE1 自定义节点。建议你启用此标志，以防止已删除的节点尝试重新加入集群。
|
||||
- `rke2`：启用配置 RKE2 集群。此标志默认启用。
|
||||
- `token-hashing`：启用令牌哈希。启用后，会使用 SHA256 算法对现有 Token 和所有新 Token 进行哈希处理。一旦对 Token 进行哈希处理，就无法撤消操作。此标志在启用后无法禁用。有关详细信息，请参阅 [API 令牌](../../../api/api-tokens.md#令牌哈希)。
|
||||
- `uiextension`: Enables UI extensions. This flag is enabled by default. Enabling or disabling the flag forces the Rancher pod to restart. The first time this flag is set to `true`, it creates a CRD and enables the controllers and endpoints necessary for the feature to work. If set to `false`, it disables the previously mentioned controllers and endpoints. Setting `uiextension` to `false` has no effect on the CRD -- it does not create a CRD if it does not yet exist, nor does it delete the CRD if it already exists.
|
||||
- `unsupported-storage-drivers`：允许启用非默认启用的存储提供程序和卷插件。有关详细信息，请参阅[允许使用不受支持的存储驱动程序](../../../how-to-guides/advanced-user-guides/enable-experimental-features/unsupported-storage-drivers.md)。
|
||||
- `ui-sql-cache`: Enables a SQLite-based cache for UI tables. See [UI Server-Side Pagination](../../../how-to-guides/advanced-user-guides/enable-experimental-features/ui-server-side-pagination.md) for more information.
|
||||
|
||||
下表介绍了 Rancher 中功能开关的可用性和默认值。标记为“GA”的功能已普遍可用：
|
||||
|
||||
| 功能开关名称 | 默认值 | 状态 | 可用于 |
|
||||
| ----------------------------- | ------------- | ------------ | --------------- |
|
||||
| `clean-stale-secrets` | `true` | GA | v2.10.2 | |
|
||||
| `continuous-delivery` | `true` | GA | v2.6.0 |
|
||||
| `fleet` | `true` | 不能禁用 | v2.6.0 |
|
||||
| `fleet` | `true` | GA | v2.5.0 |
|
||||
@@ -37,3 +41,5 @@ title: 功能开关
|
||||
| `rke1-custom-node-cleanup` | `true` | GA | v2.6.0 |
|
||||
| `rke2` | `true` | 实验功能 | v2.6.0 |
|
||||
| `token-hashing` | 新安装：`false`；升级：`true` | GA | v2.6.0 |
|
||||
| `uiextension` | `true` | GA | v2.9.0 | |
|
||||
| `ui-sql-cache` | `false` | Highly experimental | v2.9.0 | |
|
||||
|
||||
+3
-1
@@ -2,6 +2,8 @@
|
||||
title: 在不升级 Rancher 的情况下升级 Kubernetes
|
||||
---
|
||||
|
||||
<EOLRKE1Warning />
|
||||
|
||||
RKE 元数据功能允许你在新版本 Kubernetes 发布后立即为集群配置新版本，而无需升级 Rancher。此功能对于使用 Kubernetes 的补丁版本非常有用，例如，在原本支持 Kubernetes v1.14.6 的 Rancher Server 版本中，将 Kubernetes 升级到 v1.14.7。
|
||||
|
||||
:::note
|
||||
@@ -83,7 +85,7 @@ Rancher Server 会定期刷新 `rke-metadata-config` 来下载新的 Kubernetes
|
||||
要下载私有镜像仓库的系统镜像：
|
||||
|
||||
1. 点击左上角的 **☰**。
|
||||
1. 点击左侧导航底部的**简介**。
|
||||
1. 点击左侧导航底部的Rancher版本号。
|
||||
1. 下载适用于 Linux 或 Windows 操作系统的镜像。
|
||||
1. 下载 `rancher-images.txt`。
|
||||
1. 使用[离线环境安装](other-installation-methods/air-gapped-helm-cli-install/publish-images.md)时使用的步骤准备私有镜像仓库，但不要使用发布页面中的 `rancher-images.txt`，而是使用上一个步骤中获取的文件。
|
||||
|
||||
+3
-5
@@ -23,15 +23,13 @@ title: Rancher Equinix Metal 快速入门
|
||||
|
||||
## 先决条件
|
||||
|
||||
- [Equinix Metal 账号](https://metal.equinix.com/developers/docs/accounts/users/)
|
||||
- [Equinix Metal 项目](https://metal.equinix.com/developers/docs/accounts/projects/)
|
||||
- [Equinix Metal 账号](https://deploy.equinix.com/developers/docs/metal/identity-access-management/users/)
|
||||
- [Equinix Metal 项目](https://deploy.equinix.com/developers/docs/metal/projects/creating-a-project/)
|
||||
|
||||
|
||||
### 1. 配置 Equinix Metal 主机
|
||||
|
||||
开始部署 Equinix Metal 主机。你可以使用 Equinix Metal 控制台、CLI 或 API 来配置 Equinix Metal Server。如果你需要了解每种 Deployment 类型的说明，请参见 [Equinix Metal 部署](https://metal.equinix.com/developers/docs/deploy/on-demand/)。以下链接介绍 Equinix Metal Server 的类型以及价格：
|
||||
- [Equinix Metal Server 类型](https://metal.equinix.com/developers/docs/servers/about/)
|
||||
- [Equinix Metal 价格](https://metal.equinix.com/developers/docs/servers/server-specs/)
|
||||
开始部署 Equinix Metal 主机。你可以使用 Equinix Metal 控制台、CLI 或 API 来配置 Equinix Metal Server。如果你需要了解每种 Deployment 类型的说明，请参见 [Equinix Metal 部署](https://metal.equinix.com/developers/docs/deploy/on-demand/)。You can find additional information on Equinix Metal server types in the [Equinix Metal Documentation](https://deploy.equinix.com/developers/docs/metal/hardware/standard-servers/).
|
||||
|
||||
:::note 注意事项：
|
||||
|
||||
|
||||
+5
-4
@@ -16,12 +16,13 @@ title: Vagrant 快速入门
|
||||
- [Virtualbox](https://www.virtualbox.org)：需要把 Vagrant 配置的虚拟机配置到 VirtualBox。
|
||||
- 至少 4GB 的可用内存。
|
||||
|
||||
### 注意
|
||||
- Vagrant 需要使用插件来创建 VirtualBox 虚拟机。请执行以下命令进行安装：
|
||||
::: 注意
|
||||
|
||||
`vagrant plugin install vagrant-vboxmanage`
|
||||
Vagrant 需要使用插件来创建 VirtualBox 虚拟机。请执行以下命令进行安装：
|
||||
- `vagrant plugin install vagrant-vboxmanage`
|
||||
- `vagrant plugin install vagrant-vbguest`
|
||||
|
||||
`vagrant plugin install vagrant-vbguest`
|
||||
:::
|
||||
|
||||
## 开始使用
|
||||
|
||||
|
||||
+8
@@ -27,6 +27,14 @@ title: 添加项目成员
|
||||
1. 在**成员**选项卡中，单击**添加**。
|
||||
1. 搜索要添加到项目的用户或组。
|
||||
|
||||
:::note Notes:
|
||||
|
||||
- At least 2 characters must be typed in the search box for results to appear.
|
||||
- Users can be searched based on their username or display name.
|
||||
- Search is prefix-based (e.g., a user named `Stan Dard` will appear when searching for `Sta`, but not when searching for `Dar`) and case-sensitive.
|
||||
|
||||
:::
|
||||
|
||||
如果配置了外部身份验证：
|
||||
|
||||
- 在你键入时，Rancher 会从你的外部身份验证源返回用户。
|
||||
|
||||
+3
@@ -6,6 +6,9 @@ title: RKE 模板
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates"/>
|
||||
</head>
|
||||
|
||||
<EOLRKE1Warning />
|
||||
|
||||
|
||||
RKE 模板旨在让 DevOps 和安全团队标准化和简化 Kubernetes 集群创建的流程。
|
||||
|
||||
RKE 的全称是 [Rancher Kubernetes Engine](https://rancher.com/docs/rke/latest/en/)，它是 Rancher 用来配置 Kubernetes 集群的工具。
|
||||
|
||||
+2
@@ -2,6 +2,8 @@
|
||||
title: 创建和修改 RKE 模板
|
||||
---
|
||||
|
||||
<EOLRKE1Warning />
|
||||
|
||||
本节介绍如何管理 RKE 模板和修订版。你可以从 **RKE1 配置 > RKE 模板**下的**集群管理**视图创建、共享、更新和删除模板。
|
||||
|
||||
模板更新通过修订系统处理。当模板所有者想要更改或更新模板时，他们会创建模板的新版本。单个修订无法编辑。但是，如果你想防止使用修订来创建新集群，你可以禁用它。
|
||||
|
||||
+4
-3
@@ -42,14 +42,15 @@ Rancher 认证代理可以与以下外部认证服务集成。
|
||||
|
||||
## 用户和组
|
||||
|
||||
Rancher 依赖用户和组来决定允许谁登录 Rancher 以及他们可以访问哪些资源。当使用外部认证时，外部认证系统会根据用户提供组的信息。这些用户和组被赋予了集群、项目及全局 DNS 提供商和条目等资源的特定角色。当你对组进行授权时，在认证服务中所有属于这个组中的用户都有访问指定的资源的权限。有关角色和权限的更多信息，请查看 [RBAC](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)。
|
||||
|
||||
:::note
|
||||
|
||||
本地认证不支持创建或管理组
|
||||
- Local authentication does not support creating or managing groups.
|
||||
- After an external authentication provider is configured, note that local Rancher scoped administrative users only display resources such as users and groups that they are a member of in the respective authentication provider.
|
||||
|
||||
:::
|
||||
|
||||
Rancher 依赖用户和组来决定允许谁登录 Rancher 以及他们可以访问哪些资源。当使用外部认证时，外部认证系统会根据用户提供组的信息。这些用户和组被赋予了集群、项目及全局 DNS 提供商和条目等资源的特定角色。当你对组进行授权时，在认证服务中所有属于这个组中的用户都有访问指定的资源的权限。有关角色和权限的更多信息，请查看 [RBAC](../manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)。
|
||||
|
||||
更多信息，请查看[用户和组](manage-users-and-groups.md)
|
||||
|
||||
## Rancher 授权范围
|
||||
|
||||
+97
-75
@@ -13,55 +13,88 @@ description: 创建 Keycloak OpenID Connect (OIDC) 客户端并配置 Rancher
|
||||
|
||||
- 已在 Rancher 上禁用 Keycloak (SAML)。
|
||||
- 你必须配置了 [Keycloak IdP 服务器](https://www.keycloak.org/guides#getting-started)。
|
||||
- 在 Keycloak 中，使用以下设置创建一个[新的 OIDC 客户端](https://www.keycloak.org/docs/latest/server_admin/#oidc-clients)。如需获取帮助，请参见 [Keycloak 文档](https://www.keycloak.org/docs/latest/server_admin/#oidc-clients)。
|
||||
- Follow the [Keycloak documentation](https://www.keycloak.org/docs/latest/server_admin/#proc-creating-oidc-client_server_administration_guide) to create a new OIDC client with the settings below.
|
||||
|
||||
| 设置 | 值 |
|
||||
------------|------------
|
||||
| `Client ID` | <CLIENT_ID> (例如 `rancher`) |
|
||||
| `Name` | <CLIENT_NAME> (例如 `rancher`) |
|
||||
| `Client Protocol` | `openid-connect` |
|
||||
| `Access Type` | `confidential` |
|
||||
| `Valid Redirect URI` | `https://yourRancherHostURL/verify-auth` |
|
||||
| 设置 | 值 |
|
||||
|------------|------------|
|
||||
| `Client ID` | <client-id> (例如 `rancher`) |
|
||||
| `Name` | <client-name> (例如 `rancher`) |
|
||||
| `Client type` | `OpenID Connect` |
|
||||
| `Client authentication` | `ON` |
|
||||
| `Valid Redirect URI` | `https://yourRancherHostURL/verify-auth` |
|
||||
|
||||
- 在新的 OIDC 客户端中，创建 [Mappers](https://www.keycloak.org/docs/latest/server_admin/#_protocol-mappers) 来公开用户字段。
|
||||
- 使用以下设置创建一个新的 "Groups Mapper"：
|
||||
1. In the navigation menu, click **Clients**.
|
||||
1. Click the **Clients list** tab.
|
||||
1. Find and click the client you created.
|
||||
1. Click the **Client scopes** tab.
|
||||
1. Find and click the link labeled `<client-name>-dedicated`. For example, if you named your client `rancher`, look for the link named `rancher-dedicated`.
|
||||
1. Click the **Mappers** tab.
|
||||
1. Click **Configure a new mapper**. If you already have existing mappers configured, click the arrow next to **Add mapper** and select **By configuration**. Repeat this process and create these mappers:
|
||||
- From the mappings table, select **Group Membership** and configure a new "Groups Mapper" with the settings below. For settings that are not mentioned, use the default value.
|
||||
|
||||
| 设置 | 值 |
|
||||
------------|------------
|
||||
| `Name` | `Groups Mapper` |
|
||||
| `Mapper Type` | `Group Membership` |
|
||||
| `Token Claim Name` | `groups` |
|
||||
| `Full group path` | `OFF` |
|
||||
| `Add to ID token` | `OFF` |
|
||||
| `Add to access token` | `OFF` |
|
||||
| `Add to user info` | `ON` |
|
||||
| Setting | Value |
|
||||
| ------------|------------|
|
||||
| `Name` | `Groups Mapper` |
|
||||
| `Mapper Type` | `Group Membership` |
|
||||
| `Token Claim Name` | `groups` |
|
||||
| `Full group path` | `OFF` |
|
||||
| `Add to ID token` | `OFF` |
|
||||
| `Add to access token` | `OFF` |
|
||||
| `Add to user info` | `ON` |
|
||||
|
||||
- 使用以下设置创建一个新的 "Client Audience" ：
|
||||
- From the mappings table, select **Audience** and configure a new "Client Audience" with the settings below. For settings that are not mentioned, use the default value.
|
||||
|
||||
| 设置 | 值 |
|
||||
------------|------------
|
||||
| `Name` | `Client Audience` |
|
||||
| `Mapper Type` | `Audience` |
|
||||
| `Included Client Audience` | <CLIENT_NAME> |
|
||||
| `Add to ID token` | `OFF` |
|
||||
| `Add to access token` | `ON` |
|
||||
| Setting | Value |
|
||||
| ------------|------------|
|
||||
| `Name` | `Client Audience` |
|
||||
| `Mapper Type` | `Audience` |
|
||||
| `Included Client Audience` | <client-name> |
|
||||
| `Add to ID token` | `OFF` |
|
||||
| `Add to access token` | `ON` |
|
||||
|
||||
- 使用以下设置创建一个新的 "Groups Path"：
|
||||
- From the mappings table, select **Group Membership** and configure a new "Groups Path" with the settings below. For settings that are not mentioned, use the default value.
|
||||
|
||||
| 设置 | 值 |
|
||||
------------|------------
|
||||
| `Name` | `Group Path` |
|
||||
| `Mapper Type` | `Group Membership` |
|
||||
| `Token Claim Name` | `full_group_path` |
|
||||
| `Full group path` | `ON` |
|
||||
| `Add to ID token` | `ON` |
|
||||
| `Add to access token` | `ON` |
|
||||
| `Add to user info` | `ON` |
|
||||
| Setting | Value |
|
||||
| ------------|------------|
|
||||
| `Name` | `Group Path` |
|
||||
| `Mapper Type` | `Group Membership` |
|
||||
| `Token Claim Name` | `full_group_path` |
|
||||
| `Full group path` | `ON` |
|
||||
| `Add to ID token` | `ON` |
|
||||
| `Add to access token` | `ON` |
|
||||
| `Add to user info` | `ON` |
|
||||
|
||||
- Go to **Role Mappings > Client Roles > realm-management** and add the following Role Mappings to all users or groups that need to query the Keycloak users.
|
||||
- query-users
|
||||
- query-groups
|
||||
- view-users
|
||||
- Add the following role mappings to all users or groups that need to query the Keycloak users.
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="Users">
|
||||
|
||||
1. In the navigation menu, click **Users**.
|
||||
1. Click the user you want to add role mappings to.
|
||||
1. Click the **Role mapping** tab.
|
||||
1. Click **Assign role**.
|
||||
1. Select the following roles:
|
||||
- query-users
|
||||
- query-groups
|
||||
- view-users
|
||||
1. Click **Assign**.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Groups">
|
||||
|
||||
1. In the navigation menu, click **Groups**.
|
||||
1. Click the group you want to add role mappings to.
|
||||
1. Click the **Role mapping** tab.
|
||||
1. Click **Assign role**.
|
||||
1. Select the following roles:
|
||||
- query-users
|
||||
- query-groups
|
||||
- view-users
|
||||
1. Click **Assign**.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## 在 Rancher 中配置 Keycloak
|
||||
|
||||
@@ -69,15 +102,22 @@ description: 创建 Keycloak OpenID Connect (OIDC) 客户端并配置 Rancher
|
||||
1. 单击左侧导航栏的**认证**。
|
||||
1. 选择 **Keycloak (OIDC)**。
|
||||
1. 填写**配置 Keycloak OIDC 账号**表单。有关填写表单的帮助，请参见[配置参考](#配置参考)。
|
||||
|
||||
:::note
|
||||
|
||||
When configuring the **Endpoints** section using the **Generate** option, Rancher includes `/auth` as part of the context path in the **Issuer** and **Auth Endpoint** fields, which is only valid for Keycloak 16 or older. You must configure endpoints using the **Specify** option for [Keycloak 17](https://www.keycloak.org/docs/latest/release_notes/index.html#keycloak-17-0-0) and newer, which have [migrated to Quarkus](https://www.keycloak.org/migration/migrating-to-quarkus).
|
||||
|
||||
:::
|
||||
|
||||
1. 完成**配置 Keycloak OIDC 账号**表单后，单击**启用**。
|
||||
|
||||
Rancher 会将你重定向到 IdP 登录页面。输入使用 Keycloak IdP 进行身份验证的凭证，来验证你的 Rancher Keycloak 配置。
|
||||
Rancher 会将你重定向到 IdP 登录页面。输入使用 Keycloak IdP 进行身份验证的凭证，来验证你的 Rancher Keycloak 配置。
|
||||
|
||||
:::note
|
||||
:::note
|
||||
|
||||
你可能需要禁用弹出窗口阻止程序才能看到 IdP 登录页面。
|
||||
你可能需要禁用弹出窗口阻止程序才能看到 IdP 登录页面。
|
||||
|
||||
:::
|
||||
:::
|
||||
|
||||
**结果**：已将 Rancher 配置为使用 OIDC 协议与 Keycloak 一起工作。你的用户现在可以使用 Keycloak 登录名登录 Rancher。
|
||||
|
||||
@@ -99,35 +139,17 @@ description: 创建 Keycloak OpenID Connect (OIDC) 客户端并配置 Rancher
|
||||
|
||||
本节描述了将使用 Keycloak (SAML) 的 Rancher 过渡到 Keycloak (OIDC) 的过程。
|
||||
|
||||
### 重新配置 Keycloak
|
||||
1. Reconfigure Keycloak.
|
||||
1. Configure a new `OpenID Connect` client according to the [Prerequisites](#先决条件). Ensure the same `Valid Redirect URIs` are set.
|
||||
1. Configure mappers for the new client according to the [Prerequisites](#先决条件).
|
||||
1. Before configuring Rancher to use Keycloak (OIDC), Keycloak (SAML) must be first disabled.
|
||||
1. In the Rancher UI, click **☰ > Users & Authentication**.
|
||||
1. In the left navigation bar, click **Auth Provider**.
|
||||
1. Select **Keycloak (SAML)**.
|
||||
1. Click **Disable**.
|
||||
1. Follow the steps in [Configuring Keycloak in Rancher](#在-rancher-中配置-keycloak).
|
||||
|
||||
1. 将现有客户端更改为使用 OIDC 协议。在 Keycloak 控制台中，单击 **Clients**，选择要迁移的 SAML 客户端，选择 **Settings** 选项卡，将 `Client Protocol` 从 `saml` 更改为 `openid-connect`，然后点击 **Save**。
|
||||
|
||||
1. 验证 `Valid Redirect URIs` 是否仍然有效。
|
||||
|
||||
1. 选择 **Mappers** 选项卡并使用以下设置创建一个新的 Mapper：
|
||||
|
||||
| 设置 | 值 |
|
||||
------------|------------
|
||||
| `Name` | `Groups Mapper` |
|
||||
| `Mapper Type` | `Group Membership` |
|
||||
| `Token Claim Name` | `groups` |
|
||||
| `Add to ID token` | `ON` |
|
||||
| `Add to access token` | `ON` |
|
||||
| `Add to user info` | `ON` |
|
||||
|
||||
### 重新配置 Rancher
|
||||
|
||||
在将 Rancher 配置为使用 Keycloak (OIDC) 之前，必须先禁用 Keycloak (SAML)：
|
||||
|
||||
1. 在 Rancher UI 中，单击 **☰ > 用户 & 认证**。
|
||||
1. 单击左侧导航栏的**认证**。
|
||||
1. 选择 **Keycloak (SAML)**。
|
||||
1. 单击**禁用**。
|
||||
|
||||
按照[本节](#在-rancher-中配置-keycloak)中的步骤将 Rancher 配置为使用 Keycloak (OIDC)。
|
||||
|
||||
:::note
|
||||
:::caution
|
||||
|
||||
配置完成后，由于用户权限不会自动迁移，你需要重新申请 Rancher 用户权限。
|
||||
|
||||
@@ -143,12 +165,12 @@ description: 创建 Keycloak OpenID Connect (OIDC) 客户端并配置 Rancher
|
||||
|
||||
完成**配置 Keycloak OIDC 账号**表单并单击**启用**后，你没有被重定向到你的 IdP。
|
||||
|
||||
* 验证你的 Keycloak 客户端配置。
|
||||
验证你的 Keycloak 客户端配置。
|
||||
|
||||
### 生成的 `Issuer` 和 `Auth 端点`不正确
|
||||
|
||||
* 在**配置 Keycloak OIDC 账号**表单中，将**端点**更改为`指定（高级设置）`并覆盖`发行者` 和 `Auth 端点`的值。要查找这些值，前往 Keycloak 控制台并选择 **Realm Settings**，选择 **General** 选项卡，然后单击 **OpenID Endpoint Configuration**。JSON 输出将显示 `issuer` 和 `authorization_endpoint` 的值。
|
||||
在**配置 Keycloak OIDC 账号**表单中，将**端点**更改为`指定（高级设置）`并覆盖`发行者` 和 `Auth 端点`的值。要查找这些值，前往 Keycloak 控制台并选择 **Realm Settings**，选择 **General** 选项卡，然后单击 **OpenID Endpoint Configuration**。JSON 输出将显示 `issuer` 和 `authorization_endpoint` 的值。
|
||||
|
||||
### Keycloak 错误："Invalid grant_type"
|
||||
|
||||
* 在某些情况下，这条错误提示信息可能有误导性，实际上造成错误的原因是 `Valid Redirect URI` 配置错误。
|
||||
在某些情况下，这条错误提示信息可能有误导性，实际上造成错误的原因是 `Valid Redirect URI` 配置错误。
|
||||
|
||||
+4
@@ -4,6 +4,10 @@ title: Pod 安全准入 (PSA) 配置模板
|
||||
|
||||
[Pod Security admission (PSA)](./pod-security-standards.md) 配置模板是 Rancher 自定义资源 (CRD)，在 Rancher v2.7.2 及更高版本中可用。这些模板提供了可应用于集群的预定义安全配置：
|
||||
|
||||
:::info important
|
||||
The policies shipped by default in Rancher aim to provide a trade-off between security and convenience. If a more strict policy configuration is needed, users are able to craft such policies themselves based on their specific requirements. In the case Rancher policies are preferred, you will need to deploy admission controllers that block the creation of any [exempted namespaces](#豁免必须的-rancher-命名空间) that won't be used within your environments.
|
||||
:::
|
||||
|
||||
- `rancher-privileged`：最宽松的配置。它不限制任何 Pod 行为，允许已知的权限升级。该策略没有豁免。
|
||||
- `rancher-restricted`：严格限制的配置，遵循当前加固 pod 的最佳实践。你必须对 Rancher 组件进行[命名空间级别豁免](./pod-security-standards.md#受-psa-限制的集群上的-rancher)。
|
||||
|
||||
|
||||
+2
-2
@@ -48,10 +48,10 @@ Rancher 可以安装到任意 Kubernetes 集群上，包括托管的 Kubernetes
|
||||
|
||||
以上假设你的环境具有到 Docker Hub 的出站连接。
|
||||
|
||||
对于**离线环境**，在安装 rancher-backup Helm Chart 时，使用下面的 Helm 值从你的私有镜像仓库中拉取 `backup-restore-operator` 镜像。
|
||||
对于**离线环境**，在安装 rancher-backup Helm Chart 时，使用下面的 Helm 值从你的私有镜像仓库中拉取 `backup-restore-operator` 和 `kubectl` 镜像。
|
||||
|
||||
```bash
|
||||
--set image.repository $REGISTRY/rancher/backup-restore-operator
|
||||
--set image.repository <registry>/rancher/backup-restore-operator --set global.kubectl.repository=<registry>/rancher/kubectl
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
+2
@@ -2,6 +2,8 @@
|
||||
title: 为高可用 RKE Kubernetes 集群设置基础设施
|
||||
---
|
||||
|
||||
<EOLRKE1Warning />
|
||||
|
||||
本教程旨在帮助你创建一个高可用的 RKE 集群，用于安装 Rancher Server。
|
||||
|
||||
:::note 重要提示：
|
||||
|
||||
+2
@@ -2,6 +2,8 @@
|
||||
title: 配置高可用的 RKE Kubernetes 集群
|
||||
---
|
||||
|
||||
<EOLRKE1Warning />
|
||||
|
||||
本文介绍如何安装 Kubernetes 集群。该集群应专用于运行 Rancher Server。
|
||||
|
||||
:::note
|
||||
|
||||
+434
@@ -109,3 +109,437 @@ Azure 订阅不支持以下账号类型：
|
||||
1. 在**集群配置 > 高级选项**、中，单击**补充的 Controller Manager 参数**下的**添加**，并添加 `--configure-cloud-routes=false` 标志。
|
||||
|
||||
1. 单击**创建**按钮来提交表单并创建集群。
|
||||
|
||||
## Cloud Provider Configuration
|
||||
|
||||
Rancher automatically creates a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you will need to specify them before creating the cluster. You can check **RKE1 Node Templates** or **RKE2 Machine Pools** to view or edit these automatically generated names.
|
||||
|
||||
**Refer to the full list of configuration options in the [upstream docs](https://cloud-provider-azure.sigs.k8s.io/install/configs/).**
|
||||
|
||||
:::note
|
||||
1. `useInstanceMetadata` must be set to `true` for the cloud provider to correctly configure `providerID`.
|
||||
2. `excludeMasterFromStandardLB` must be set to `false` if you need to add nodes labeled `node-role.kubernetes.io/master` to the backend of the Azure Load Balancer (ALB).
|
||||
3. `loadBalancerSku` can be set to `basic` or `standard`. Basic SKU will be deprecated in September 2025. Refer to the [Azure upstream docs](https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/public-ip-basic-upgrade-guidance#basic-sku-vs-standard-sku) for more information.
|
||||
:::
|
||||
|
||||
Azure supports reading the cloud config from Kubernetes secrets. The secret is a serialized version of the azure.json file. When the secret is changed, the cloud controller manager reconstructs itself without restarting the pod. It is recommended for the Helm chart to read the Cloud Provider Config from the secret.
|
||||
|
||||
Note that the chart reads the Cloud Provider Config from a given secret name in the `kube-system` namespace. Since Azure reads Kubernetes secrets, RBAC also needs to be configured. An example secret for the Cloud Provider Config is shown below. Modify it as needed and create the secret.
|
||||
|
||||
```yaml
|
||||
# azure-cloud-config.yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: azure-cloud-config
|
||||
namespace: kube-system
|
||||
type: Opaque
|
||||
stringData:
|
||||
cloud-config: |-
|
||||
{
|
||||
"cloud": "AzurePublicCloud",
|
||||
"tenantId": "<tenant-id>",
|
||||
"subscriptionId": "<subscription-id>",
|
||||
"aadClientId": "<client-id>",
|
||||
"aadClientSecret": "<tenant-id>",
|
||||
"resourceGroup": "docker-machine",
|
||||
"location": "westus",
|
||||
"subnetName": "docker-machine",
|
||||
"securityGroupName": "rancher-managed-kqmtsjgJ",
|
||||
"securityGroupResourceGroup": "docker-machine",
|
||||
"vnetName": "docker-machine-vnet",
|
||||
"vnetResourceGroup": "docker-machine",
|
||||
"primaryAvailabilitySetName": "docker-machine",
|
||||
"routeTableResourceGroup": "docker-machine",
|
||||
"cloudProviderBackoff": false,
|
||||
"useManagedIdentityExtension": false,
|
||||
"useInstanceMetadata": true,
|
||||
"loadBalancerSku": "standard",
|
||||
"excludeMasterFromStandardLB": false,
|
||||
}
|
||||
```
|
||||
|
||||
## Using the Out-of-tree Azure Cloud Provider
|
||||
|
||||
<Tabs groupId="k8s-distro">
|
||||
<TabItem value="RKE2">
|
||||
|
||||
1. Select **External** from the **Cloud Provider** drop-down in the **Cluster Configuration** section.
|
||||
|
||||
2. Under **Cluster Configuration > Advanced**, click **Add** under **Additional Controller Manager Args** and add this flag: `--configure-cloud-routes=false`.
|
||||
|
||||
3. Prepare the Cloud Provider Configuration to set it in the next step. Note that Rancher automatically creates a new Network Security Group, Resource Group, Availability Set, Subnet, and Virtual Network. If you already have some or all of these created, you must specify them before creating the cluster.
|
||||
|
||||
Click **Show Advanced** to view or edit these automatically generated names. Your Cloud Provider Configuration **must** match the fields in the **Machine Pools** section. If you have multiple pools, they must all use the same Resource Group, Availability Set, Subnet, Virtual Network, and Network Security Group.
|
||||
|
||||
4. Under **Cluster Configuration > Add-on Config**, add the cloud controller manager manifest shown below into **Additional Manifest**.
|
||||
Note that this chart reads the Cloud Provider Config from the secret in the `kube-system` namespace. An example secret for the Cloud Provider Config is shown below; modify it as needed. Refer to the full list of configuration options in the [upstream docs](https://cloud-provider-azure.sigs.k8s.io/install/configs/).
|
||||
|
||||
Alternatively, you can also install the cloud controller manager using the [Helm CLI](#helm-chart-installation-from-cli).
|
||||
|
||||
```yaml
|
||||
apiVersion: helm.cattle.io/v1
|
||||
kind: HelmChart
|
||||
metadata:
|
||||
name: azure-cloud-controller-manager
|
||||
namespace: kube-system
|
||||
spec:
|
||||
chart: cloud-provider-azure
|
||||
repo: https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo
|
||||
targetNamespace: kube-system
|
||||
bootstrap: true
|
||||
valuesContent: |-
|
||||
infra:
|
||||
clusterName: <cluster-name>
|
||||
cloudControllerManager:
|
||||
cloudConfigSecretName: azure-cloud-config
|
||||
cloudConfig: null
|
||||
clusterCIDR: null
|
||||
enableDynamicReloading: 'true'
|
||||
nodeSelector:
|
||||
node-role.kubernetes.io/control-plane: 'true'
|
||||
allocateNodeCidrs: 'false'
|
||||
hostNetworking: true
|
||||
caCertDir: /etc/ssl
|
||||
configureCloudRoutes: 'false'
|
||||
enabled: true
|
||||
tolerations:
|
||||
- effect: NoSchedule
|
||||
key: node-role.kubernetes.io/master
|
||||
- effect: NoSchedule
|
||||
key: node-role.kubernetes.io/control-plane
|
||||
value: 'true'
|
||||
- effect: NoSchedule
|
||||
key: node.cloudprovider.kubernetes.io/uninitialized
|
||||
value: 'true'
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: azure-cloud-config
|
||||
namespace: kube-system
|
||||
type: Opaque
|
||||
stringData:
|
||||
cloud-config: |-
|
||||
{
|
||||
"cloud": "AzurePublicCloud",
|
||||
"tenantId": "<tenant-id>",
|
||||
"subscriptionId": "<subscription-id>",
|
||||
"aadClientId": "<client-id>",
|
||||
"aadClientSecret": "<tenant-id>",
|
||||
"resourceGroup": "docker-machine",
|
||||
"location": "westus",
|
||||
"subnetName": "docker-machine",
|
||||
"securityGroupName": "rancher-managed-kqmtsjgJ",
|
||||
"securityGroupResourceGroup": "docker-machine",
|
||||
"vnetName": "docker-machine-vnet",
|
||||
"vnetResourceGroup": "docker-machine",
|
||||
"primaryAvailabilitySetName": "docker-machine",
|
||||
"routeTableResourceGroup": "docker-machine",
|
||||
"cloudProviderBackoff": false,
|
||||
"useManagedIdentityExtension": false,
|
||||
"useInstanceMetadata": true,
|
||||
"loadBalancerSku": "standard",
|
||||
"excludeMasterFromStandardLB": false,
|
||||
}
|
||||
```
|
||||
|
||||
5. Click **Create** to submit the form and create the cluster.
|
||||
|
||||
</TabItem>
|
||||
|
||||
<TabItem value="RKE1">
|
||||
|
||||
1. Choose **External** from the **Cloud Provider** drop-down in the **Cluster Options** section. This sets `--cloud-provider=external` for Kubernetes components.
|
||||
|
||||
2. Install the `cloud-provider-azure` chart after the cluster finishes provisioning. Note that the cluster is not successfully provisioned and nodes are still in an `uninitialized` state until you deploy the cloud controller manager. This can be done [manually using CLI](#helm-chart-installation-from-cli), or via [Helm charts in UI](#helm-chart-installation-from-ui).
|
||||
|
||||
Refer to the [official Azure upstream documentation](https://cloud-provider-azure.sigs.k8s.io/install/azure-ccm/) for more details on deploying the Cloud Controller Manager.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### Helm Chart Installation from CLI
|
||||
|
||||
Official upstream docs for [Helm chart installation](https://github.com/kubernetes-sigs/cloud-provider-azure/tree/master/helm/cloud-provider-azure) can be found on Github.
|
||||
|
||||
1. Create a `azure-cloud-config` secret with the required [cloud provider config](#cloud-provider-configuration).
|
||||
|
||||
```shell
|
||||
kubectl apply -f azure-cloud-config.yaml
|
||||
```
|
||||
|
||||
2. Add the Helm repository:
|
||||
|
||||
```shell
|
||||
helm repo add azure-cloud-controller-manager https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo
|
||||
helm repo update
|
||||
```
|
||||
|
||||
3. Create a `values.yaml` file with the following contents to override the default `values.yaml`:
|
||||
|
||||
<Tabs groupId="k8s-distro">
|
||||
<TabItem value="RKE2">
|
||||
|
||||
```yaml
|
||||
# values.yaml
|
||||
infra:
|
||||
clusterName: <cluster-name>
|
||||
cloudControllerManager:
|
||||
cloudConfigSecretName: azure-cloud-config
|
||||
cloudConfig: null
|
||||
clusterCIDR: null
|
||||
enableDynamicReloading: 'true'
|
||||
configureCloudRoutes: 'false'
|
||||
allocateNodeCidrs: 'false'
|
||||
caCertDir: /etc/ssl
|
||||
enabled: true
|
||||
replicas: 1
|
||||
hostNetworking: true
|
||||
nodeSelector:
|
||||
node-role.kubernetes.io/control-plane: 'true'
|
||||
tolerations:
|
||||
- effect: NoSchedule
|
||||
key: node-role.kubernetes.io/master
|
||||
- effect: NoSchedule
|
||||
key: node-role.kubernetes.io/control-plane
|
||||
value: 'true'
|
||||
- effect: NoSchedule
|
||||
key: node.cloudprovider.kubernetes.io/uninitialized
|
||||
value: 'true'
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
|
||||
<TabItem value="RKE">
|
||||
|
||||
```yaml
|
||||
# values.yaml
|
||||
cloudControllerManager:
|
||||
cloudConfigSecretName: azure-cloud-config
|
||||
cloudConfig: null
|
||||
clusterCIDR: null
|
||||
enableDynamicReloading: 'true'
|
||||
configureCloudRoutes: 'false'
|
||||
allocateNodeCidrs: 'false'
|
||||
caCertDir: /etc/ssl
|
||||
enabled: true
|
||||
replicas: 1
|
||||
hostNetworking: true
|
||||
nodeSelector:
|
||||
node-role.kubernetes.io/controlplane: 'true'
|
||||
node-role.kubernetes.io/control-plane: null
|
||||
tolerations:
|
||||
- effect: NoSchedule
|
||||
key: node-role.kubernetes.io/controlplane
|
||||
value: 'true'
|
||||
- effect: NoSchedule
|
||||
key: node.cloudprovider.kubernetes.io/uninitialized
|
||||
value: 'true'
|
||||
infra:
|
||||
clusterName: <cluster-name>
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
4. Install the Helm chart:
|
||||
|
||||
```shell
|
||||
helm upgrade --install cloud-provider-azure azure-cloud-controller-manager/cloud-provider-azure -n kube-system --values values.yaml
|
||||
```
|
||||
|
||||
Verify that the Helm chart installed successfully:
|
||||
|
||||
```shell
|
||||
helm status cloud-provider-azure -n kube-system
|
||||
```
|
||||
|
||||
5. (Optional) Verify that the cloud controller manager update succeeded:
|
||||
|
||||
```shell
|
||||
kubectl rollout status deployment -n kube-system cloud-controller-manager
|
||||
kubectl rollout status daemonset -n kube-system cloud-node-manager
|
||||
```
|
||||
|
||||
6. The cloud provider is responsible for setting the ProviderID of the node. Check if all nodes are initialized with the ProviderID:
|
||||
|
||||
```shell
|
||||
kubectl describe nodes | grep "ProviderID"
|
||||
```
|
||||
|
||||
### Helm Chart Installation from UI
|
||||
|
||||
1. Click **☰**, then select the name of the cluster from the left navigation.
|
||||
|
||||
2. Select **Apps** > **Repositories**.
|
||||
|
||||
3. Click the **Create** button.
|
||||
|
||||
4. Enter `https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo` in the **Index URL** field.
|
||||
|
||||
5. Select **Apps** > **Charts** from the left navigation and install **cloud-provider-azure** chart.
|
||||
|
||||
6. Select the namespace, `kube-system`, and enable **Customize Helm options before install**.
|
||||
|
||||
7. Replace `cloudConfig: /etc/kubernetes/azure.json` to read from the Cloud Config Secret and enable dynamic reloading:
|
||||
|
||||
```yaml
|
||||
cloudConfigSecretName: azure-cloud-config
|
||||
enableDynamicReloading: 'true'
|
||||
```
|
||||
|
||||
8. Update the following fields as required:
|
||||
|
||||
```yaml
|
||||
allocateNodeCidrs: 'false'
|
||||
configureCloudRoutes: 'false'
|
||||
clusterCIDR: null
|
||||
```
|
||||
|
||||
<Tabs groupId="k8s-distro">
|
||||
<TabItem value="RKE2">
|
||||
|
||||
9. Rancher-provisioned RKE2 nodes have the selector `node-role.kubernetes.io/control-plane` set to `true`. Update the nodeSelector:
|
||||
```yaml
|
||||
nodeSelector:
|
||||
node-role.kubernetes.io/control-plane: 'true'
|
||||
```
|
||||
</TabItem>
|
||||
|
||||
<TabItem value="RKE">
|
||||
|
||||
10. Rancher-provisioned RKE nodes are tainted `node-role.kubernetes.io/controlplane`. Update tolerations and the nodeSelector:
|
||||
|
||||
```yaml
|
||||
tolerations:
|
||||
- effect: NoSchedule
|
||||
key: node.cloudprovider.kubernetes.io/uninitialized
|
||||
value: 'true'
|
||||
- effect: NoSchedule
|
||||
value: 'true'
|
||||
key: node-role.kubernetes.io/controlplane
|
||||
```
|
||||
|
||||
```yaml
|
||||
nodeSelector:
|
||||
node-role.kubernetes.io/controlplane: 'true'
|
||||
```
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
11. Install the chart and confirm that the cloud controller and cloud node manager deployed successfully:
|
||||
|
||||
```shell
|
||||
kubectl rollout status deployment -n kube-system cloud-controller-manager
|
||||
kubectl rollout status daemonset -n kube-system cloud-node-manager
|
||||
```
|
||||
|
||||
12. The cloud provider is responsible for setting the ProviderID of the node. Check if all nodes are initialized with the ProviderID:
|
||||
|
||||
```shell
|
||||
kubectl describe nodes | grep "ProviderID"
|
||||
```
|
||||
|
||||
### Installing CSI Drivers
|
||||
|
||||
Install [Azure Disk CSI driver](https://github.com/kubernetes-sigs/azuredisk-csi-driver) or [Azure File CSI Driver](https://github.com/kubernetes-sigs/azurefile-csi-driver) to access [Azure Disk](https://azure.microsoft.com/en-us/services/storage/disks/) or [Azure File](https://azure.microsoft.com/en-us/services/storage/disks/) volumes respectively.
|
||||
|
||||
The steps to install the Azure Disk CSI driver are shown below. You can install the Azure File CSI Driver in a similar manner by following the [helm installation documentation](https://github.com/kubernetes-sigs/azurefile-csi-driver/blob/master/charts/README.md).
|
||||
|
||||
::: note Important:
|
||||
|
||||
Clusters must be provisioned using `Managed Disk` to use Azure Disk. You can configure this when creating **RKE1 Node Templates** or **RKE2 Machine Pools*.
|
||||
|
||||
:::
|
||||
|
||||
Official upstream docs for [Helm chart installation](https://github.com/kubernetes-sigs/azuredisk-csi-driver/blob/master/charts/README.md) can be found on Github.
|
||||
|
||||
1. Add and update the helm repository:
|
||||
|
||||
```shell
|
||||
helm repo add azuredisk-csi-driver https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/charts
|
||||
helm repo update azuredisk-csi-driver
|
||||
```
|
||||
|
||||
1. Install the chart as shown below, updating the --version argument as needed. Refer to the full list of latest chart configurations in the [upstream docs](https://github.com/kubernetes-sigs/azuredisk-csi-driver/blob/master/charts/README.md#latest-chart-configuration).
|
||||
|
||||
```shell
|
||||
helm install azuredisk-csi-driver azuredisk-csi-driver/azuredisk-csi-driver --namespace kube-system --version v1.30.1 --set controller.cloudConfigSecretName=azure-cloud-config --set controller.cloudConfigSecretNamespace=kube-system --set controller.runOnControlPlane=true
|
||||
```
|
||||
|
||||
2. (Optional) Verify that the azuredisk-csi-driver installation succeeded:
|
||||
|
||||
```shell
|
||||
kubectl --namespace=kube-system get pods --selector="app.kubernetes.io/name=azuredisk-csi-driver" --watch
|
||||
```
|
||||
|
||||
3. Provision an example Storage Class:
|
||||
|
||||
```shell
|
||||
cat <<EOF | kubectl create -f -
|
||||
kind: StorageClass
|
||||
apiVersion: storage.k8s.io/v1
|
||||
metadata:
|
||||
name: standard
|
||||
provisioner: kubernetes.io/azure-disk
|
||||
parameters:
|
||||
storageaccounttype: Standard_LRS
|
||||
kind: Managed
|
||||
EOF
|
||||
```
|
||||
|
||||
Verify that the storage class has been provisioned:
|
||||
```shell
|
||||
kubectl get storageclasses
|
||||
```
|
||||
|
||||
4. Create a PersistentVolumeClaim:
|
||||
```shell
|
||||
cat <<EOF | kubectl create -f -
|
||||
kind: PersistentVolumeClaim
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
name: azure-disk-pvc
|
||||
spec:
|
||||
storageClassName: standard
|
||||
accessModes:
|
||||
- ReadWriteOnce
|
||||
resources:
|
||||
requests:
|
||||
storage: 5Gi
|
||||
EOF
|
||||
```
|
||||
|
||||
Verify that the PersistentVolumeClaim and PersistentVolume have been created:
|
||||
```shell
|
||||
kubectl get persistentvolumeclaim
|
||||
kubectl get persistentvolume
|
||||
```
|
||||
|
||||
5. Attach the new Azure Disk:
|
||||
|
||||
You can now mount the Kubernetes PersistentVolume into a Kubernetes Pod. The disk can be consumed by any Kubernetes object type, including a Deployment, DaemonSet, or StatefulSet. However, the following example simply mounts the PersistentVolume into a standalone Pod.
|
||||
|
||||
```shell
|
||||
cat <<EOF | kubectl create -f -
|
||||
kind: Pod
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
name: mypod-dynamic-azuredisk
|
||||
spec:
|
||||
containers:
|
||||
- name: mypod
|
||||
image: nginx
|
||||
ports:
|
||||
- containerPort: 80
|
||||
name: "http-server"
|
||||
volumeMounts:
|
||||
- mountPath: "/usr/share/nginx/html"
|
||||
name: storage
|
||||
volumes:
|
||||
- name: storage
|
||||
persistentVolumeClaim:
|
||||
claimName: azure-disk-pvc
|
||||
EOF
|
||||
```
|
||||
|
||||
+2
@@ -2,6 +2,8 @@
|
||||
title: RKE1 和 RKE2 差异
|
||||
---
|
||||
|
||||
<EOLRKE1Warning />
|
||||
|
||||
RKE2，也称为 RKE Government，是一个完全符合标准的 Kubernetes 发行版，它专注于安全性和合规性。它被认为是 Rancher Kubernetes Engine（即 RKE1）的下一个迭代。
|
||||
|
||||
RKE1 和 RKE2 有一些细微的差异，本文将重点介绍这些差异。
|
||||
|
||||
+2
-2
@@ -31,7 +31,7 @@ Linux 和 Windows 虚拟机都需要特定工具才能供 vSphere 主机驱动
|
||||
* cloud-init
|
||||
* cloud-guest-utils
|
||||
* cloud-image-utils
|
||||
* growpart
|
||||
* growpart (part of cloud-guest-utils)
|
||||
* cloud-initramfs-growroot
|
||||
* open-iscsi
|
||||
* openssh-server
|
||||
@@ -129,7 +129,7 @@ cloud-init clean -s -l
|
||||
|
||||
### Windows 准备
|
||||
|
||||
Windows 有一个名为 [sysprep](https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/sysprep--generalize--a-windows-installation) 的实用程序，用于一般化镜像并重置上述 Linux 项目。命令如下：
|
||||
Windows 有一个名为 [sysprep](https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/sysprep--generalize--a-windows-installation?view=windows-11) 的实用程序，用于一般化镜像并重置上述 Linux 项目。命令如下：
|
||||
|
||||
```PowerShell
|
||||
sysprep.exe /generalize /shutdown /oobe
|
||||
|
||||
+9
-1
@@ -2,7 +2,7 @@
|
||||
title: 将用户添加到集群
|
||||
---
|
||||
|
||||
如果你想为用户提供对集群内 _所有_ 项目、节点和资源的访问权限，请为用户分配集群成员资格。
|
||||
To provide a user access to view certain cluster-level resources and create new projects, assign the user a **Cluster Membership**. Cluster members can create projects and manage resources in those projects. However, not all resources, namespaces and workloads in a cluster are accessible by cluster members.
|
||||
|
||||
:::tip
|
||||
|
||||
@@ -29,6 +29,14 @@ title: 将用户添加到集群
|
||||
1. 在**成员角色**选项卡中，单击**添加成员**。
|
||||
1. 搜索要添加到集群的用户或组。
|
||||
|
||||
:::note Notes:
|
||||
|
||||
- At least 2 characters must be typed in the search box for results to appear.
|
||||
- Users can be searched based on their username or display name.
|
||||
- Search is prefix-based (e.g., a user named `Stan Dard` will appear when searching for `Sta`, but not when searching for `Dar`) and case-sensitive.
|
||||
|
||||
:::
|
||||
|
||||
如果配置了外部身份验证：
|
||||
|
||||
- 在你键入时，Rancher 会从你的[外部身份验证](../../authentication-permissions-and-global-configuration/authentication-config/authentication-config.md)源返回用户。
|
||||
|
||||
+6
@@ -180,6 +180,12 @@ for mount in $(mount | grep tmpfs | grep '/var/lib/kubelet' | awk '{ print $3 }'
|
||||
</TabItem>
|
||||
<TabItem value="RKE2">
|
||||
|
||||
:::note
|
||||
|
||||
For instructions on cleaning nodes in RKE2 clusters that weren't deployed by Rancher, see the [official RKE2 documentation](https://docs.rke2.io/install/uninstall) on uninstalling clusters.
|
||||
|
||||
:::
|
||||
|
||||
你需要从 Rancher 提供的 RKE2 节点中删除以下组件：
|
||||
|
||||
* rancher-system-agent，用于连接 Rancher 并安装和管理 RKE2。
|
||||
|
||||
+9
-1
@@ -164,7 +164,15 @@ Rancher 在 Kubernetes 之上进行了扩展，除了集群级别之外，还允
|
||||
要添加成员：
|
||||
|
||||
1. 在**成员**选项卡中，单击**添加**。
|
||||
1. 在**选择成员**字段中，搜索要分配项目访问权限的用户或组。请注意，如果你启用了外部身份验证，则只能搜索组。
|
||||
1. 在**选择成员**字段中，搜索要分配项目访问权限的用户或组。如果你启用了外部身份验证，则只能搜索组。
|
||||
|
||||
:::note Notes:
|
||||
|
||||
- At least 2 characters must be typed in the search box for results to appear.
|
||||
- Users can be searched based on their username or display name.
|
||||
- Search is prefix-based (e.g., a user named `Stan Dard` will appear when searching for `Sta`, but not when searching for `Dar`) and case-sensitive.
|
||||
|
||||
:::
|
||||
1. 在**项目权限**中选择一个角色。如需更多信息，请参阅[项目角色文档](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md)。
|
||||
|
||||
### 4. 可选：添加资源配额
|
||||
|
||||
+3
-8
@@ -14,14 +14,9 @@ title: 安装 Adapter
|
||||
:::
|
||||
|
||||
| Rancher 版本 | Adapter 版本 |
|
||||
|-----------------|:---------------:|
|
||||
| v2.7.0 | v2.0.0 |
|
||||
| v2.7.1 | v2.0.0 |
|
||||
| v2.7.2 | v2.0.1 |
|
||||
| v2.7.3 | v2.0.1 |
|
||||
| v2.7.4 | v2.0.1 |
|
||||
| v2.7.5 | v2.0.2 |
|
||||
|
||||
|-----------------|:----------------:|
|
||||
| v2.11.1 | v106.0.0+up6.0.0 |
|
||||
| v2.11.0 | v106.0.0+up6.0.0 |
|
||||
|
||||
## 1. 获取对 Local 集群的访问权限
|
||||
|
||||
|
||||
+1
-1
@@ -9,6 +9,6 @@ title: Cluster API (CAPI) 与 Rancher Turtles
|
||||
[Rancher Turtles](https://turtles.docs.rancher.com/) 是一个 [Rancher 扩展](../rancher-extensions.md)，通过提供 Cluster API (CAPI) 和 Rancher 之间的集成来管理配置的 Kubernetes 集群的生命周期。使用 Rancher Turtles，你可以：
|
||||
|
||||
- 通过在 CAPI 配置的集群中安装 Rancher Cluster Agent，将 CAPI 集群导入 Rancher。
|
||||
- 配置 [CAPI Operator](https://turtles.docs.rancher.com/reference-guides/rancher-turtles-chart/values#cluster-api-operator-values)。
|
||||
- 配置 [CAPI Operator](https://turtles.docs.rancher.com/turtles/next/en/reference-guides/rancher-turtles-chart/values.html#cluster-api-operator-values)。
|
||||
|
||||
[概述](./overview.md)部分介绍了安装选项、Rancher Turtles 架构和简要 Demo。有关详细信息，请参阅 [Rancher Turtles 文档](https://turtles.docs.rancher.com/)。
|
||||
|
||||
+4
-4
@@ -16,7 +16,7 @@ title: 概述
|
||||
|
||||
[SLSA](https://slsa.dev/spec/v1.0/about) 是一套由行业共识制定的可逐步采用的供应链安全指南。SLSA 制定的规范对软件生产者和消费者都很有用：生产者可以遵循 SLSA 的指导方针，使他们的软件供应链更加安全，消费者可以使用 SLSA 来决定是否信任软件包。
|
||||
|
||||
Rancher Turtles 满足 [SLSA Level 3](https://slsa.dev/spec/v1.0/levels#build-l3) 对适当的构建平台、一致的构建过程和来源分布的要求。更多信息请参阅 [Rancher Turtles 安全](https://turtles.docs.rancher.com/security/slsa)文档。
|
||||
Rancher Turtles 满足 [SLSA Level 3](https://slsa.dev/spec/v1.0/levels#build-l3) 对适当的构建平台、一致的构建过程和来源分布的要求。更多信息请参阅 [Rancher Turtles 安全](https://turtles.docs.rancher.com/turtles/next/en/security/slsa.html)文档。
|
||||
|
||||
## 先决条件
|
||||
|
||||
@@ -92,7 +92,7 @@ kubectl apply -f feature.yaml
|
||||
1. 点击 **Rancher Turtles - the Cluster API Extension**。
|
||||
1. 点击 **Install > Next > Install**.
|
||||
|
||||
此过程使用 Helm chart 的默认值，这些值适用于大部分的安装场景。如果你的配置需要覆盖其中一些默认值，你可以在安装期间通过 Rancher UI 指定这些值，也可以通过 [Helm 手动安装 Chart](#通过-helm-安装)。有关可用的 values 设置的详细信息，请参阅 Rancher Turtles 的 [Helm chart 参考指南](https://turtles.docs.rancher.com/reference-guides/rancher-turtles-chart/values)。
|
||||
此过程使用 Helm chart 的默认值，这些值适用于大部分的安装场景。如果你的配置需要覆盖其中一些默认值，你可以在安装期间通过 Rancher UI 指定这些值，也可以通过 [Helm 手动安装 Chart](#通过-helm-安装)。有关可用的 values 设置的详细信息，请参阅 Rancher Turtles 的 [Helm chart 参考指南](https://turtles.docs.rancher.com/turtles/next/en/reference-guides/rancher-turtles-chart/values.html)。
|
||||
|
||||
安装可能需要几分钟时间，安装完成后，你可以在集群中看到以下新部署：
|
||||
|
||||
@@ -177,7 +177,7 @@ stringData:
|
||||
|
||||
:::info
|
||||
|
||||
有关 chart 支持的 values 及其用法的详细信息，请参阅 [Helm chart 选项](https://turtles.docs.rancher.com/reference-guides/rancher-turtles-chart/values)
|
||||
有关 chart 支持的 values 及其用法的详细信息，请参阅 [Helm chart 选项](https://turtles.docs.rancher.com/turtles/next/en/reference-guides/rancher-turtles-chart/values.html)
|
||||
|
||||
:::
|
||||
|
||||
@@ -185,7 +185,7 @@ stringData:
|
||||
|
||||
:::note
|
||||
|
||||
请记住，如果使用此安装选项，你必须自行管理 CAPI Operator 的安装。你可以参照 Rancher Turtles 文档中的 [CAPI Operator 指南](https://turtles.docs.rancher.com/contributing/install_capi_operator)
|
||||
请记住，如果使用此安装选项，你必须自行管理 CAPI Operator 的安装。你可以参照 Rancher Turtles 文档中的 [CAPI Operator 指南](https://turtles.docs.rancher.com/turtles/next/en/contributing/install_capi_operator.html)
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+1
-1
@@ -15,4 +15,4 @@ Prime 还提供生产支持选项，以及根据你的商业需求定制的订
|
||||
import DocCardList from '@theme/DocCardList';
|
||||
import { useCurrentSidebarCategory } from '@docusaurus/theme-common/internal';
|
||||
|
||||
<DocCardList items={useCurrentSidebarCategory().items.slice(0,8)} />
|
||||
<DocCardList items={useCurrentSidebarCategory().items.slice(0,10)} />
|
||||
|
||||
+1
-1
@@ -50,7 +50,7 @@ Kiali 是一个全面的可视化辅助工具，用于绘制整个服务网格
|
||||
|
||||
Jaeger 是用于跟踪分布式系统的工具。我们的 Istio 安装程序包括能快速启动的一体化 [Jaeger](https://www.jaegertracing.io/) 安装。
|
||||
|
||||
请注意，这不是符合 Jaeger 生产要求的部署。此部署使用在内存中的存储组件，而 Jaeger 推荐在生产环境中使用持久存储组件。有关你所需的部署策略的更多信息，请参阅 [Jaeger 文档](https://www.jaegertracing.io/docs/latest/operator/#production-strategy)。
|
||||
请注意，这不是符合 Jaeger 生产要求的部署。此部署使用在内存中的存储组件，而 Jaeger 推荐在生产环境中使用持久存储组件。有关你所需的部署策略的更多信息，请参阅 [Jaeger 文档](https://www.jaegertracing.io/docs/1.65/operator/#production-strategy)。
|
||||
|
||||
## 先决条件
|
||||
|
||||
|
||||
+1
-1
@@ -62,7 +62,7 @@ Prometheus 不是用于长期存储指标的，它只用于短期存储。
|
||||
|
||||
### 关于 Prometheus Exporters
|
||||
|
||||
许多第三方工作负载（如数据库、队列或 Web 服务器）要么已经支持以 Prometheus 格式公开指标，要么有所谓的 exporter，来对工具的指标格式和 Prometheus 理解的指标格式进行转换。通常，你可以将这些 exporter 作为额外的 Sidecar 容器添加到工作负载的 Pod 中。很多 Helm Chart 已经包含了部署 exporter 的选项。此外，你还可以在 [promcat.io](https://promcat.io/) 和 [ExporterHub](https://exporterhub.io/) 上找到一个由 SysDig 策划的 exporter 列表。
|
||||
许多第三方工作负载（如数据库、队列或 Web 服务器）要么已经支持以 Prometheus 格式公开指标，要么有所谓的 exporter，来对工具的指标格式和 Prometheus 理解的指标格式进行转换。通常，你可以将这些 exporter 作为额外的 Sidecar 容器添加到工作负载的 Pod 中。很多 Helm Chart 已经包含了部署 exporter 的选项。此外，你还可以在 [ExporterHub](https://exporterhub.io/) 上找到一个策划的 exporter 列表。
|
||||
|
||||
### Prometheus 的编程语言和框架支持
|
||||
|
||||
|
||||
+1
-1
@@ -14,7 +14,7 @@ Rancher CLI（命令行界面）是一个命令行工具，可用于与 Rancher
|
||||
你可以直接 UI 下载二进制文件。
|
||||
|
||||
1. 点击左上角的 **☰**。
|
||||
1. 在导航侧边栏菜单底部，单击**简介**。
|
||||
1. 在导航侧边栏菜单底部，单击Rancher的版本号。
|
||||
1. 在 **CLI 下载**中，有 Windows、Mac 和 Linux 的二进制文件下载链接。你还可以访问我们的 CLI [发布页面](https://github.com/rancher/cli/releases)直接下载二进制文件。
|
||||
|
||||
## 要求
|
||||
|
||||
+2
@@ -2,6 +2,8 @@
|
||||
title: RKE 集群配置参考
|
||||
---
|
||||
|
||||
<EOLRKE1Warning />
|
||||
|
||||
Rancher 安装 Kubernetes 时，它使用 [RKE](../../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) 或 [RKE2](https://docs.rke2.io/) 作为 Kubernetes 发行版。
|
||||
|
||||
本文介绍 Rancher 中可用于新的或现有的 RKE Kubernetes 集群的配置选项。
|
||||
|
||||
+2
-2
@@ -8,7 +8,7 @@ title: 示例
|
||||
|
||||
## PodMonitor
|
||||
|
||||
你可以在[此处](https://github.com/prometheus-operator/prometheus-operator/blob/master/example/user-guides/getting-started/example-app-pod-monitor.yaml)找到 PodMonitor 示例，还可以在[此处](https://github.com/prometheus-operator/prometheus-operator/blob/master/example/user-guides/getting-started/prometheus-pod-monitor.yaml)找到引用它的 Prometheus 资源示例。
|
||||
你可以在[此处](https://prometheus-operator.dev/docs/developer/getting-started/#using-podmonitors)找到 PodMonitor 示例和引用它的 Prometheus 资源示例。
|
||||
|
||||
## PrometheusRule
|
||||
|
||||
@@ -16,7 +16,7 @@ PrometheusRule 包含你通常放置在 [Prometheus 规则文件](https://promet
|
||||
|
||||
要在集群中更细粒度地应用 PrometheusRules，你可以使用 Prometheus 资源的 ruleSelector 字段，从而根据添加到 PrometheusRules 资源的标签来选择要加载到 Prometheus 上的 PrometheusRule。
|
||||
|
||||
你可以在[此页面](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/user-guides/alerting.md)找到 PrometheusRule 示例。
|
||||
你可以在[此页面](https://prometheus-operator.dev/docs/developer/alerting/)找到 PrometheusRule 示例。
|
||||
|
||||
## Alertmanager 配置
|
||||
|
||||
|
||||
+2
-2
@@ -20,7 +20,7 @@ ServiceMonitor 比 PodMonitor 更常用，推荐用于大多数用例。
|
||||
|
||||
创建 ServiceMonitor 时，Prometheus Operator 会更新 Prometheus 抓取配置，从而包含 ServiceMonitor 配置。然后 Prometheus 开始从 ServiceMonitor 中定义的端点抓取指标。
|
||||
|
||||
如果集群中的任何 Service 与 ServiceMonitor `selector` 字段中的标签匹配，则会根据 ServiceMonitor 指定的 `endpoints` 进行监控。有关可以指定的字段的更多信息，请查看 Prometheus Operator 的[规范](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/api.md#servicemonitor)。
|
||||
如果集群中的任何 Service 与 ServiceMonitor `selector` 字段中的标签匹配，则会根据 ServiceMonitor 指定的 `endpoints` 进行监控。有关可以指定的字段的更多信息，请查看 Prometheus Operator 的[规范](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api-reference/api.md#servicemonitor)。
|
||||
|
||||
有关 ServiceMonitor 工作原理的更多信息，请参阅 [Prometheus Operator 文档](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/user-guides/running-exporters.md)。
|
||||
|
||||
@@ -30,4 +30,4 @@ ServiceMonitor 比 PodMonitor 更常用，推荐用于大多数用例。
|
||||
|
||||
创建 PodMonitor 时，Prometheus Operator 会更新 Prometheus 抓取配置，从而包含 PodMonitor 配置。然后 Prometheus 开始从 PodMonitor 中定义的端点抓取指标。
|
||||
|
||||
如果集群中的任何 Pod 与 PodMonitor `selector` 字段中的标签匹配，则会根据 PodMonitor 指定的 `podMetricsEndpoints` 进行监控。有关可以指定的字段的更多信息，请查看 Prometheus Operator 的[规范](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/api.md#podmonitorspec)。
|
||||
如果集群中的任何 Pod 与 PodMonitor `selector` 字段中的标签匹配，则会根据 PodMonitor 指定的 `podMetricsEndpoints` 进行监控。有关可以指定的字段的更多信息，请查看 Prometheus Operator 的[规范](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api-reference/api.md#podmonitor)。
|
||||
|
||||
+2
@@ -6,6 +6,8 @@ title: RKE 加固指南
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide"/>
|
||||
</head>
|
||||
|
||||
<EOLRKE1Warning />
|
||||
|
||||
本文档提供了针对生产环境的 RKE 集群进行加固的具体指导，以便在使用 Rancher 部署之前进行配置。它概述了满足信息安全中心（Center for Information Security, CIS）Kubernetes benchmark controls 所需的配置和控制。
|
||||
|
||||
:::note
|
||||
|
||||
+2
@@ -6,6 +6,8 @@ title: RKE 自我评估指南 - CIS Benchmark v1.23 - K8s v1.23
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.23-k8s-v1.23"/>
|
||||
</head>
|
||||
|
||||
<EOLRKE1Warning />
|
||||
|
||||
本文档是 [RKE 加固指南](rke1-hardening-guide.md)的配套文档，该指南提供了关于如何加固正在生产环境中运行并由 Rancher 管理的 RKE 集群的指导方针。本 benchmark 指南可帮助你根据 CIS Kubernetes Benchmark 中的每个 control 来评估加固集群的安全性。
|
||||
|
||||
本指南对应以下版本的 Rancher、CIS Benchmarks 和 Kubernetes：
|
||||
|
||||
+2
@@ -6,6 +6,8 @@ title: RKE 自我评估指南 - CIS Benchmark v1.24 - K8s v1.24
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.24-k8s-v1.24"/>
|
||||
</head>
|
||||
|
||||
<EOLRKE1Warning />
|
||||
|
||||
本文档是 [RKE 加固指南](rke1-hardening-guide.md)的配套文档，该指南提供了关于如何加固正在生产环境中运行并由 Rancher 管理的 RKE 集群的指导方针。本 benchmark 指南可帮助你根据 CIS Kubernetes Benchmark 中的每个 control 来评估加固集群的安全性。
|
||||
|
||||
本指南对应以下版本的 Rancher、CIS Benchmarks 和 Kubernetes：
|
||||
|
||||
+2
@@ -6,6 +6,8 @@ title: RKE 自我评估指南 - CIS Benchmark v1.7 - K8s v1.25/v1.26/v1.27
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.7-k8s-v1.25-v1.26-v1.27"/>
|
||||
</head>
|
||||
|
||||
<EOLRKE1Warning />
|
||||
|
||||
本文档是 [RKE 加固指南](rke1-hardening-guide.md)的配套文档，该指南提供了关于如何加固正在生产环境中运行并由 Rancher 管理的 RKE 集群的指导方针。本 benchmark 指南可帮助你根据 CIS Kubernetes Benchmark 中的每个 control 来评估加固集群的安全性。
|
||||
|
||||
本指南对应以下版本的 Rancher、CIS Benchmarks 和 Kubernetes：
|
||||
|
||||
+17
-1
@@ -10,7 +10,23 @@ Rancher 致力于向社区披露我们产品的安全问题。我们会针对已
|
||||
|
||||
| ID | 描述 | 日期 | 解决 |
|
||||
|----|-------------|------|------------|
|
||||
| [CVE-2024-22030](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-22030) | 发现了 Rancher 和 Fleet 代理的一个漏洞，目前被认为是中到高危的 CVE。在非特定情况下，这个漏洞允许恶意行为者接管现有的 Rancher 节点。攻击者需要控制一个过期的域名，或者对该域名执行 DNS 欺骗/劫持攻击才可以利用此漏洞。被攻击的域名是 Rancher URL（用作 Rancher 集群的 server-url）。目前还没有可用的修复方案，它影响所有受支持的 Rancher 版本。建议客户和用户遵循我们[博客文章](https://www.suse.com/c/rancher-security-update/)中描述的建议和最佳实践。 | 2024 年 2 月 16 日 | 处理中 |
|
||||
| [CVE-2025-23390](https://github.com/rancher/fleet/security/advisories/GHSA-xgpc-q899-67p8) | This vulnerability only affects customers using [Continuous Delivery with Fleet](https://ranchermanager.docs.rancher.com/integrations-in-rancher/fleet) where Fleet does not validate a server's certificate when connecting through SSH. This can allow for a main-in-the-middle-attack against Fleet. The fix provides a new `insecureSkipHostKeyChecks` value for the `fleet` Helm chart. The default value is set to **`true` (opt-in) for Rancher v2.9 - v2.11** for backward compatibility. The default value is set to **`false` (opt-out) for Rancher v2.12 and later**, and Fleet v0.13 and later. <br/><br/> `true` (opt-in): <br/><br/><ul> If `insecureSkipHostKeyChecks` is set to `true`, then not finding any matching `known_hosts` entry for an SSH host will not lead to any error. Please note, regardless of the configuration setting, if the `known-hosts` ConfigMap is deleted it will lead to errors as it will be considered a symptom of an incomplete Fleet deployment. </ul> `false` (opt-out): <br/><br/><ul> If `insecureSkipHostKeyChecks` is set to `false`, then strict host key checks are enabled. When enabled, the checks ensure that when using SSH, Fleet rejects connection attempts to hosts not matching any entry found in (decreasing order of precedence): <br/><br/><ul> <li>A secret referenced by name in a `GitRepo` which is located in the same `GitRepo's` namespace.</li> <li> If no such secret name is provided, in a `gitcredential` secret located in the same namespace. </li> <li> A new `known-hosts` ConfigMap, created during the Fleet chart installation time and located in the namespace `cattle-fleet-system`. </li></ul> <br></br> This happens regardless of whether a `GitRepo` uses an SSH URL to point to a Git repository since, once cloned, a repository may be found to contain external resources to be retrieved, such as Helm artifacts. </ul> A limitation with the default `known_hosts` entries is that they are only provided for GitHub, Gitlab, Bitbucket and Azure DevOps hosts. If you need to connect to a different host, or if key fingerprints for the provided entries are updated, the following options are available: <br/><br/><ul><li> Manually update the default `known-hosts` ConfigMap. </li> <li> Reference a secret from your `GitRepo` resources, containing the updated or additional `known_hosts` entries. </li> <li> Create a `gitcredential` secret containing the entries for `GitRepo` resources that do not already reference a secret. </li></ul> | 24 Apr 2025 | Rancher [v2.11.1](https://github.com/rancher/rancher/releases/tag/v2.11.1), [v2.10.5](https://github.com/rancher/rancher/releases/tag/v2.10.5), and [v2.9.9](https://github.com/rancher/rancher/releases/tag/v2.9.9) |
|
||||
| [CVE-2025-22031](https://github.com/rancher/rancher/security/advisories/GHSA-8h6m-wv39-239m) | A vulnerability was found where users could create a project and then gain access to arbitrary projects. As a fix, a new field has been added to projects called the `BackingNampespace`, which represents the namespace created for a project containing all resources needed for project operations. This includes resources such as ProjectRoleTemplateBindings, project-scoped secrets and workloads. <br/><br/> The field is populated automatically during project creation and is formatted as `<clusterID>-<project.Name>`. For example, if your project is named `project-abc123` in a cluster with ID `cluster-xyz789`, then the project will have the `BackingNampespace`: `cluster-xyz789-project-abc123`. <br/><br/> If the `BackingNampespace` field is empty then the project will fallback to using the namespace that is the project's name as it did before. Existing projects will not be migrated and only newly created projects will have the new namespace naming convention. If listing projects via `kubectl` the `BackingNampespace` will also be listed as a column. | 24 Apr 2025 | Rancher [v2.11.1](https://github.com/rancher/rancher/releases/tag/v2.11.1), [v2.10.5](https://github.com/rancher/rancher/releases/tag/v2.10.5), and [v2.9.9](https://github.com/rancher/rancher/releases/tag/v2.9.9) |
|
||||
| [CVE-2025-32198](https://github.com/rancher/steve/security/advisories/GHSA-95fc-g4gj-mqmx) | A vulnerability was found where users with permission to create a service in the Kubernetes cluster where Rancher is deployed can take over the Rancher UI, display their own UI, and gather sensitive information. This is only possible when the setting `ui-offline-preferred` is set to `remote`. This release introduces a patch, and the malicious user can no longer serve their own UI. If users can't upgrade, please make sure that only trustable users have access to create a service in the local cluster. | 24 Apr 2025 | Rancher [v2.11.1](https://github.com/rancher/rancher/releases/tag/v2.11.1), [v2.10.5](https://github.com/rancher/rancher/releases/tag/v2.10.5), [v2.9.9](https://github.com/rancher/rancher/releases/tag/v2.9.9) and [v2.8.15](https://github.com/rancher/rancher/releases/tag/v2.8.15) |
|
||||
| [CVE-2025-23391](https://github.com/rancher/rancher/security/advisories/GHSA-8p83-cpfg-fj3g) | A vulnerability has been identified within Rancher where a Restricted Administrator can change the password of Administrators and take over their accounts. A Restricted Administrator should not be allowed to change the password of more privileged users unless it contains the Manage Users permissions. A new validation has been added to block a user from editing or deleting another user with more permissions than themselves. Rancher deployments where the Restricted Administrator role is not being used are not affected by this CVE. | 31 Mar 2025 | Rancher [v2.11.0](https://github.com/rancher/rancher/releases/tag/v2.11.0), [v2.10.4](https://github.com/rancher/rancher/releases/tag/v2.10.4), [v2.9.8](https://github.com/rancher/rancher/releases/tag/v2.9.8) and [v2.8.14](https://github.com/rancher/rancher/releases/tag/v2.8.14) |
|
||||
| [CVE-2025-23389](https://github.com/rancher/rancher/security/advisories/GHSA-5qmp-9x47-92q8) | A vulnerability in Rancher has been discovered, leading to a local user impersonation through SAML Authentication on first login. <br/><br/> The issue occurs when a SAML authentication provider (AP) is configured (e.g. Keycloak). A newly created AP user can impersonate any user on Rancher by manipulating cookie values during their initial login to Rancher. This vulnerability could also be exploited if a Rancher user (present on the AP) is removed, either manually or automatically via the [User Retention feature](../../how-to-guides/advanced-user-guides/enable-user-retention.md) with delete-inactive-user-after | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) |
|
||||
| [CVE-2025-23388](https://github.com/rancher/rancher/security/advisories/GHSA-xr9q-h9c7-xw8q) | An unauthenticated stack overflow crash, leading to a denial of service (DoS), was identified in Rancher’s `/v3-public/authproviders` public API endpoint. A malicious user could submit data to the API which would cause the Rancher server to crash, but no malicious or incorrect data would actually be written in the API. The downstream clusters, i.e., the clusters managed by Rancher, are not affected by this issue. <br/><br/> This vulnerability affects those using external authentication providers as well as Rancher’s local authentication. | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) |
|
||||
| [CVE-2025-23387](https://github.com/rancher/rancher/security/advisories/GHSA-mq23-vvg7-xfm4) | A vulnerability has been identified within Rancher where it is possible for an unauthenticated user to list all CLI authentication tokens and delete them before the CLI is able to get the token value. This effectively prevents users from logging in via the CLI when using rancher token as the execution command (instead of the token directly being in the kubeconfig). <br/><br/> Note that this token is not the kubeconfig token and if an attacker is able to intercept it they can't use it to impersonate a real user since it is encrypted. | 27 Feb 2025 | Rancher [v2.10.3](https://github.com/rancher/rancher/releases/tag/v2.10.3), [v2.9.7](https://github.com/rancher/rancher/releases/tag/v2.9.7) and [v2.8.13](https://github.com/rancher/rancher/releases/tag/v2.8.13) |
|
||||
| [CVE-2024-52281](https://github.com/rancher/rancher/security/advisories/GHSA-2v2w-8v8c-wcm9) | A high severity vulnerability was identified within the Rancher UI that allows a malicious actor to perform a Stored XSS attack through the cluster description field. | 15 Jan 2025 | Rancher [v2.10.0](https://github.com/rancher/rancher/releases/tag/v2.10.0) and [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) |
|
||||
| [CVE-2024-52282](https://github.com/rancher/rancher/security/advisories/GHSA-9c5p-35gj-jqp4) | A medium severity vulnerability was discovered within Rancher Manager whereby applications installed via Rancher Manager Apps Catalog store their Helm values directly into the Apps Custom Resource Definition, resulting in any users with GET access to it to be able to read any sensitive information that are contained within the Apps’ values. Additionally, the same information leaks into auditing logs when the audit level is set to equal or above 2. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 19 Nov 2024 | Rancher [v2.9.4](https://github.com/rancher/rancher/releases/tag/v2.9.4) and [v2.8.10](https://github.com/rancher/rancher/releases/tag/v2.8.10). |
|
||||
| [CVE-2024-22036](https://github.com/rancher/rancher/security/advisories/GHSA-h99m-6755-rgwc) | A critical severity vulnerability was discovered within Rancher where a cluster or node driver can be used to escape the `chroot` jail and gain root access to the Rancher container itself. In production environments, further privilege escalation is possible based on living off the land within the Rancher container itself. For test and development environments, based on a –privileged Docker container, it is possible to escape the Docker container and gain execution access on the host system. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3), [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) and [v2.7.16](https://github.com/rancher/rancher/releases/tag/v2.7.16) |
|
||||
| [CVE-2023-32197](https://github.com/rancher/rancher/security/advisories/GHSA-7h8m-pvw3-5gh4) | A critical severity vulnerability was discovered whereby Rancher Manager deployments containing Windows nodes have weak Access Control Lists (ACL), allowing `BUILTIN\Users` or `NT AUTHORITY\Authenticated Users` to view or edit sensitive files which could lead to privilege escalation. This vulnerability is exclusive to deployments that contain Windows nodes. Linux-only environments are not affected by it. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) |
|
||||
| [CVE-2022-45157](https://github.com/rancher/rancher/security/advisories/GHSA-xj7w-r753-vj8v) | A critical severity vulnerability was discovered in the way that Rancher stores vSphere's CPI (Cloud Provider Interface) and CSI (Container Storage Interface) credentials used to deploy clusters through the vSphere cloud provider. This issue leads to the vSphere CPI and CSI passwords being stored in a plaintext object inside Rancher. This vulnerability is only applicable to users that deploy clusters in vSphere environments. **Rancher v2.7 is vulnerable and hasn't received the fix**. | 24 Oct 2024 | Rancher [v2.9.3](https://github.com/rancher/rancher/releases/tag/v2.9.3) and [v2.8.9](https://github.com/rancher/rancher/releases/tag/v2.8.9) |
|
||||
| [CVE-2024-22030](https://github.com/rancher/rancher/security/advisories/GHSA-h4h5-9833-v2p4) | 发现了 Rancher 和 Fleet 代理的一个漏洞，目前被认为是中到高危的 CVE。在非特定情况下，这个漏洞允许恶意行为者接管现有的 Rancher 节点。攻击者需要控制一个过期的域名，或者对该域名执行 DNS 欺骗/劫持攻击才可以利用此漏洞。被攻击的域名是 Rancher URL（用作 Rancher 集群的 server-url）。目前还没有可用的修复方案，它影响所有受支持的 Rancher 版本。建议客户和用户遵循我们[博客文章](https://www.suse.com/c/rancher-security-update/)中描述的建议和最佳实践。 | 2024 年 9 月 19 日 | 处理中 |
|
||||
| [CVE-2024-22032](https://github.com/rancher/rancher/security/advisories/GHSA-q6c7-56cq-g2wm) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where custom secrets encryption configurations are stored in plaintext under the clusters `AppliedSpec`. This also causes clusters to continuously reconcile, as the `AppliedSpec` would never match the desired cluster `Spec`. The stored information contains the encryption configuration for secrets within etcd, and could potentially expose sensitive data if the etcd database was exposed directly. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
| [CVE-2023-32196](https://github.com/rancher/rancher/security/advisories/GHSA-64jq-m7rq-768h) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where the webhook rule resolver ignores rules from a `ClusterRole` for an external `RoleTemplate` set with `.context=project` or `.context=""`. This allows a user to create an external `ClusterRole` with `.context=project` or `.context=""`, depending on the use of the new feature flag `external-rules` and backing `ClusterRole`. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
| [CVE-2023-22650](https://github.com/rancher/rancher/security/advisories/GHSA-9ghh-mmcq-8phc) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, where Rancher did not have a user retention process for when external authentication providers are used, that could be configured to run periodically and disable and/or delete inactive users. The new user retention process added in Rancher v2.8.5 and Rancher v2.7.14 is disabled by default. If enabled, a user becomes subject to the retention process if they don't log in for a configurable period of time. It's possible to set overrides for user accounts that are primarily intended for programmatic access (e.g. CI, scripts, etc.) so that they don't become subject to the retention process for a longer period of time or at all. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
| [CVE-2023-32191](https://github.com/rancher/rke/security/advisories/GHSA-6gr4-52w6-vmqx) | An issue was discovered in Rancher versions up to and including 2.7.13 and 2.8.4, in which supported RKE versions store credentials inside a ConfigMap that can be accessible by non-administrative users in Rancher. This vulnerability only affects an RKE-provisioned cluster. | 17 Jun 2024 | Rancher [v2.8.5](https://github.com/rancher/rancher/releases/tag/v2.8.5) and [v2.7.14](https://github.com/rancher/rancher/releases/tag/v2.7.14) |
|
||||
| [CVE-2023-32193](https://github.com/rancher/norman/security/advisories/GHSA-r8f4-hv23-6qp6) | 在 Rancher 2.6.13、2.7.9 和 2.8.1 及之前的版本中发现了一个问题。多个 Cross-Site Scripting (XSS) 漏洞可通过 Rancher UI (Norman) 进行利用。 | 2024 年 2 月 8 日 | Rancher [v2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2)、[v2.7.10](https://github.com/rancher/rancher/releases/tag/v2.7.10) 和 [v2.6.14](https://github.com/rancher/rancher/releases/tag/v2.6.14) |
|
||||
| [CVE-2023-32192](https://github.com/rancher/apiserver/security/advisories/GHSA-833m-37f7-jq55) | 在 Rancher 2.6.13、2.7.9 和 2.8.1 及之前的版本中发现了一个问题。多个 Cross-Site Scripting (XSS) 漏洞，可以通过 Rancher UI (Apiserver) 进行利用 | 2024 年 2 月 8 日 | Rancher [v2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2)、[v2.7.10](https://github.com/rancher/rancher/releases/tag/v2.7.10) 和 [v2.6.14](https://github.com/rancher/rancher/releases/tag/v2.6.14) |
|
||||
| [CVE-2023-22649](https://github.com/rancher/rancher/security/advisories/GHSA-xfj7-qf8w-2gcr) | 在 Rancher 2.6.13、2.7.9 和 2.8.1 及之前的版本中发现了一个问题。敏感数据可能会泄漏到 Rancher 的审计日志中。 | 2024 年 2 月 8 日 | Rancher [v2.8.2](https://github.com/rancher/rancher/releases/tag/v2.8.2)、[v2.7.10](https://github.com/rancher/rancher/releases/tag/v2.7.10) 和 [v2.6.14](https://github.com/rancher/rancher/releases/tag/v2.6.14) |
|
||||
|
||||
@@ -19,11 +19,9 @@ Rancher 将 Rancher-Webhook 作为单独的 deployment 和服务部署在 local
|
||||
<!-- releaseTask -->
|
||||
|
||||
| Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
|
||||
| --------------- | --------------- | --------------------- | ------------------------- |
|
||||
| v2.8.3 | v0.4.3 | ✓ | ✓ |
|
||||
| v2.8.2 | v0.4.2 | ✓ | ✓ |
|
||||
| v2.8.1 | v0.4.2 | ✓ | ✓ |
|
||||
| v2.8.0 | v0.4.2 | ✗ | ✓ |
|
||||
|-----------------|-----------------|-----------------------|---------------------------|
|
||||
| v2.11.1 | v0.7.1 | ✓ | ✓ |
|
||||
| v2.11.0 | v0.7.0 | ✗ | ✓ |
|
||||
|
||||
## 为什么我们需要它？
|
||||
|
||||
|
||||
+2
@@ -2,6 +2,8 @@
|
||||
title: RKE1 示例 YAML
|
||||
---
|
||||
|
||||
<EOLRKE1Warning />
|
||||
|
||||
以下是一个供参考的 RKE 模板配置文件示例。
|
||||
|
||||
RKE 模板中的 YAML 使用与创建 RKE 集群时相同的自定义项。但是，由于 YAML 位于 Rancher 配置的 RKE 集群的上下文中，因此 RKE 文档中的自定义项需要嵌套在 `rancher_kubernetes_engine` 指令下。
|
||||
|
||||
+1
-1
@@ -96,7 +96,7 @@ pod "busybox" deleted
|
||||
- image: busybox:1.28
|
||||
imagePullPolicy: Always
|
||||
name: alpine
|
||||
command: ["sh", "-c", "tail -f /dev/null"]
|
||||
command: ["sleep", "infinity"]
|
||||
terminationMessagePath: /dev/termination-log
|
||||
```
|
||||
|
||||
|
||||
+1
-1
@@ -44,7 +44,7 @@ title: 网络
|
||||
- image: rancherlabs/swiss-army-knife
|
||||
imagePullPolicy: Always
|
||||
name: overlaytest
|
||||
command: ["sh", "-c", "tail -f /dev/null"]
|
||||
command: ["sleep", "infinity"]
|
||||
terminationMessagePath: /dev/termination-log
|
||||
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user