mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-05-04 20:23:24 +00:00
update missing Chinese translation for v2.7
This commit is contained in:
Jacie
+93
@@ -0,0 +1,93 @@
|
||||
---
|
||||
title: API
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/about-the-api"/>
|
||||
</head>
|
||||
|
||||
## 如何使用 API
|
||||
|
||||
API 有自己的用户界面，你可以从 Web 浏览器访问它。这是查看资源、执行操作以及查看等效 cURL 或 HTTP 请求和响应的一种简单的方法。要访问它：
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="Rancher v2.6.4+">
|
||||
|
||||
1. 单击右上角的用户头像。
|
||||
1. 单击**账号 & API 密钥**。
|
||||
1. 在 **API 密钥**下，找到 **API 端点**字段并单击链接。该链接类似于 `https://<RANCHER_FQDN>/v3`，其中 `<RANCHER_FQDN>` 是 Rancher deployment 的完全限定域名。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Rancher 版本低于 v2.6.4">
|
||||
|
||||
转到位于 `https://<RANCHER_FQDN>/v3` 的 URL 端点，其中 `<RANCHER_FQDN>` 是你的 Rancher deployment 的完全限定域名。
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## 认证
|
||||
|
||||
API 请求必须包含认证信息。认证是通过 [API 密钥](../user-settings/api-keys.md)使用 HTTP 基本认证完成的。API 密钥可以创建新集群并通过 `/v3/clusters/` 访问多个集群。[集群和项目角色](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md)会应用于这些键，并限制账号可以查看的集群和项目以及可以执行的操作。
|
||||
|
||||
默认情况下，某些集群级别的 API 令牌是使用无限期 TTL（`ttl=0`）生成的。换言之，除非你让令牌失效，否则 `ttl=0` 的 API 令牌永远不会过期。有关如何使 API 令牌失效的详细信息，请参阅 [API 令牌](api-tokens.md)。
|
||||
|
||||
## 发出请求
|
||||
|
||||
该 API 通常是 RESTful 的，但是还具有多种功能。这些功能可以使客户端发现所有内容，因此可以编写通用客户端，而不必为每种资源编写特定代码。有关通用 API 规范的详细信息，请参阅[此处](https://github.com/rancher/api-spec/blob/master/specification.md)。
|
||||
|
||||
- 每种类型都有一个 Schema，这个 Schema 描述了以下内容：
|
||||
- 用于获取此类资源集合的 URL
|
||||
- 资源可以具有的每个字段及其类型、基本验证规则、是必填还是可选字段等
|
||||
- 在此类资源上可以执行的每个操作，以及它们的输入和输出（也作为 schema）
|
||||
- 允许过滤的每个字段
|
||||
- 集合本身或集合中的单个资源可以使用的 HTTP 操作方法
|
||||
|
||||
|
||||
- 因此，你可以只加载 schema 列表并了解 API 的所有信息。实际上，这是 API 的 UI 工作方式，它不包含特定于 Rancher 本身的代码。每个 HTTP 响应中的 `X-Api-Schemas` 标头都会发送获取 Schemas 的 URL。你可以按照每个 schema 上的 `collection` 链接了解要在哪里列出资源，并在返回资源中的其他 `links` 中获取其他信息。
|
||||
|
||||
- 在实践中，你可能只想构造 URL 字符串。我们强烈建议将此限制为在顶层列出的集合 (`/v3/<type>`)，或获取特定资源 (`/v3/<type>/<id>`)。除此之外的任何内容都可能在将来的版本中发生更改。
|
||||
|
||||
- 资源之间相互之间有联系，称为链接（links）。每个资源都包含一个 `links` 映射，其中包含链接名称和用于检索该信息的 URL。同样，你应该 `GET` 资源并遵循 `links` 映射中的 URL，而不是自己构造这些字符串。
|
||||
|
||||
- 大多数资源都有操作（action），表示可以执行某个操作或改变资源的状态。要使用操作，请将 HTTP `POST` 请求发送到 `actions` 映射中你想要的操作的 URL。某些操作需要输入或生成输出，请参阅每种类型的独立文档或 schema 以获取具体信息。
|
||||
|
||||
- 要编辑资源，请将 HTTP `PUT` 请求发送到资源上的 `links.update` 链接，其中包含要更改的字段。如果链接丢失，则你无权更新资源。未知字段和不可编辑的字段将被忽略。
|
||||
|
||||
- 要删除资源，请将 HTTP `DELETE` 请求发送到资源上的 `links.remove` 链接。如果链接丢失，则你无权更新资源。
|
||||
|
||||
- 要创建新资源，HTTP `POST` 到 schema（即 `/v3/<type>`）中的集合 URL。
|
||||
|
||||
## 过滤
|
||||
|
||||
你可以使用 HTTP 查询参数的公共字段在服务器端过滤大多数集合。`filters` 映射显示了可以过滤的字段，以及过滤后的值在你发起的请求中是什么。API UI 具有设置过滤和显示适当请求的控件。对于简单的 "equals" 匹配，它只是 `field=value`。你可以将修饰符添加到字段名称，例如 `field_gt=42` 表示“字段大于 42”。详情请参阅 [API 规范](https://github.com/rancher/api-spec/blob/master/specification.md#filtering)。
|
||||
|
||||
## 排序
|
||||
|
||||
你可以使用 HTTP 查询参数的公共字段在服务器端排序大多数集合。`sortLinks` 映射显示了可用的排序，以及用于获取遵循该排序的集合的 URL。它还包括当前响排序依据的信息（如果指定）。
|
||||
|
||||
## 分页
|
||||
|
||||
默认情况下，API 响应以每页 100 个资源的限制进行分页。你可以通过 `limit` 查询参数进行更改，最大为 1000，例如 `/v3/pods?limit=1000`。集合响应中的 `pagination` 映射能让你知道你是否拥有完整的结果集，如果没有，则会指向下一页的链接。
|
||||
|
||||
## 捕获 Rancher API 调用
|
||||
|
||||
你可以使用浏览器开发人员工具来捕获 Rancher API 的调用方式。例如，你可以按照以下步骤使用 Chrome 开发人员工具来获取用于配置 RKE 集群的 API 调用：
|
||||
|
||||
1. 在 Rancher UI 中，转到**集群管理**并单击**创建**。
|
||||
1. 单击某个集群类型。此示例使用 Digital Ocean。
|
||||
1. 使用集群名称和节点模板填写表单，但不要单击**创建**。
|
||||
1. 在创建集群之前，你需要打开开发人员工具才能看到正在记录的 API 调用。要打开工具，右键单击 Rancher UI，然后单击**检查**。
|
||||
1. 在开发者工具中，单击 **Network** 选项卡。
|
||||
1. 在 **Network** 选项卡上，确保选择了 **Fetch/XHR**。
|
||||
1. 在 Rancher UI 中，单击**创建**。在开发者工具中，你应该会看到一个名为 `cluster?_replace=true` 的新网络请求。
|
||||
1. 右键单击 `cluster?_replace=true` 并单击**复制 > 复制为 cURL**。
|
||||
1. 将结果粘贴到文本编辑器中。你将能够看到 POST 请求，包括被发送到的 URL、所有标头以及请求的完整正文。此命令可用于从命令行创建集群。请注意，请求包含凭证，因此请将请求存储在安全的地方。
|
||||
|
||||
### 启用在 API 中查看
|
||||
|
||||
你还可以查看针对各自集群和资源捕获的 Rancher API 调用。 默认情况下不启用此功能。 要启用它：
|
||||
|
||||
1. 单击 UI 右上角的 **用户图标**，然后从下拉菜单中选择 **偏好设置**
|
||||
1. 在**高级功能**部分下，单击**启用"在 API 中查看"**
|
||||
|
||||
选中后，**在 API 中查看**链接现在将显示在 UI 资源页面上的 **⋮** 子菜单下。
|
||||
+6
@@ -68,6 +68,12 @@ kubectl create secret generic encryptionconfig \
|
||||
|
||||
### S3
|
||||
|
||||
:::caution
|
||||
|
||||
如果你使用 S3 备份目标，请确保每个集群都有自己的存储桶或文件夹。Rancher 将使用集群配置的 S3 存储桶或文件夹中的可用快照来填充快照信息。
|
||||
|
||||
:::
|
||||
|
||||
S3 存储位置包含以下配置字段：
|
||||
|
||||
1. **凭证密文**（可选）：如果你需要使用 AWS 访问密钥（access key）和密文密钥（secret key）来访问 S3 存储桶，请使用带有密钥和指令 `accessKey` 和 `secretKey` 的凭证来创建密文。它可以是任意一个命名空间。你可以点击[此处](#credentialsecret-示例)查看示例密文。如果运行 operator 的节点在 EC2 中，并且设置了允许它们访问 S3 的 IAM 权限，则此指令是不必要的（如[本节](#ec2-节点访问-s3-的-iam-权限)所述）。凭证密文下拉菜单列出了所有命名空间的密文。
|
||||
|
||||
+12
@@ -0,0 +1,12 @@
|
||||
---
|
||||
title: Rancher 备份配置参考
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/backup-restore-configuration"/>
|
||||
</head>
|
||||
|
||||
- [备份配置](backup-configuration.md)
|
||||
- [还原配置](restore-configuration.md)
|
||||
- [存储位置配置](storage-configuration.md)
|
||||
- [Backup 和 Restore 自定义资源示例](examples.md)
|
||||
+21
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: 最佳实践
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/best-practices"/>
|
||||
</head>
|
||||
|
||||
本节介绍 Rancher 实现的最佳实践，其中包括对 Kubernetes、Docker、容器等技术的使用建议。最佳实践旨在利用 Rancher 及其客户的运营经验，助你更好地实现 Rancher。
|
||||
|
||||
如果你对用例的实际应用有任何疑问，请联系客户成功经理或支持中心。
|
||||
|
||||
你可以在左侧导航栏快速找到管理和部署 Rancher Server 的最佳实践。
|
||||
|
||||
如需查看更多最佳实践指南，请参见：
|
||||
|
||||
- [安全类文档](../rancher-security/rancher-security.md)
|
||||
- [Rancher 博客](https://www.suse.com/c/rancherblog/)
|
||||
- [Rancher 论坛](https://forums.rancher.com/)
|
||||
- [Rancher 用户的 Slack 群组](https://slack.rancher.io/)
|
||||
- [B 站](https://space.bilibili.com/430496045/)
|
||||
+1
-1
@@ -86,7 +86,7 @@ Prometheus 不是用于长期存储指标的，它只用于短期存储。
|
||||
|
||||
如果你有一个（微）服务架构，在该架构中集群的多个单独的工作负载相互通信，那么拥有这些流量的详细指标和跟踪是非常重要的，因为这可以帮助你了解所有这些工作负载之间的通信方式，以及问题或瓶颈可能出现的地方。
|
||||
|
||||
当然，你可以监控所有工作负载中的所有内部流量，并将这些指标暴露给 Prometheus，但这相当耗费精力。像 Istio 这样的服务网格（可以通过[单击](https://rancher.com/docs/rancher/v2.6/en/istio/)在 Rancher 中安装）可以自动完成这项工作，并提供所有 Service 之间流量的丰富的遥测数据。
|
||||
当然，你可以监控所有工作负载中的所有内部流量，并将这些指标暴露给 Prometheus，但这相当耗费精力。像 Istio 这样的服务网格（可以通过[单击](../../../pages-for-subheaders/istio.md)在 Rancher 中安装）可以自动完成这项工作，并提供所有 Service 之间流量的丰富的遥测数据。
|
||||
|
||||
## 真实用户监控
|
||||
|
||||
|
||||
+23
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: Rancher 管理集群的最佳实践
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/best-practices/rancher-managed-clusters"/>
|
||||
</head>
|
||||
|
||||
### Logging
|
||||
|
||||
有关集群级别日志和应用日志的建议，请参见 [Logging 最佳实践](logging-best-practices.md)。
|
||||
|
||||
### Monitoring
|
||||
|
||||
配置合理的监控和告警规则对于安全、可靠地运行生产环境中的工作负载至关重要。有关更多建议，请参阅[最佳实践](monitoring-best-practices.md)。
|
||||
|
||||
### 设置容器的技巧
|
||||
|
||||
配置良好的容器可以极大地提高环境的整体性能和安全性。有关容器设置的建议，请参见[设置容器的技巧](tips-to-set-up-containers.md)。
|
||||
|
||||
### Rancher 管理 vSphere 集群的最佳实践
|
||||
|
||||
[Rancher 管理 vSphere 集群的最佳实践](rancher-managed-clusters-in-vsphere.md)概述了在 vSphere 环境中配置下游 Rancher 集群的参考架构，以及 VMware 记录的标准 vSphere 最佳实践。
|
||||
+21
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: Rancher Server 的最佳实践
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/best-practices/rancher-server"/>
|
||||
</head>
|
||||
|
||||
本指南介绍了让 Rancher 管理下游 Kubernetes 集群的 Rancher Server 运行建议。
|
||||
|
||||
### 推荐的架构和基础设施
|
||||
|
||||
有关在高可用 Kubernetes 集群上设置 Rancher Server 的通用建议，请参见[本指南](tips-for-running-rancher.md)。
|
||||
|
||||
### 部署策略
|
||||
|
||||
[本指南](rancher-deployment-strategy.md)旨在帮助你选择部署策略（区域部署/中心辐射型部署），来让 Rancher Server 更好地管理下游 Kubernetes 集群。
|
||||
|
||||
### 在 vSphere 环境中安装 Rancher
|
||||
|
||||
[本指南](on-premises-rancher-in-vsphere.md)介绍了在 vSphere 环境中安装 Rancher 的参考架构，以及 VMware 记录的标准 vSphere 最佳实践。
|
||||
+117
@@ -0,0 +1,117 @@
|
||||
---
|
||||
title: Rancher 大规模部署的调优和最佳实践
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/best-practices/rancher-server/tuning-and-best-practices-for-rancher-at-scale"/>
|
||||
</head>
|
||||
|
||||
本指南介绍了扩容 Rancher 相关场景的最佳实践和调优方法。随着系统规模的不断增长，性能自然会降低，但是可以采取一些步骤将 Rancher 的负载最小化，以优化 Rancher 管理较大基础设施的能力。
|
||||
|
||||
## 优化 Rancher 性能
|
||||
|
||||
* 及时升级 Rancher 的 Patch 更新。我们会不断的对 Rancher 进行性能增强和错误修复，最新的 Rancher 版本包含了基于开发人员和用户反馈的所有性能和稳定性的优化改进。
|
||||
* 逐渐的执行扩容操作，在操作的过程中观察并监控任何变化，在性能刚出现异常时发现问题并修复，避免其他干扰因素。
|
||||
* 尽可能地减少上游 Rancher 集群和下游集群之间的网络延时。需要注意的是，排除掉其他因素，延时与地理距离成正比，如果你的集群或节点分布在全球各地，请考虑改为安装多个 Rancher。
|
||||
|
||||
## 最小化上游集群的负载
|
||||
|
||||
在 Rancher 扩容时，一个典型的性能瓶颈是上游（local）Kubernetes 集群的资源增长。上游集群包含所有下游集群的数据信息，许多对下游集群的操作会在上游集群中创建新的对象，并需要在上游集群中进行计算处理。
|
||||
|
||||
### 最大限度地减少上游集群上的第三方软件
|
||||
|
||||
大规模运行 Rancher 可能会给内部 Kubernetes 组件（例如 `etcd` 或 `kubeapiserver`）带来大量负载。如果第三方软件干扰了这些组件或 Rancher 的性能，则可能会出现性能问题。
|
||||
|
||||
每个第三方软件都存在干扰性能的风险。为了防止上游集群出现性能问题，你应该避免运行除 Kubernetes 系统组件和 Rancher 本身之外的任何应用程序或组件。
|
||||
|
||||
以下类别的软件通常不会干扰 Rancher 或 Kubernetes 系统性能：
|
||||
* Rancher 内部组件，例如 Fleet
|
||||
* Rancher 扩展
|
||||
* 集群 API 组件
|
||||
* CNI 网络插件
|
||||
* 云控制器管理器
|
||||
* 观察和监控工具（`prometheus-rancher-exporter` 除外）
|
||||
|
||||
除此之外，已发现以下软件会在 Rancher 扩容时影响性能：
|
||||
* [CrossPlane](https://www.crossplane.io/)
|
||||
* [Argo CD](https://argoproj.github.io/cd/)
|
||||
* [Flux](https://fluxcd.io/)
|
||||
* [prometheus-rancher-exporter](https://github.com/David-VTUK/prometheus-rancher-exporter)（请参阅 [issue 33](https://github.com/David-VTUK/prometheus-rancher-exporter/issues/33)）
|
||||
|
||||
### 管理你的 Object 计数
|
||||
|
||||
Etcd 是 Kubernetes 和 Rancher 的后端数据库，该数据库可能会遇到单个 Kubernetes 资源类型数量的限制，确切的限制因素各不相同，取决于诸多因素。经验表明，一旦单个资源类型的对象数量超过 60000，通常会出现性能问题，通常该资源类型是 RoleBinding 对象。
|
||||
|
||||
这在 Rancher 中很常见，因为许多操作会在上游集群中创建新的 RoleBinding 对象。
|
||||
|
||||
你可以通过以下方法减少上游集群的 `RoleBinding` 数量：
|
||||
* 减少使用 [Restricted Admin（受限管理员）](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md#受限管理员) 角色，改为使用其他角色。
|
||||
* 如果你使用了 [外部认证](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md)，配置其按组分配角色。
|
||||
* 仅在必要情况下将用户添加到集群和项目中。
|
||||
* 移除不需要的集群和项目。
|
||||
* 仅在必要情况下使用自定义角色。
|
||||
* 在自定义角色中，尽可能的减少规则数量。
|
||||
* 避免为用户添加多余的角色。
|
||||
* 考虑使用数量更少，但性能更强大的集群。
|
||||
* Kubernetes 权限始终是 “附加”（允许列表）而不是“减去”（拒绝列表）。尽量减少允许访问集群、项目或命名空间等方面的配置，因为这将导致创建大量的 RoleBinding 对象。
|
||||
* 实验一下，创建新项目或集群后，在你的特定用例场景是否表现出更少的 RoleBinding 的效果。
|
||||
|
||||
### RoleBinding 计数估计
|
||||
|
||||
预测给定的配置将创建多少个 RoleBinding 对象很复杂，但是以下注意事项可以提供粗略的估算：
|
||||
* 对于最小的数量估计，请使用公式 `32C + U + 2UaC + 8P + 5Pa`。
|
||||
* `C` 是集群数量。
|
||||
* `U` 是用户数量。
|
||||
* `Ua` 是集群中具有成员资格的用户的平均数量。
|
||||
* `P` 是项目总数。
|
||||
* `Pa` 是项目中具有成员资格的平均用户数。
|
||||
* 受限管理员角色（Restricted Admin）遵循不同的公式，因为具有此角色的每个用户都会额外产生至少 `7C + 2P + 2` 个 `RoleBinding` 对象。
|
||||
* * `RoleBinding` 的数量会随着集群、项目和用户的数量线性增加。
|
||||
|
||||
### 使用新的应用代替旧版应用
|
||||
|
||||
Rancher 使用两个 Kubernetes 应用程序资源：`apps.projects.cattle.io` 和 `apps.cattle.cattle.io`。以`apps.projects.cattle.io` 为代表的旧版应用程序在低版本的 Cluster Manager UI 中引入，现已弃用。新的应用程序（由 `apps.catalog.cattle.io` 表示）可以在 Cluster Explorer UI 中安装部署。新的 `apps.cattle.cattle.io` 应用程序数据保存在下游集群中，这可以减少上游集群中的资源数量。
|
||||
|
||||
你应当删除 Cluster Manager UI 中遗留的所有旧版应用程序，并将其替换为 Cluster Explorer UI 中的应用程序。只在 Cluster Explorer UI 中创建任何新应用程序。
|
||||
|
||||
### 使用授权集群端点 (ACE)
|
||||
|
||||
[授权集群端点](../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-授权集群端点) (ACE) 提供了 Rancher 部署的 RKE、RKE2 和 K3s 集群的 Kubernetes API 访问。启用后，ACE 会为生成的 `kubeconfig` 文件配置直接访问下游集群 Endpoint，从而绕过 Rancher 代理。在可以直接访问下游集群 Kubernetes API 的场景下，可以减少 Rancher 负载。有关更多信息，请参阅[授权集群端点](../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-授权集群端点)配置说明。
|
||||
|
||||
### 减少 Event Handler 执行
|
||||
|
||||
Rancher 的大部分逻辑发生在 Event Handler 上。每当资源对象产生更新或 Rancher 启动时，这些资源对应的 Event Handler 都会执行。除此之外，它们会每隔 15 小时在 Rancher 计划的同步缓存时再运行一次，这可能会导致 Rancher 运行过程中出现大量性能消耗。可使用 `CATTLE_SYNC_ONLY_CHANGED_OBJECTS` 环境变量禁用计划的 Handler 处理程序执行。如果每 15 小时出现一次性能资源高峰，此设置会有所帮助。
|
||||
|
||||
`CATTLE_SYNC_ONLY_CHANGED_OBJECTS` 的值可被设置为以下内容，以逗号分隔。这些值代表了处理程序的种类，将处理程序添加到该变量会禁止其在定期的缓存重新同步过程中运行。
|
||||
|
||||
* `mgmt`：在 Rancher 节点上运行的 Management 管理控制器。
|
||||
* `user`：所有集群运行的用户控制器。其中一部分与 Management 管理控制器运行在同一节点上，而另一部分运行在下游集群中，该选项针对的是前者。
|
||||
* `scaled`：每个 Rancher 节点上运行的规模控制器。因规模控制器负责关键功能，应当避免设置此值。如果设置可能会破坏集群稳定。
|
||||
|
||||
简而言之，如果你发现 CPU 使用率每 15 小时出现一次峰值，请将 `CATTLE_SYNC_ONLY_CHANGED_OBJECTS` 环境变量添加到 Rancher Deployment 中（添加至 `spec.containers.env` 列表），其值为 `mgmt,user`。
|
||||
|
||||
## Rancher 之外的优化
|
||||
|
||||
集群底层自身的配置也是影响性能的重要因素。如果上游集群存在错误配置，会带来 Rancher 软件所无法解决的性能瓶颈。
|
||||
|
||||
### 使用 RKE2 直接管理上游集群节点
|
||||
|
||||
由于 Rancher 对上游集群的要求非常高，尤其是在大规模部署场景，你需要拥有上游集群和节点的所有管理员权限，要找出资源消耗过高的根本原因，请使用标准的 Linux 故障排除工具，这有助于区分是 Rancher、Kubernetes 还是操作系统组件出现的问题。
|
||||
|
||||
尽管托管 Kubernetes 服务使部署和运行 Kubernetes 集群变得更加容易，但在大规模场景中，不鼓励将其用于上游集群。 托管 Kubernetes 服务通常会限制对单个节点和服务配置的访问。
|
||||
|
||||
建议在大规模用例场景中使用 RKE2 集群。
|
||||
|
||||
### 及时更新 Kubernetes 版本
|
||||
|
||||
你应当及时更新上游集群的 Kubernetes 版本，以确保你的集群具备最新的性能增强和问题修复。
|
||||
|
||||
### 优化 Etcd
|
||||
|
||||
Etcd 是 Kubernetes 和 Rancher 的后端数据库，在 Rancher 性能中扮演重要的角色。
|
||||
|
||||
[Etcd 性能](https://etcd.io/docs/v3.4/op-guide/performance/)的两个主要瓶颈是磁盘和网络速度。Etcd 应当在具有高速网络和高读写速度 (IOPS) SSD 硬盘的专用节点上运行。有关 etcd 性能的更多信息，请参阅 [etcd 性能缓慢（性能测试和优化）](https://www.suse.com/support/kb/doc/?id=000020100)和[为大型安装进行 etcd 调优](../../../how-to-guides/advanced-user-guides/tune-etcd-for-large-installs.md)。有关磁盘的信息可以在[安装要求](../../../getting-started/installation-and-upgrade/installation-requirements/installation-requirements.md#磁盘)中找到。
|
||||
|
||||
根据 etcd 的[复制机制](https://etcd.io/docs/v3.5/faq/#what-is-maximum-cluster-size)，建议在三个节点上运行 etcd，运行在更多的节点上反而会降低速度。
|
||||
|
||||
Etcd 性能也会受节点之间的网络延迟影响，因此 etcd 节点应与 Rancher 节点部署在一起。
|
||||
+9
@@ -0,0 +1,9 @@
|
||||
---
|
||||
title: Rancher CLI
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/cli-with-rancher"/>
|
||||
</head>
|
||||
|
||||
Rancher CLI 是一个命令行工具，用于在工作站中与 Rancher 进行交互。以下文档将描述 [Rancher CLI](rancher-cli.md) 和 [kubectl实用程序](kubectl-utility.md)。
|
||||
+32
@@ -0,0 +1,32 @@
|
||||
---
|
||||
title: 集群配置
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/cluster-configuration"/>
|
||||
</head>
|
||||
|
||||
使用 Rancher 配置 Kubernetes 集群后，你仍然可以编辑集群的选项和设置。
|
||||
|
||||
有关编辑集群成员资格的信息，请转至[此页面](../../how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md)。
|
||||
|
||||
### 集群配置参考
|
||||
|
||||
集群配置选项取决于 Kubernetes 集群的类型：
|
||||
|
||||
- [RKE 集群配置](rancher-server-configuration/rke1-cluster-configuration.md)
|
||||
- [RKE2 集群配置](rancher-server-configuration/rke2-cluster-configuration.md)
|
||||
- [K3s 集群配置](rancher-server-configuration/k3s-cluster-configuration.md)
|
||||
- [EKS 集群配置](rancher-server-configuration/eks-cluster-configuration.md)
|
||||
- [GKE 集群配置](gke-cluster-configuration.md)
|
||||
- [AKS 集群配置](rancher-server-configuration/aks-cluster-configuration.md)
|
||||
|
||||
### 不同类型集群的管理功能
|
||||
|
||||
对于已有集群而言，可提供的选项和设置取决于你配置集群的方法。
|
||||
|
||||
下表总结了每一种类型的集群和对应的可编辑的选项和设置：
|
||||
|
||||
import ClusterCapabilitiesTable from '../../shared-files/_cluster-capabilities-table.md';
|
||||
|
||||
<ClusterCapabilitiesTable />
|
||||
+9
@@ -0,0 +1,9 @@
|
||||
---
|
||||
title: 下游集群配置
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/cluster-configuration/downstream-cluster-configuration"/>
|
||||
</head>
|
||||
|
||||
以下文档将讨论[节点模板配置](./node-template-configuration.md)和[主机配置](./machine-configuration.md)。
|
||||
+9
@@ -0,0 +1,9 @@
|
||||
---
|
||||
title: 主机配置
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/cluster-configuration/downstream-cluster-configuration/machine-configuration"/>
|
||||
</head>
|
||||
|
||||
主机配置指的是如何将资源分配给虚拟机。请参阅 [Amazon EC2](amazon-ec2.md)、[DigitalOcean](digitalocean.md) 和 [Azure](azure.md) 的文档以了解更多信息。
|
||||
+9
@@ -0,0 +1,9 @@
|
||||
---
|
||||
title: 节点模板配置
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration"/>
|
||||
</head>
|
||||
|
||||
要了解节点模板配置，请参阅[EC2 节点模板配置](amazon-ec2.md)、[DigitalOcean 节点模板配置](digitalocean.md)、[Azure 节点模板配置](azure.md)、[vSphere 节点模板配置](vsphere.md)和 [Nutanix 节点模板配置](nutanix.md)。
|
||||
+2
-2
@@ -13,7 +13,7 @@ title: vSphere 节点模板配置
|
||||
| 凭证字段 | 描述 |
|
||||
|-----------------|--------------|
|
||||
| vCenter 或 ESXi Server | 输入 vCenter 或 ESXi 主机名/IP。ESXi 是你创建和运行虚拟机和虚拟设备的虚拟化平台。你可以通过 vCenter Server 服务来管理网络中连接的多个主机并池化主机资源。 |
|
||||
| 端口 | 配置 vCenter 或 ESXi Server 的端口。 |
|
||||
| 端口 | 可选：配置 vCenter 或 ESXi Server 的端口。 |
|
||||
| 用户名和密码 | 你的 vSphere 登录用户名和密码。 |
|
||||
|
||||
## 调度
|
||||
@@ -92,4 +92,4 @@ title: vSphere 节点模板配置
|
||||
如果要配置 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`。
|
||||
:::
|
||||
:::
|
||||
+324
@@ -0,0 +1,324 @@
|
||||
---
|
||||
title: GKE 集群配置参考
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/cluster-configuration/rancher-server-configuration/gke-cluster-configuration"/>
|
||||
</head>
|
||||
|
||||
## Rancher 2.6 变更
|
||||
|
||||
- 支持额外的配置选项：
|
||||
- 项目网络隔离
|
||||
- 网络标签
|
||||
|
||||
## 集群位置
|
||||
|
||||
| 值 | 描述 |
|
||||
|--------|--------------|
|
||||
| 位置类型 | 地区 (zone) 或区域 (region)。借助 GKE，你可以根据工作负载的可用性要求和预算创建一个量身定制的集群。默认情况下，集群的节点在单个计算区域中运行。选择多个区域时，集群的节点将跨越多个计算区域，而 controlplane 则只位于单个区域中。区域集群也增加了 controlplane 的可用性。有关选择集群可用性类型的帮助，请参阅[这些文档](https://cloud.google.com/kubernetes-engine/docs/best-practices/scalability#choosing_a_regional_or_zonal_control_plane)。 |
|
||||
| 地区 | 计算引擎中的每个区域都包含多地区。有关可用区域和可用区的更多信息，请参阅[这些文档](https://cloud.google.com/compute/docs/regions-zones#available)。 |
|
||||
| 其他地区 | 对于地区性集群，你可以选择其他地区来创建[多地区集群](https://cloud.google.com/kubernetes-engine/docs/concepts/types-of-clusters#multi-zonal_clusters)。 |
|
||||
| 区域 | 对于[区域性集群](https://cloud.google.com/kubernetes-engine/docs/concepts/types-of-clusters#regional_clusters)，你可以选择一个区域。有关可用区域和可用区的更多信息，请参阅[本节](https://cloud.google.com/compute/docs/regions-zones#available)。地区名称的前面部分是区域的名称。 |
|
||||
|
||||
## 集群选项
|
||||
|
||||
### Kubernetes 版本
|
||||
|
||||
_可变：是_
|
||||
|
||||
有关 GKE Kubernetes 版本的更多信息，请参阅[这些文档](https://cloud.google.com/kubernetes-engine/versioning)。
|
||||
|
||||
### 容器地址范围
|
||||
|
||||
_可变：否_
|
||||
|
||||
集群中 Pod 的 IP 地址范围。必须是有效的 CIDR 范围，例如 10.42.0.0/16。如果未指定，则会自动从 10.0.0.0/8 中选择一个随机范围，并排除已分配给 VM、其他集群或路由的范围。自动选择的范围可能与预留的 IP 地址、动态路由或与集群对等的 VPC 中的路由发生冲突。
|
||||
|
||||
### 网络
|
||||
|
||||
_可变：否_
|
||||
|
||||
集群连接的 Compute Engine 网络。将使用此网络创建路由和防火墙。如果使用[共享 VPC](https://cloud.google.com/vpc/docs/shared-vpc)，与你的项目共享的 VPC 网络将显示在此处。你将可以在此字段中进行选择。有关详细信息，请参阅[此页面](https://cloud.google.com/vpc/docs/vpc#vpc_networks_and_subnets)。
|
||||
|
||||
### 节点子网/子网
|
||||
|
||||
_可变：否_
|
||||
|
||||
集群连接到的 Compute Engine 子网。该子网必须属于**网络**字段中指定的网络。选择一个现有的子网，或选择“自动创建子网”来自动创建一个子网。如果不使用现有网络，则需要使用**子网名称**来生成一个。如果使用[共享 VPC](https://cloud.google.com/vpc/docs/shared-vpc)，与你的项目共享的 VPC 子网将显示在此处。如果使用共享 VPC 网络，则无法选择“自动创建子网”。如需更多信息，请参阅[此页面](https://cloud.google.com/vpc/docs/vpc#vpc_networks_and_subnets)。
|
||||
|
||||
### 子网名称
|
||||
|
||||
_可变：否_
|
||||
|
||||
使用提供的名称自动创建子网。如果为**节点子网**或**子网**选择了“自动创建子网”，则为必填。有关子网的更多信息，请参阅[此页面](https://cloud.google.com/vpc/docs/vpc#vpc_networks_and_subnets)。
|
||||
|
||||
### IP 别名
|
||||
|
||||
_可变：否_
|
||||
|
||||
启用[别名 IP](https://cloud.google.com/vpc/docs/alias-ip)。这将启用 VPC 原生流量路由。如果使用[共享 VPC](https://cloud.google.com/vpc/docs/shared-vpc)，则为必填。
|
||||
|
||||
### 网络策略
|
||||
|
||||
_可变：是_
|
||||
|
||||
在集群上启用的网络策略。网络策略定义了集群中 pod 和 service 之间可以发生的通信级别。有关详细信息，请参阅[此页面](https://cloud.google.com/kubernetes-engine/docs/how-to/network-policy)。
|
||||
|
||||
### 项目网络隔离
|
||||
|
||||
_可变：是_
|
||||
|
||||
选择启用或禁用项目间通信。请注意，如果启用**项目网络隔离**，则将自动启用**网络策略**和**网络策略配置**，反之则不然。
|
||||
|
||||
### 节点 IPv4 CIDR 块
|
||||
|
||||
_可变：否_
|
||||
|
||||
此集群中实例 IP 的 IP 地址范围。如果为**节点子网**或**子网**选择了“自动创建子网”，则可以进行设置。必须是有效的 CIDR 范围，例如 10.96.0.0/14。有关如何确定 IP 地址范围的详细信息，请参阅[此页面](https://cloud.google.com/kubernetes-engine/docs/concepts/alias-ips#cluster_sizing)。
|
||||
|
||||
### 集群次要范围名称
|
||||
|
||||
_可变：否_
|
||||
|
||||
Pod IP 地址的现有次要范围的名称。如果选中，将自动填充**集群 Pod 地址范围**。如果使用共享 VPC 网络，则为必填。
|
||||
|
||||
### 集群 Pod 地址范围
|
||||
|
||||
_可变：否_
|
||||
|
||||
分配给集群中 pod 的 IP 地址范围。必须是有效的 CIDR 范围，例如 10.96.0.0/11。如果未提供，将自动创建。如果使用共享 VPC 网络，则必须提供。有关如何确定 pod 的 IP 地址范围的更多信息，请参阅[本节](https://cloud.google.com/kubernetes-engine/docs/concepts/alias-ips#cluster_sizing_secondary_range_pods)。
|
||||
|
||||
### Service 次要范围名称
|
||||
|
||||
_可变：否_
|
||||
|
||||
Service IP 地址的现有次要范围的名称。如果选中，将自动填充 **Service 地址范围**。如果使用共享 VPC 网络，则为必填。
|
||||
|
||||
### Service 地址范围
|
||||
|
||||
_可变：否_
|
||||
|
||||
分配给集群中 Service 的地址范围。必须是有效的 CIDR 范围，例如 10.94.0.0/18。如果未提供，将自动创建。如果使用共享 VPC 网络，则必须提供。有关如何确定 Service 的 IP 地址范围的详细信息，请参阅[本节](https://cloud.google.com/kubernetes-engine/docs/concepts/alias-ips#cluster_sizing_secondary_range_svcs)。
|
||||
|
||||
### 私有集群
|
||||
|
||||
_可变：否_
|
||||
|
||||
:::caution
|
||||
|
||||
私有集群需要在 Rancher 之外进行额外的规划和配置。请参阅[私有集群指南](gke-private-clusters.md)。
|
||||
|
||||
:::
|
||||
|
||||
仅分配节点内部 IP 地址。除非在 GCP 中执行了额外的联网步骤，否则私有集群节点无法访问公共互联网。
|
||||
|
||||
### 启用私有端点
|
||||
|
||||
:::caution
|
||||
|
||||
私有集群需要在 Rancher 之外进行额外的规划和配置。请参阅[私有集群指南](gke-private-clusters.md)。
|
||||
|
||||
:::
|
||||
|
||||
_可变：否_
|
||||
|
||||
锁定对 controlplane 端点的外部访问。仅当**私有集群**也被选中时可用。如果选中，并且 Rancher 无法直接访问集群所在的虚拟私有云网络，Rancher 将提供在集群上运行的注册命令，以使 Rancher 能够连接到集群。
|
||||
|
||||
### 主 IPV4 CIDR 块
|
||||
|
||||
_可变：否_
|
||||
|
||||
controlplane VPC 的 IP 范围。
|
||||
|
||||
### 主授权网络
|
||||
|
||||
_可变：是_
|
||||
|
||||
启用 controlplane 授权网络，以阻止不受信任的非 GCP 源 IP 通过 HTTPS 访问 Kubernetes master。如果选择，则可以添加额外的授权网络。如果集群是使用公共端点创建的，则此选项可用于将公共端点的访问锁定到特定网络（例如运行 Rancher 服务的网络）。如果集群只有一个私有端点，则需要此设置。
|
||||
|
||||
## 其他选项
|
||||
|
||||
### 集群插件
|
||||
|
||||
其他 Kubernetes 集群组件。有关详细信息，请参阅[此页面](https://cloud.google.com/kubernetes-engine/docs/reference/rest/v1/projects.locations.clusters#Cluster.AddonsConfig)。
|
||||
|
||||
#### 水平 Pod 自动缩放
|
||||
|
||||
_可变：是_
|
||||
|
||||
Horizontal Pod Autoscaler 通过自动增加或减少 Pod 的数量来调整 Kubernetes 工作负载，从而响应工作负载的 CPU 或内存消耗，以及 Kubernetes 内部报告的自定义指标或集群外部设置的指标。详情请参见[本页面](https://cloud.google.com/kubernetes-engine/docs/concepts/horizontalpodautoscaler)。
|
||||
|
||||
#### HTTP (L7) 负载均衡
|
||||
|
||||
_可变：是_
|
||||
|
||||
HTTP (L7) 负载均衡将 HTTP 和 HTTPS 流量分配到托管在 GKE 上的后端。有关详细信息，请参阅[此页面](https://cloud.google.com/kubernetes-engine/docs/tutorials/http-balancer)。
|
||||
|
||||
#### 网络策略配置（仅限 master）
|
||||
|
||||
_可变：是_
|
||||
|
||||
NetworkPolicy 的配置。仅跟踪 master 节点上是否启用了插件，不跟踪是否为节点启用了网络策略。
|
||||
|
||||
### 集群特征（Alpha 功能）
|
||||
|
||||
_可变：否_
|
||||
|
||||
打开集群的所有 Kubernetes alpha API 组和功能。启用后，集群无法升级，并且会在 30 天后自动删除。由于 GKE SLA 未支持 alpha 集群，因此不建议将 Alpha 集群用于生产环境。有关详细信息，请参阅[此页面](https://cloud.google.com/kubernetes-engine/docs/concepts/alpha-clusters)。
|
||||
|
||||
### Logging 服务
|
||||
|
||||
_可变：是_
|
||||
|
||||
集群用于写入日志的日志管理服务。要么使用 [Cloud Logging](https://cloud.google.com/logging)，要么不使用日志管理服务（不会从集群中导出日志）。
|
||||
|
||||
### 监控服务
|
||||
|
||||
_可变：是_
|
||||
|
||||
集群用于写入指标的监控服务。要么使用 [Cloud Monitoring](https://cloud.google.com/monitoring)，要么不使用集群监控服务（不会从集群中导出指标）。
|
||||
|
||||
|
||||
### 维护窗口
|
||||
|
||||
_可变：是_
|
||||
|
||||
设置时长 4 小时的维护窗口的开始时间。使用 HH:MM 格式在 UTC 时区中指定时间。有关详细信息，请参阅[此页面](https://cloud.google.com/kubernetes-engine/docs/concepts/maintenance-windows-and-exclusions)。
|
||||
|
||||
## 节点池
|
||||
|
||||
在此部分中，输入描述节点池中每个节点的配置的详细信息。
|
||||
|
||||
### Kubernetes 版本
|
||||
|
||||
_可变：是_
|
||||
|
||||
节点池中每个节点的 Kubernetes 版本。有关 GKE Kubernetes 版本的更多信息，请参阅[这些文档](https://cloud.google.com/kubernetes-engine/versioning)。
|
||||
|
||||
### 镜像类型
|
||||
|
||||
_可变：是_
|
||||
|
||||
节点操作系统镜像。有关 GKE 为每个操作系统提供的节点镜像选项，请参阅[此页面](https://cloud.google.com/kubernetes-engine/docs/concepts/node-images#available_node_images)。
|
||||
|
||||
:::note
|
||||
|
||||
默认选项是 “Container-Optimized OS with Docker”。GCP Container-Optimized OS 上的只读文件系统与 Rancher 中的 [legacy logging](/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-logging/cluster-logging.md) 实现不兼容。如果你需要使用旧版日志管理功能，请选择 “Ubuntu with Docker” 或 “Ubuntu with Containerd”。[current logging feature](../../../../integrations-in-rancher/logging/logging.md) 与 Container-Optimized OS 镜像兼容。
|
||||
|
||||
:::
|
||||
|
||||
:::note
|
||||
|
||||
如果节点池镜像类型选择 “Windows Long Term Service Channel” 或 “Windows Semi-Annual Channel”，还必须至少添加一个 Container-Optimized OS 或 Ubuntu 节点池。
|
||||
|
||||
:::
|
||||
|
||||
### 主机类型
|
||||
|
||||
_可变：否_
|
||||
|
||||
节点实例可用的虚拟化硬件资源。有关 Google Cloud 主机类型的详细信息，请参阅[此页面](https://cloud.google.com/compute/docs/machine-types#machine_types)。
|
||||
|
||||
### 根磁盘类型
|
||||
|
||||
_可变：否_
|
||||
|
||||
标准永久性磁盘由标准磁盘驱动器 (HDD) 支持，而 SSD 永久性磁盘由固态硬盘 (SSD) 支持。有关详细信息，请参阅[本节](https://cloud.google.com/compute/docs/disks)。
|
||||
|
||||
### 本地 SSD 磁盘
|
||||
|
||||
_可变：否_
|
||||
|
||||
配置每个节点的本地 SSD 磁盘存储（以 GB 为单位）。本地 SSD 物理连接到托管你的 VM 实例的服务器。与标准永久性磁盘或 SSD 永久性磁盘相比，本地 SSD 具有更高的吞吐量和更低的延迟。存储在本地 SSD 上的数据只会保留到实例停止或删除。有关详细信息，请参阅[本节](https://cloud.google.com/compute/docs/disks#localssds)。
|
||||
|
||||
### 抢占式节点（beta）
|
||||
|
||||
_可变：否_
|
||||
|
||||
抢占式节点也称为抢占式虚拟机。通常是最长持续 24 小时的 Compute Engine 虚拟机实例，不提供可用性保证。详情请参见[本页面](https://cloud.google.com/kubernetes-engine/docs/how-to/preemptible-vms)。
|
||||
|
||||
### 污点
|
||||
|
||||
_可变：否_
|
||||
|
||||
将污点应用于节点时，仅允许容忍该污点的 Pod 在该节点上运行。在 GKE 集群中，你可以将污点应用到节点池，这会将污点应用到池中的所有节点。
|
||||
|
||||
### 节点标签
|
||||
|
||||
_可变：否_
|
||||
|
||||
你可以将标签应用到节点池，这会将标签应用到池中的所有节点。
|
||||
|
||||
无效标签会阻止升级，或阻止 Rancher 启动。有关标签语法的详细信息，请参阅 [Kubernetes 文档](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)。
|
||||
|
||||
### 网络标签
|
||||
|
||||
_可变：否_
|
||||
|
||||
你可以将网络标签添加到节点池以制定防火墙规则和子网之间的路由。标签将应用于池中的所有节点。
|
||||
|
||||
有关标签语法和要求的详细信息，请参阅 [Kubernetes 文档](https://cloud.google.com/vpc/docs/add-remove-network-tags)。
|
||||
|
||||
## 组详细信息
|
||||
|
||||
在此部分中，输入描述节点池的详细信息。
|
||||
|
||||
### 名称
|
||||
|
||||
_可变：否_
|
||||
|
||||
输入节点池的名称。
|
||||
|
||||
### 初始节点数
|
||||
|
||||
_可变：是_
|
||||
|
||||
节点池中初始节点数的整数。
|
||||
|
||||
### 每个节点的最大 Pod 数量
|
||||
|
||||
_可变：否_
|
||||
|
||||
GKE 的硬性限制是每个节点 110 个 Pod。有关 Kubernetes 限制的更多信息，请参阅[本节](https://cloud.google.com/kubernetes-engine/docs/best-practices/scalability#dimension_limits)。
|
||||
|
||||
### 自动缩放
|
||||
|
||||
_可变：是_
|
||||
|
||||
节点池自动缩放会根据工作负载的需求动态创建或删除节点。详情请参见[本页面](https://cloud.google.com/kubernetes-engine/docs/concepts/cluster-autoscaler)。
|
||||
|
||||
### 自动修复
|
||||
|
||||
_可变：是_
|
||||
|
||||
GKE 的节点自动修复功能可帮助你将集群中的节点保持在健康的运行状态。启用后，GKE 会定期检查集群中每个节点的运行状况。如果某个节点在较长时间段内连续未通过健康检查，GKE 会为该节点启动修复过程。有关详细信息，请参阅[自动修复节点](https://cloud.google.com/kubernetes-engine/docs/how-to/node-auto-repair)。
|
||||
|
||||
### 自动升级
|
||||
|
||||
_可变：是_
|
||||
|
||||
启用后，当你的 controlplane [按照你的需求更新](https://cloud.google.com/kubernetes-engine/upgrades#automatic_cp_upgrades)时，自动升级功能会使集群中的节点与集群 controlplane（master）版本保持同步。有关自动升级节点的更多信息，参见[此页面。](https://cloud.google.com/kubernetes-engine/docs/how-to/node-auto-upgrades)
|
||||
|
||||
### 访问范围
|
||||
|
||||
_可变：否_
|
||||
|
||||
设置访问范围是为你的节点指定权限的旧版方法。
|
||||
|
||||
- **允许默认访问**：新集群的默认访问是 [Compute Engine 默认 ServiceAccount](https://cloud.google.com/compute/docs/access/service-accounts?hl=en_US#default_service_account)。
|
||||
- **允许完全访问所有 Cloud API**：通常，你只需设置云平台访问范围来允许完全访问所有 Cloud API，然后仅授予 ServiceAccount 相关的 IAM 角色。授予虚拟机实例的访问范围和授予 ServiceAccount 的 IAM 角色的组合决定了 ServiceAccount 对该实例的访问量。
|
||||
- **为每个 API 设置访问权限**：或者，你可以设置服务将调用的特定 API 方法的访问范围。
|
||||
|
||||
有关详细信息，请参阅[为 VM 启用 ServiceAccount](https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances)。
|
||||
|
||||
|
||||
### 配置刷新间隔
|
||||
|
||||
刷新间隔可以通过 “gke-refresh” 来配置，它是一个代表秒的整数。
|
||||
|
||||
默认值为 300 秒。
|
||||
|
||||
你可以通过运行 `kubectl edit setting gke-refresh` 来更改同步间隔。
|
||||
|
||||
刷新窗口越短，争用条件发生的可能性就越小。但这确实增加了遇到 GCP API 可能存在的请求限制的可能性。
|
||||
+1
-1
@@ -26,7 +26,7 @@ Cloud NAT 将[产生费用](https://cloud.google.com/nat/pricing)。
|
||||
|
||||
:::
|
||||
|
||||
如果要求限制节点的传入和传出流量，请按照离线安装说明，在集群所在的 VPC 上设置一个私有容器[镜像仓库](https://rancher.com/docs/rancher/v2.6/en/installation/other-installation-methods/air-gap/)，从而允许集群节点访问和下载运行 cluster agent 所需的镜像。如果 controlplane 端点也是私有的，Rancher 将需要[直接访问](#直接访问)它。
|
||||
如果要求限制节点的传入和传出流量，请按照离线安装说明，在集群所在的 VPC 上设置一个私有容器[镜像仓库](../../../../pages-for-subheaders/air-gapped-helm-cli-install.md)，从而允许集群节点访问和下载运行 cluster agent 所需的镜像。如果 controlplane 端点也是私有的，Rancher 将需要[直接访问](#直接访问)它。
|
||||
|
||||
### 私有 controlplane 端点
|
||||
|
||||
|
||||
+16
@@ -0,0 +1,16 @@
|
||||
---
|
||||
title: Rancher Server Configuration
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/cluster-configuration/rancher-server-configuration"/>
|
||||
</head>
|
||||
|
||||
- [RKE1 集群配置](rke1-cluster-configuration.md)
|
||||
- [RKE2 集群配置](rke2-cluster-configuration.md)
|
||||
- [K3s 集群配置](k3s-cluster-configuration.md)
|
||||
- [EKS 集群配置](eks-cluster-configuration.md)
|
||||
- [AKS 集群配置](aks-cluster-configuration.md)
|
||||
- [GKE 集群配置](gke-cluster-configuration/gke-cluster-configuration.md)
|
||||
- [使用现有节点](use-existing-nodes/use-existing-nodes.md)
|
||||
- [同步集群](sync-clusters.md)
|
||||
+1
-1
@@ -160,7 +160,7 @@ Rancher 与以下开箱即用的网络提供商兼容：
|
||||
|
||||
### Agent 环境变量
|
||||
|
||||
为 [Rancher agent](https://rancher.com/docs/rancher/v2.6/en/cluster-provisioning/rke-clusters/rancher-agents/) 设置环境变量的选项。你可以使用键值对设置环境变量。有关详细信息，请参阅 [RKE2 文档](https://docs.rke2.io/reference/linux_agent_config)。
|
||||
为 [Rancher agent](../../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/about-rancher-agents.md) 设置环境变量的选项。你可以使用键值对设置环境变量。有关详细信息，请参阅 [RKE2 文档](https://docs.rke2.io/reference/linux_agent_config)。
|
||||
|
||||
### etcd
|
||||
|
||||
|
||||
+141
@@ -0,0 +1,141 @@
|
||||
---
|
||||
title: 在现有自定义节点上启动 Kubernetes
|
||||
description: 要创建具有自定义节点的集群，你需要访问集群中的服务器，并根据 Rancher 的要求配置服务器。
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/cluster-configuration/rancher-server-configuration/use-existing-nodes"/>
|
||||
</head>
|
||||
|
||||
创建自定义集群时，Rancher 使用 RKE（Rancher Kubernetes Engine）在本地裸机服务器、本地虚拟机或云服务器节点中创建 Kubernetes 集群。
|
||||
|
||||
要使用此选项，你需要访问要在 Kubernetes 集群中使用的服务器。请根据[要求](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md)配置每台服务器，其中包括硬件要求和 Docker 要求。在每台服务器上安装 Docker 后，你还需要在每台服务器上运行 Rancher UI 中提供的命令，从而将每台服务器转换为 Kubernetes 节点。
|
||||
|
||||
本节介绍如何设置自定义集群。
|
||||
|
||||
## 使用自定义节点创建集群
|
||||
|
||||
:::note 使用 Windows 主机作为 Kubernetes Worker 节点？
|
||||
|
||||
在开始之前，请参阅[配置 Windows 自定义集群](use-windows-clusters.md)。
|
||||
|
||||
:::
|
||||
|
||||
### 1. 配置 Linux 主机
|
||||
|
||||
你可以通过配置 Linux 主机，来创建自定义集群。你的主机可以是：
|
||||
|
||||
- 云虚拟机
|
||||
- 本地虚拟机
|
||||
- 裸机服务器
|
||||
|
||||
如果要重复使用之前的自定义集群中的节点，请在复用之前[清理节点](../../../../how-to-guides/new-user-guides/manage-clusters/clean-cluster-nodes.md)。如果你重复使用尚未清理的节点，则集群配置可能会失败。
|
||||
|
||||
根据[安装要求](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md)和[生产就绪集群的检查清单](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/checklist-for-production-ready-clusters/checklist-for-production-ready-clusters.md)配置主机。
|
||||
|
||||
如果你使用 Amazon EC2 作为主机，并希望使用[双栈 (dual-stack)](https://kubernetes.io/docs/concepts/services-networking/dual-stack/) 功能，则需要满足配置主机的其他[要求](https://rancher.com/docs/rke//latest/en/config-options/dual-stack#requirements)。
|
||||
|
||||
### 2. 创建自定义集群
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，单击**创建**。
|
||||
1. 单击**自定义**。
|
||||
1. 输入**集群名称**。
|
||||
1. 在**集群配置**中，选择 Kubernetes 版本、要使用的网络提供商，以及是否启用项目网络隔离。要查看更多集群选项，请单击**显示高级选项**。
|
||||
|
||||
:::note 你使用 Windows 主机作为 Kubernetes Worker 节点？
|
||||
|
||||
- 请参阅[启用 Windows 支持选项](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/use-windows-clusters/use-windows-clusters.md)。
|
||||
- 支持 Windows 集群的唯一网络插件是 Flannel。
|
||||
|
||||
:::
|
||||
|
||||
:::note Amazon EC2 上的双栈：
|
||||
|
||||
如果你使用 Amazon EC2 作为主机，并希望使用[双栈 (dual-stack)](https://kubernetes.io/docs/concepts/services-networking/dual-stack/) 功能，则需要满足配置 RKE 的其他[要求](https://rancher.com/docs/rke//latest/en/config-options/dual-stack#requirements)。
|
||||
|
||||
:::
|
||||
|
||||
6. 点击**下一步**。
|
||||
|
||||
4. 使用**成员角色**为集群配置用户授权。点击**添加成员**添加可以访问集群的用户。使用**角色**下拉菜单为每个用户设置权限。
|
||||
|
||||
7. 从**节点角色**中，选择要由集群节点充当的角色。你必须为 `etcd`、`worker` 和 `controlplane` 角色配置至少一个节点。自定义集群需要所有三个角色才能完成配置。有关角色的详细信息，请参阅[本节](../../../kubernetes-concepts.md#kubernetes-集群中节点的角色)。
|
||||
|
||||
:::note
|
||||
|
||||
- 使用 Windows 主机作为 Kubernetes Worker 节点？请参阅[本节](../../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/use-windows-clusters/use-windows-clusters.md)。
|
||||
- 裸机服务器提醒：如果你想将裸机服务器专用于每个角色，则必须为每个角色配置一个裸机服务器（即配置多个裸机服务器）。
|
||||
|
||||
:::
|
||||
|
||||
8. **可选**：点击[显示高级选项](../../../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/about-rancher-agents.md)来指定注册节点时使用的 IP 地址，覆盖节点的主机名，或将[标签](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)或[污点](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/)添加到节点。
|
||||
|
||||
9. 将屏幕上显示的命令复制到剪贴板。
|
||||
|
||||
10. 使用你惯用的 shell（例如 PuTTy 或远程终端）登录到你的 Linux 主机。粘贴剪贴板的命令并运行。
|
||||
|
||||
:::note
|
||||
|
||||
如果要将特定主机专用于特定节点角色，请重复步骤 7-10。根据需要多次重复这些步骤。
|
||||
|
||||
:::
|
||||
|
||||
11. 在 Linux 主机上运行完命令后，单击**完成**。
|
||||
|
||||
**结果**：
|
||||
|
||||
你已创建集群，集群的状态是**配置中**。Rancher 已在你的集群中。
|
||||
|
||||
当集群状态变为 **Active** 后，你可访问集群。
|
||||
|
||||
**Active** 状态的集群会分配到两个项目：
|
||||
|
||||
- `Default`：包含 `default` 命名空间
|
||||
- `System`：包含 `cattle-system`，`ingress-nginx`，`kube-public` 和 `kube-system` 命名空间。
|
||||
|
||||
|
||||
### 3. 仅限亚马逊：标签资源
|
||||
|
||||
如果你已将集群配置为使用 Amazon 作为**云提供商**，请使用集群 ID 标记你的 AWS 资源。
|
||||
|
||||
[Amazon 文档：标记你的 Amazon EC2 资源](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html)
|
||||
|
||||
:::note
|
||||
|
||||
你可以使用 Amazon EC2 实例，而无需在 Kubernetes 中配置云提供商。如果你想使用特定的 Kubernetes 云提供商功能，配置云提供商即可。如需更多信息，请参阅 [Kubernetes 云提供商](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/)。
|
||||
|
||||
:::
|
||||
|
||||
以下资源需要使用 `ClusterID` 进行标记：
|
||||
|
||||
- **Nodes**：Rancher 中添加的所有主机。
|
||||
- **Subnet**：集群使用的子网。
|
||||
- **Security Group**：用于你的集群的安全组。
|
||||
|
||||
:::note
|
||||
|
||||
不要标记多个安全组。创建 Elastic Load Balancer 时，标记多个组会导致错误。
|
||||
|
||||
:::
|
||||
|
||||
应该使用的标签是：
|
||||
|
||||
```
|
||||
Key=kubernetes.io/cluster/<CLUSTERID>, Value=owned
|
||||
```
|
||||
|
||||
`<CLUSTERID>` 可以是你选择的任何字符串。但是，必须在你标记的每个资源上使用相同的字符串。将值设置为 `owned` 会通知集群所有带有 `<CLUSTERID>` 标记的资源都由该集群拥有和管理。
|
||||
|
||||
如果你在集群之间共享资源，你可以将标签更改为：
|
||||
|
||||
```
|
||||
Key=kubernetes.io/cluster/CLUSTERID, Value=shared
|
||||
```
|
||||
|
||||
## 可选的后续步骤
|
||||
|
||||
创建集群后，你可以通过 Rancher UI 访问集群。最佳实践建议你设置以下访问集群的备用方式：
|
||||
|
||||
- **通过 kubectl CLI 访问你的集群**：按照[这些步骤](../../../../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#accessing-clusters-with-kubectl-from-your-workstation)在你的工作站上使用 kubectl 访问集群。在这种情况下，你将通过 Rancher Server 的认证代理进行认证，然后 Rancher 会让你连接到下游集群。此方法允许你在没有 Rancher UI 的情况下管理集群。
|
||||
- **通过 kubectl CLI 使用授权的集群端点访问你的集群**：按照[这些步骤](../../../../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster)直接使用 kubectl 访问集群，而无需通过 Rancher 进行认证。我们建议设置此替代方法来访问集群，以便在无法连接到 Rancher 时访问集群。
|
||||
+15
@@ -0,0 +1,15 @@
|
||||
---
|
||||
title: Monitoring V2 配置
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/monitoring-v2-configuration"/>
|
||||
</head>
|
||||
|
||||
以下将说明在 Rancher 中如何配置 Monitoring V2 的基本重要选项：
|
||||
|
||||
- [接收器配置](receivers.md)
|
||||
- [路由配置](routes.md)
|
||||
- [ServiceMonitor 和 PodMonitor 配置](servicemonitors-and-podmonitors.md)
|
||||
- [Helm Chart 选项](helm-chart-options.md)
|
||||
- [示例](examples.md)
|
||||
+1
-1
@@ -42,7 +42,7 @@ Alerting Drivers 为 Alertmanager 将告警代理到非原生接收器，例如
|
||||
|
||||
| 字段 | 默认 | 描述 |
|
||||
|-------|--------------|---------|
|
||||
| 分组依据 | N/A | 用于分组的标签列表。标签必须是唯一的。如果提供了特殊标签“...”（由所有可能的标签聚合），标签必须在列表中是唯一的元素。接受字符串列表。有关详细信息，请参阅[上游文档](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api.md#route)。 |
|
||||
| 分组依据 | N/A | 用于分组的标签列表。所有标签都必须是唯一的。如果提供了特殊标签“...”（由所有可能的标签聚合），标签必须在列表中是唯一的元素。接受字符串列表。有关详细信息，请参阅[上游文档](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api.md#route)。 |
|
||||
| 组等待时长 | 30s | 在发送之前，缓冲同一组告警的等待时间。 |
|
||||
| 组间隔 | 5m | 等待多长时间才发送已添加到告警组的告警，其中该告警组的初次通知已被发送。 |
|
||||
| 重复间隔 | 4h | 等待多长时间后，才重新发送已发送的告警。 |
|
||||
|
||||
+109
@@ -0,0 +1,109 @@
|
||||
---
|
||||
title: Prometheus Federator
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/prometheus-federator"/>
|
||||
</head>
|
||||
|
||||
Prometheus Federator（也称为 Project Monitoring V2）基于 [rancher/helm-project-operator](https://github.com/rancher/helm-project-operator) 部署一个 Helm Project Operator。该 Operator 管理 Helm Chart 的部署，每个 Operator 都包含一个 Project Monitoring Stack，而每个堆栈都包含：
|
||||
|
||||
- [Prometheus](https://prometheus.io/)（由 [Prometheus Operator](https://github.com/prometheus-operator/prometheus-operator) 在外部管理）
|
||||
- [Alertmanager](https://prometheus.io/docs/alerting/latest/alertmanager/)（由 [Prometheus Operator](https://github.com/prometheus-operator/prometheus-operator) 在外部管理）
|
||||
- [Grafana](https://github.com/helm/charts/tree/master/stable/grafana)（通过嵌入式 Helm Chart 部署）
|
||||
- 基于 [kube-prometheus](https://github.com/prometheus-operator/kube-prometheus/) 社区策划资源集合的默认 PrometheusRules 和 Grafana 仪表板
|
||||
- 监视已部署资源的默认 ServiceMonitor
|
||||
|
||||
:::note 重要提示：
|
||||
|
||||
Prometheus Federator 适合在已安装 Prometheus Operator CRD 的集群中与现有的 Prometheus Operator Deployment 一起部署。
|
||||
|
||||
:::
|
||||
|
||||
## Operator 工作原理
|
||||
|
||||
1. 在部署此 Chart 时，用户可以创建 ProjectHelmCharts CR，并在**项目 Registration 命名空间 (`cattle-project-<id>`)** 中将 `spec.helmApiVersion` 设置为 `monitoring.cattle.io/v1alpha1`（在 Rancher UI 中也称为“项目监控”）。
|
||||
2. 在看到每个 ProjectHelmChartCR 时，Operator 会代表项目所有者在**项目 Release 命名空间 (`cattle-project-<id>-monitoring`)** 中自动部署一个 Project Prometheus 堆栈（基于 ProjectHelmChart 控制器在 **Operator / System Namespace** 中创建的 HelmChart CR 和 HelmRelease CR）。
|
||||
3. RBAC 将自动分配到项目 Release 命名空间中，从而允许用户查看 Prometheus、Alertmanager 以及已部署的 Project Monitoring Stack 的 Grafana UI（基于在项目 Registration 命名空间上针对[面向用户的默认 Kubernetes 角色](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)定义的 RBAC）。有关详细信息，请参阅[配置 RBAC](rbac.md)。
|
||||
|
||||
### 什么是项目？
|
||||
|
||||
在 Prometheus Federator 中，项目是一组可以由 `metav1.LabelSelector` 标识的命名空间。默认情况下，用于标识项目的标签是 `field.cattle.io/projectId`，该标签用于标识给定 Rancher 项目中包含的命名空间。
|
||||
|
||||
### 配置由 ProjectHelmChart 创建的 Helm 版本
|
||||
|
||||
此 ProjectHelmChart 资源的 `spec.values` 对应于为底层 Helm Chart 配置的 `values.yaml` 覆盖，该 Helm Chart 是 Operator 代表用户部署的。要查看底层 Chart 的 `values.yaml` 规范，你可以选择以下其中一种方式：
|
||||
|
||||
- 查看位于 [`charts/rancher-project-monitoring` 中的 `rancher/prometheus-federator`](https://github.com/rancher/prometheus-federator/blob/main/charts/rancher-project-monitoring) 的 Chart 定义（Chart 版本会绑定到 Operator 版本）。
|
||||
- 查找在每个项目 Registration 命名空间中自动创建的名为 `monitoring.cattle.io.v1alpha1` 的 ConfigMap，其中包含用于配置 Chart（直接嵌入到 `prometheus-federator` 二进制文件中）的`values.yaml` 和 `questions.yaml`。
|
||||
|
||||
### 命名空间
|
||||
|
||||
Prometheus Federator 是基于 [rancher/helm-project-operator](https://github.com/rancher/helm-project-operator) 的 Project Operator，Prometheus Federator 提供了三类命名空间供 Operator 查找：
|
||||
|
||||
1. **Operator / System 命名空间**：部署 Operator 的命名空间（例如 `cattle-monitoring-system`）。此命名空间将包含该 Operator 监视的所有 ProjectHelmChart 的所有 HelmChart 和 HelmRelease。**只有集群管理员才能访问此命名空间**。
|
||||
|
||||
2. **项目 Registration 命名空间 (`cattle-project-<id>`)**：Operator 在这些命名空间中监视 ProjectHelmChart。对于在项目发布命名空间中创建的自动分配的 RBAC，应用于此命名空间的 RoleBinding 和 ClusterRoleBinding 也会作为 RBAC 的真实来源。有关详细信息，请参阅 [RBAC 页面](rbac.md)。**项目所有者（admin）、项目成员（edit）和只读成员（view）应该有权访问此命名空间。**
|
||||
|
||||
:::note 注意事项：
|
||||
|
||||
- 如果提供了 `.Values.global.cattle.projectLabel`（默认设置为 `field.cattle.io/projectId`），则 Operator 会自动生成项目注册命名空间，并将它导入到命名空间绑定的项目中。换言之，如果观察到至少一个带有该标签的命名空间，则 Operator 会创建一个项目 Registration 命名空间。除非出现以下两种情况，否则 Operator 不会让这些命名空间被删除。第一种情况是带有该标签的所有命名空间都消失了（例如，这是该项目中的最后一个命名空间，在这种情况下，命名空间将标有标签 `"helm.cattle.io/helm-project-operator-orphaned": "true"`，表示可以删除）。第二种情况是由于项目 ID 是在 `.Values.helmProjectOperator.otherSystemProjectLabelValues` 下提供的（用作项目的拒绝名单），导致 Operator 不再监视该项目。这些命名空间不会被自动删除，这样能避免破坏用户数据。如果需要，建议用户在创建或删除项目时手动清理这些命名空间。
|
||||
|
||||
- 如果未提供 `.Values.global.cattle.projectLabel`，则 Operator / System 命名空间也是项目注册命名空间。
|
||||
|
||||
:::
|
||||
|
||||
3. **项目发布命名空间（`cattle-project-<id>-monitoring`）**：Operator 代表 ProjectHelmChart 在其中部署项目监控堆栈的命名空间集。Operator 还将根据在项目 Registration 命名空间中找到的绑定，自动为项目监控堆栈在此命名空间中创建的角色分配 RBAC。**只有集群管理员才能访问这个命名空间。部署的 Helm Chart 和 Prometheus Federator 将为项目所有者（admin）、项目成员（edit）和只读成员（view）分配该命名空间的有限访问权限。**
|
||||
|
||||
:::note 注意事项：
|
||||
|
||||
- 项目发布命名空间会自动部署并导入到 ID 在 `.Values.helmProjectOperator.projectReleaseNamespaces.labelValue` 下指定的项目中，如果未指定，且项目注册命名空间中指定了 ProjectHelmChart，则默认为 `.Values.global.cattle.systemProjectId` 的值。
|
||||
|
||||
- 项目发布命名空间的孤立约定与项目注册命名空间的相同（参见上面的注释）。
|
||||
|
||||
- 如果 `.Values.projectReleaseNamespaces.enabled` 为 false，则项目发布命名空间与项目注册命名空间是相同的。
|
||||
|
||||
:::
|
||||
|
||||
### Helm 资源（HelmChart、HelmRelease）
|
||||
|
||||
在部署 ProjectHelmChart 时，Prometheus Federator 将自动创建和管理两个子自定义资源，它们依次管理以下底层 Helm 资源：
|
||||
|
||||
- HelmChart CR（通过 Operator 中的嵌入式 [k3s-io/helm-contoller](https://github.com/k3s-io/helm-controller) 管理）：此自定义资源会根据应用到 HelmChart CR 的变更，在触发 `helm install`、`helm upgrade` 或 `helm uninstall` 的同一命名空间中自动创建一个 Job。此 CR 会根据 ProjectHelmChart 的更改（例如，修改 `values.yaml`）或底层项目定义的更改（例如，从项目中添加或删除命名空间）自动更新。
|
||||
|
||||
:::note 重要提示：
|
||||
|
||||
如果 ProjectHelmChart 没有部署或更新底层项目监控堆栈，你可以先使用此资源在 Operator / System 命名空间中创建的 Job 来检查 Helm 操作是否有问题。通常只能由**集群管理员访问**。
|
||||
|
||||
:::
|
||||
|
||||
- HelmRelease CR（通过 Operator 中的嵌入式 [rancher/helm-locker](https://github.com/rancher/helm-locker) 管理）：此自定义资源会自动锁定已部署的 Helm 版本并自动覆盖对底层资源的更新，除非更改是 Helm 操作导致的（`helm install`、`helm upgrade` 或 `helm uninstall` 由 HelmChart CR 执行）。
|
||||
|
||||
:::note
|
||||
|
||||
HelmRelease CR 会发出 Kubernetes 事件，用于检测底层 Helm 版本修改并将其锁定回原位。要查看这些事件，你可以使用 `kubectl describe helmrelease <helm-release-name> -n <operator/system-namespace>`。你还可以查看此 Operator 的日志，了解检测到更改的时间以及哪些资源被尝试更改。
|
||||
|
||||
:::
|
||||
|
||||
这两种资源都是为 Operator / System 命名空间中的所有 Helm Chart 创建的，用于避免低权限用户的权限升级。
|
||||
|
||||
### 高级 Helm Project Operator 配置
|
||||
|
||||
有关高级配置的更多信息，请参阅[此页面](https://github.com/rancher/prometheus-federator/blob/main/charts/prometheus-federator/0.0.1/README.md#advanced-helm-project-operator-configuration)。
|
||||
|
||||
<!--
|
||||
|Value|Configuration|
|
||||
|---|---------------------------|
|
||||
|`helmProjectOperator.valuesOverride`| Allows an Operator to override values that are set on each ProjectHelmChart deployment on an operator-level; user-provided options (specified on the `spec.values` of the ProjectHelmChart) are automatically overridden if operator-level values are provided. For an example, see how the default value overrides `federate.targets`. Note: When overriding list values like `federate.targets`, user-provided list values will **not** be concatenated. |
|
||||
|`helmProjectOperator.projectReleaseNamespaces.labelValues`| The value of the Project that all Project Release Namespaces should be auto-imported into via label and annotation. Not recommended to be overridden on a Rancher setup. |
|
||||
|`helmProjectOperator.otherSystemProjectLabelValues`| Other namespaces that the operator should treat as a system namespace that should not be monitored. By default, all namespaces that match `global.cattle.systemProjectId` will not be matched. `cattle-monitoring-system`, `cattle-dashboards`, and `kube-system` are explicitly marked as system namespaces as well, regardless of label or annotation. |
|
||||
|`helmProjectOperator.releaseRoleBindings.aggregate`| Whether to automatically create RBAC resources in Project Release namespaces.
|
||||
|`helmProjectOperator.releaseRoleBindings.clusterRoleRefs.<admin\|edit\|view>`| ClusterRoles to reference to discover subjects to create RoleBindings for in the Project Release Namespace for all corresponding Project Release Roles. See RBAC above for more information. |
|
||||
|`helmProjectOperator.hardenedNamespaces.enabled`| Whether to automatically patch the default ServiceAccount with `automountServiceAccountToken: false` and create a default NetworkPolicy in all managed namespaces in the cluster; the default values ensure that the creation of the namespace does not break a CIS 1.16 hardened scan. |
|
||||
|`helmProjectOperator.hardenedNamespaces.configuration`| The configuration to be supplied to the default ServiceAccount or auto-generated NetworkPolicy on managing a namespace. |
|
||||
-->
|
||||
|
||||
### Local 集群上的 Prometheus Federator
|
||||
|
||||
Prometheus Federator 是一个资源密集型应用程序。你可以将其安装到 Local 集群（**不推荐**）。
|
||||
|
||||
+21
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: 架构
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-manager-architecture"/>
|
||||
</head>
|
||||
|
||||
本章节重点介绍 [Rancher Server 及其组件](rancher-server-and-components.md) 以及 [Rancher 如何与下游 Kubernetes 集群通信](communicating-with-downstream-user-clusters.md)。
|
||||
|
||||
有关安装 Rancher 的不同方式的信息，请参见[安装选项概述](../../getting-started/installation-and-upgrade/installation-and-upgrade.md#安装方式概述)。
|
||||
|
||||
有关 Rancher API Server 的主要功能，请参见[概述](../../getting-started/overview.md#rancher-api-server-的功能)。
|
||||
|
||||
有关如何为 Rancher Server 设置底层基础架构，请参见[架构推荐](architecture-recommendations.md)。
|
||||
|
||||
:::note
|
||||
|
||||
本节默认你已对 Docker 和 Kubernetes 有一定的了解。如果你需要了解 Kubernetes 组件如何协作，请参见 [Kubernetes 概念](../kubernetes-concepts.md)。
|
||||
|
||||
:::
|
||||
+55
@@ -0,0 +1,55 @@
|
||||
---
|
||||
title: Rancher 自我评估和加固指南
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security/hardening-guides"/>
|
||||
</head>
|
||||
|
||||
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://docs.k3s.io/) 是一个完全合规的，轻量级 Kubernetes 发行版。它易于安装，内存需求只有上游 Kubernetes 的一半，所有组件都在一个小于 100 MB 的二进制文件中。
|
||||
|
||||
要加固运行未列出的发行版的 Kubernetes 集群，请参阅 Kubernetes 提供商文档。
|
||||
|
||||
## 加固指南和 Benchmark 版本
|
||||
|
||||
每个自我评估指南都附有强化指南。这些指南与列出的 Rancher 版本一起进行了测试。每个自我评估指南都在特定的 Kubernetes 版本和 CIS Benchmark 版本上进行了测试。如果 CIS Benchmark 尚未针对你的 Kubernetes 版本进行验证，你可以使用现有指南，直到添加适合你的版本的指南。
|
||||
|
||||
### RKE 指南
|
||||
|
||||
| Kubernetes 版本 | CIS Benchmark 版本 | 自我评估指南 | 加固指南 |
|
||||
|--------------------|-----------------------|-----------------------|------------------|
|
||||
| Kubernetes v1.23 | CIS v1.23 | [链接](rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.23-k8s-v1.23.md) | [链接](rke1-hardening-guide/rke1-hardening-guide.md) |
|
||||
| Kubernetes v1.24 | CIS v1.24 | [链接](rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.24-k8s-v1.24.md) | [链接](rke1-hardening-guide/rke1-hardening-guide.md) |
|
||||
| Kubernetes v1.25/v1.26/v1.27 | CIS v1.7 | [链接](rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.7-k8s-v1.25-v1.26-v1.27.md) | [链接](rke1-hardening-guide/rke1-hardening-guide.md) |
|
||||
|
||||
### RKE2 指南
|
||||
|
||||
| 类型 | Kubernetes 版本 | CIS Benchmark 版本 | 自我评估指南 | 加固指南 |
|
||||
|------|--------------------|-----------------------|-----------------------|------------------|
|
||||
| Rancher provisioned RKE2 | Kubernetes v1.23 | CIS v1.23 | [链接](rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.23-k8s-v1.23.md) | [链接](rke2-hardening-guide/rke2-hardening-guide.md) |
|
||||
| Rancher provisioned RKE2 | Kubernetes v1.24 | CIS v1.24 | [链接](rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.24-k8s-v1.24.md) | [链接](rke2-hardening-guide/rke2-hardening-guide.md) |
|
||||
| Rancher provisioned RKE2 | Kubernetes v1.25/v1.26/v1.27 | CIS v1.7 | [链接](rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.7-k8s-v1.25-v1.26-v1.27.md) | [链接](rke2-hardening-guide/rke2-hardening-guide.md) |
|
||||
| Standalone RKE2 | Kubernetes v1.25/v1.26/v1.27 | CIS v1.7 | [链接](https://docs.rke2.io/security/cis_self_assessment123) | [链接](https://docs.rke2.io/security/hardening_guide) |
|
||||
|
||||
### K3s 指南
|
||||
|
||||
| 类型 | Kubernetes 版本 | CIS Benchmark 版本 | 自我评估指南 | 加固指南 |
|
||||
|------|--------------------|-----------------------|-----------------------|------------------|
|
||||
| Rancher provisioned K3s cluster | Kubernetes v1.23 | CIS v1.23 | [链接](k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.23-k8s-v1.23.md) | [链接](k3s-hardening-guide/k3s-hardening-guide.md) |
|
||||
| Rancher provisioned K3s cluster | Kubernetes v1.24 | CIS v1.24 | [链接](k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.24-k8s-v1.24.md) | [链接](k3s-hardening-guide/k3s-hardening-guide.md) |
|
||||
| Rancher provisioned K3s cluster | Kubernetes v1.25/v1.26/v1.27 | CIS v1.7 | [链接](k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.7-k8s-v1.25-v1.26-v1.27.md) | [链接](k3s-hardening-guide/k3s-hardening-guide.md) |
|
||||
| Standalone K3s | Kubernetes v1.22 up to v1.24 | CIS v1.23 | [链接](https://docs.k3s.io/security/self-assessment) | [链接](https://docs.k3s.io/security/hardening-guide) |
|
||||
|
||||
## 在 SELinux 上使用 Rancher
|
||||
|
||||
[Security-Enhanced Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) 是一个内核模块，为 Linux 添加了额外的访问控制和安全工具。SELinux 过去曾被政府机构使用，现在已成为行业标准。SELinux 在 RHEL 和 CentOS 上默认启用。
|
||||
|
||||
要将 Rancher 与 SELinux 结合使用，我们建议[安装](../selinux-rpm/about-rancher-selinux.md) `rancher-selinux`。
|
||||
+744
@@ -0,0 +1,744 @@
|
||||
---
|
||||
title: K3s 加固指南
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security/hardening-guides/k3s-hardening-guide"/>
|
||||
</head>
|
||||
|
||||
本文档提供了针对生产环境的 K3s 集群进行加固的具体指导，以便在使用 Rancher 部署之前进行配置。它概述了满足信息安全中心（Center for Information Security, CIS）Kubernetes benchmark controls 所需的配置和控制。
|
||||
|
||||
:::note
|
||||
这份加固指南描述了如何确保你集群中的节点安全。我们建议你在安装 Kubernetes 之前遵循本指南。
|
||||
:::
|
||||
|
||||
此加固指南适用于 K3s 集群，并与以下版本的 CIS Kubernetes Benchmark、Kubernetes 和 Rancher 相关联：
|
||||
|
||||
| Rancher 版本 | CIS Benchmark 版本 | Kubernetes 版本 |
|
||||
|-----------------|-----------------------|------------------------------|
|
||||
| Rancher v2.7 | Benchmark v1.23 | Kubernetes v1.23 |
|
||||
| Rancher v2.7 | Benchmark v1.24 | Kubernetes v1.24 |
|
||||
| Rancher v2.7 | Benchmark v1.7 | Kubernetes v1.25 至 v1.26 |
|
||||
|
||||
:::note
|
||||
在 Benchmark v1.7 中，不再需要 `--protect-kernel-defaults` (4.2.6) 参数，并已被 CIS 删除。
|
||||
:::
|
||||
|
||||
有关如何评估加固的 K3s 集群与官方 CIS benchmark 的更多细节，请参考特定 Kubernetes 和 CIS benchmark 版本的 K3s 自我评估指南。
|
||||
|
||||
K3s 在不需要修改的情况下通过了许多 Kubernetes CIS controls，因为它默认应用了几个安全缓解措施。然而，有一些值得注意的例外情况，需要手动干预才能完全符合 CIS Benchmark 要求：
|
||||
|
||||
1. K3s 不修改主机操作系统。任何主机级别的修改都需要手动完成。
|
||||
2. 某些 CIS policy controls，例如 `NetworkPolicies` 和 `PodSecurityStandards`（在 v1.24 及更早版本中为 `PodSecurityPolicies`），会限制集群功能。
|
||||
你必须选择让 K3s 配置这些策略。在你的命令行标志或配置文件中添加相应的选项（启用准入插件），并手动应用适当的策略。
|
||||
请参阅以下详细信息。
|
||||
|
||||
CIS Benchmark 的第一部分（1.1）主要关注于 Pod manifest 的权限和所有权。由于发行版中的所有内容都打包在一个二进制文件中，因此这一部分不适用于 K3s 的核心组件。
|
||||
|
||||
## 主机级别要求
|
||||
|
||||
### 确保 `protect-kernel-defaults`已经设置
|
||||
|
||||
<Tabs groupId="k3s-version">
|
||||
<TabItem value="v1.25 及更新版本" default>
|
||||
|
||||
自 CIS benchmark 1.7 开始，不再需要`protect-kernel-defaults`。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="v1.24 及更早版本">
|
||||
|
||||
这是一个 kubelet 标志，如果所需的内核参数未设置或设置为与 kubelet 的默认值不同的值，将导致 kubelet 退出。
|
||||
|
||||
可以在 Rancher 的集群配置中设置 `protect-kernel-defaults` 标志。
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
rkeConfig:
|
||||
machineSelectorConfig:
|
||||
- config:
|
||||
protect-kernel-defaults: true
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### 设置内核参数
|
||||
|
||||
建议为集群中的所有节点类型设置以下 `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` 以启用设置。
|
||||
|
||||
此配置需要在设置 kubelet 标志之前完成，否则 K3s 将无法启动。
|
||||
|
||||
## Kubernetes 运行时要求
|
||||
|
||||
CIS Benchmark 的运行时要求主要围绕 Pod 安全（通过 PSP 或 PSA）、网络策略和 API 服务器审计日志展开。
|
||||
|
||||
默认情况下，K3s 不包含任何 Pod 安全或网络策略。然而，K3s 附带一个控制器，可以强制执行你创建的任何网络策略。默认情况下，K3s 启用了 `PodSecurity` 和 `NodeRestriction` 等多个准入控制器。
|
||||
|
||||
### Pod 安全
|
||||
|
||||
<Tabs groupId="k3s-version">
|
||||
<TabItem value="v1.25 及更新版本" default>
|
||||
|
||||
K3s v1.25 及更新版本支持 [Pod 安全准入(PSA)](https://kubernetes.io/docs/concepts/security/pod-security-admission/)，用于控制 Pod 安全性。
|
||||
|
||||
你可以在 Rancher 中通过集群配置，设置 `defaultPodSecurityAdmissionConfigurationTemplateName` 字段来指定 PSA 配置：
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
defaultPodSecurityAdmissionConfigurationTemplateName: rancher-restricted
|
||||
```
|
||||
|
||||
Rancher 提供了 `rancher-restricted` 模板，用于强制执行高度限制性的 Kubernetes 上游 [`Restricted`](https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted) 配置文件，其中包含了 Pod 加固的最佳实践。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="v1.24 及更早版本">
|
||||
|
||||
K3s v1.24 及更早版本支持 [Pod 安全策略 (PSP)](https://v1-24.docs.kubernetes.io/docs/concepts/security/pod-security-policy/) 以控制 Pod 安全性。
|
||||
|
||||
你可以在 Rancher 中通过集群配置，传递以下标志来启用 PSPs：
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
rkeConfig:
|
||||
machineGlobalConfig:
|
||||
kube-apiserver-arg:
|
||||
- enable-admission-plugins=NodeRestriction,PodSecurityPolicy,ServiceAccount
|
||||
```
|
||||
|
||||
这会保留 `NodeRestriction` 插件并启用 `PodSecurityPolicy`。
|
||||
|
||||
启用 PSPs 后，你可以应用策略来满足 CIS Benchmark 第 5.2 节中描述的必要控制。
|
||||
|
||||
:::note
|
||||
这些是 CIS Benchmark 中的手动检查。CIS 扫描结果将标记为 `warning`，因为需要集群操作员进行手动检查。
|
||||
:::
|
||||
|
||||
以下是合规的 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
|
||||
```
|
||||
|
||||
要使示例 PSP 生效，我们需要创建一个 `ClusterRole` 和 一个`ClusterRoleBinding`。我们还需要为需要额外权限的系统级 Pod 提供“系统无限制策略”，以及允许必要的 sysctls 来实现 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
|
||||
```
|
||||
|
||||
上述策略可以放置在 `/var/lib/rancher/k3s/server/manifests` 目录下名为 `policy.yaml` 的文件中。在启动 K3s 之前，必须创建策略文件和其目录结构。建议限制访问权限以避免泄露潜在的敏感信息。
|
||||
|
||||
```shell
|
||||
sudo mkdir -p -m 700 /var/lib/rancher/k3s/server/manifests
|
||||
```
|
||||
|
||||
:::note
|
||||
CNI、DNS 和 Ingress 等关键 Kubernetes 组件在 `kube-system` 命名空间中作为 Pod 运行。因此，这个命名空间的限制政策较少，从而使这些组件能够正常运行。
|
||||
:::
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### 网络策略
|
||||
|
||||
CIS 要求所有命名空间应用网络策略，合理限制进入命名空间和 Pod 的流量。
|
||||
|
||||
:::note
|
||||
这些是 CIS Benchmark 中的手动检查。CIS 扫描结果将标记为 `warning`，因为需要集群操作员进行手动检查。
|
||||
:::
|
||||
|
||||
网络策略可以放置在 `/var/lib/rancher/k3s/server/manifests` 目录下的 `policy.yaml` 文件中。如果该目录不是作为 PSP（如上所述）的一部分创建的，则必须首先创建该目录。
|
||||
|
||||
```shell
|
||||
sudo mkdir -p -m 700 /var/lib/rancher/k3s/server/manifests
|
||||
```
|
||||
|
||||
以下是合规的网络策略示例：
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
除非特意允许，否则活动限制会阻止 DNS。以下是允许 DNS 相关流量的网络策略示例：
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
如果没有创建网络策略来允许访问，则默认情况下会阻止 metrics-server 和 Traefik Ingress 控制器。
|
||||
|
||||
```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
|
||||
你必须像平常一样管理你创建的任何其他命名空间的网络策略。
|
||||
:::
|
||||
|
||||
### API server 审计配置
|
||||
|
||||
CIS 要求 1.2.19 至 1.2.22 与配置 API server 审核日志相关。默认情况下，K3s 不会创建日志目录和审计策略，因为每个用户的审计策略要求和环境都是特定的。
|
||||
|
||||
如果你需要日志目录，则必须在启动 K3s 之前创建它。我们建议限制访问权限以避免泄露敏感信息。
|
||||
|
||||
```bash
|
||||
sudo mkdir -p -m 700 /var/lib/rancher/k3s/server/logs
|
||||
```
|
||||
|
||||
以下是用于记录请求元数据的初始审计策略。应将策略写入到 `/var/lib/rancher/k3s/server` 目录下名为 `audit.yaml` 的文件中。有关 API server 的策略配置的详细信息，请参阅 [官方 Kubernetes 文档](https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/)。
|
||||
|
||||
```yaml
|
||||
---
|
||||
apiVersion: audit.k8s.io/v1
|
||||
kind: Policy
|
||||
rules:
|
||||
- level: Metadata
|
||||
```
|
||||
|
||||
还需要进一步配置才能通过 CIS 检查。这些在 K3s 中默认不配置，因为它们根据你的环境和需求而有所不同：
|
||||
|
||||
- 确保 `--audit-log-path` 参数已经设置。
|
||||
- 确保 `--audit-log-maxage` 参数设置为 30 或适当的值。
|
||||
- 确保 `--audit-log-maxbackup` 参数设置为 10 或适当的值。
|
||||
- 确保 `--audit-log-maxsize` 参数设置为 100 或适当的值。
|
||||
|
||||
综合起来，要启用和配置审计日志，请将以下行添加到 Rancher 的 K3s 集群配置文件中：
|
||||
|
||||
```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 要求
|
||||
|
||||
CIS 要求 1.3.1 检查 Controller Manager 中的垃圾收集设置。垃圾收集对于确保资源充足可用性并避免性能和可用性下降非常重要。根据你的系统资源和测试结果，选择一个适当的阈值来激活垃圾收集。
|
||||
|
||||
你可以在 Rancher 的 K3s 集群文件中设置以下配置来解决此问题。下面的值仅是一个示例，请根据当前环境设置适当的阈值。
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
rkeConfig:
|
||||
machineGlobalConfig:
|
||||
kube-controller-manager-arg:
|
||||
- terminated-pod-gc-threshold=10 # CIS 1.3.1
|
||||
```
|
||||
|
||||
### 配置 `default` Service Account
|
||||
|
||||
Kubernetes 提供了一个名为 `default` 的 service account，供集群工作负载使用，其中没有为 Pod 分配特定的 service account。当 Pod 需要从 Kubernetes API 获取访问权限时，应为该 Pod 创建一个特定的 service account，并为该 service account 授予权限。
|
||||
|
||||
对于 CIS 5.1.5，`default` service account 应配置为不提供 service account 令牌，并且不具有任何明确的权限分配。
|
||||
|
||||
可以通过在每个命名空间中将 `default` service account 的 `automountServiceAccountToken` 字段更新为 `false` 来解决此问题。
|
||||
|
||||
对于内置命名空间（`kube-system`、`kube-public`、`kube-node-lease` 和 `default`）中的 `default` service accounts，K3s 不会自动执行此操作。
|
||||
|
||||
将以下配置保存到名为 `account_update.yaml` 的文件中。
|
||||
|
||||
```yaml
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: default
|
||||
automountServiceAccountToken: false
|
||||
```
|
||||
|
||||
创建一个名为 `account_update.sh` 的 Bash 脚本文件。确保使用 `chmod +x account_update.sh` 给脚本添加可执行权限。
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
每次向你的集群添加新的 service account 时，运行该脚本。
|
||||
|
||||
## 加固版 K3s 模板配置参考
|
||||
|
||||
Rancher 使用以下参考模板配置，基于本指南中的每个 CIS 控件创建加固过的自定义 K3s 集群。此参考内容不包括其他必需的**集群配置**指令，这些指令因你的环境而异。
|
||||
|
||||
<Tabs groupId="k3s-version">
|
||||
<TabItem value="v1.25 及更新的版本" default>
|
||||
|
||||
```yaml
|
||||
apiVersion: provisioning.cattle.io/v1
|
||||
kind: Cluster
|
||||
metadata:
|
||||
name: # 定义集群名称
|
||||
spec:
|
||||
defaultPodSecurityAdmissionConfigurationTemplateName: rancher-restricted
|
||||
enableNetworkPolicy: true
|
||||
kubernetesVersion: # 定义 K3s 版本
|
||||
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
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="v1.24 及更早的版本">
|
||||
|
||||
```yaml
|
||||
apiVersion: provisioning.cattle.io/v1
|
||||
kind: Cluster
|
||||
metadata:
|
||||
name: # 定义集群名称
|
||||
spec:
|
||||
enableNetworkPolicy: true
|
||||
kubernetesVersion: # 定义 K3s 版本
|
||||
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>
|
||||
|
||||
## 结论
|
||||
|
||||
如果你按照本指南操作，由 Rancher 提供的 K3s 自定义集群将配置为通过 CIS Kubernetes Benchmark 测试。你可以查看我们的 K3s 自我评估指南，了解我们是如何验证每个 benchmarks 的，并且你可以在你的集群上执行相同的操作。
|
||||
+19
-15
@@ -1,36 +1,40 @@
|
||||
---
|
||||
title: K3s Self-Assessment Guide - CIS Benchmark v1.23 - K8s v1.23
|
||||
title: K3s 自我评估指南 - CIS Benchmark v1.23 - K8s v1.23
|
||||
---
|
||||
|
||||
This document is a companion to the [K3s Hardening Guide](../../../../pages-for-subheaders/k3s-hardening-guide.md), which provides prescriptive guidance on how to harden K3s clusters that are running in production and managed by Rancher. This benchmark guide helps you evaluate the security of a hardened cluster against each control in the CIS Kubernetes Benchmark.
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security/hardening-guides/k3s-hardening-guide/k3s-self-assessment-guide-with-cis-v1.23-k8s-v1.23"/>
|
||||
</head>
|
||||
|
||||
This guide corresponds to the following versions of Rancher, CIS Benchmarks, and Kubernetes:
|
||||
本文档是 [K3s 加固指南](k3s-hardening-guide.md)的配套文档，该指南提供了关于如何加固正在生产环境中运行并由 Rancher 管理的 K3s 集群的指导方针。本 benchmark 指南可帮助你根据 CIS Kubernetes Benchmark 中的每个 control 来评估加固集群的安全性。
|
||||
|
||||
| Rancher Version | CIS Benchmark Version | Kubernetes Version |
|
||||
本指南对应以下版本的 Rancher、CIS Benchmarks 和 Kubernetes：
|
||||
|
||||
| Rancher 版本 | CIS Benchmark 版本 | Kubernetes 版本 |
|
||||
|-----------------|-----------------------|--------------------|
|
||||
| Rancher v2.7 | Benchmark v1.23 | Kubernetes v1.23 |
|
||||
|
||||
This document is for Rancher operators, security teams, auditors and decision makers.
|
||||
本文档适用于 Rancher 运维人员、安全团队、审计员和决策者。
|
||||
|
||||
For more information about each control, including detailed descriptions and remediations for failing tests, refer to the corresponding section of the CIS Kubernetes Benchmark v1.23. You can download the benchmark, after creating a free account, at [Center for Internet Security (CIS)](https://www.cisecurity.org/benchmark/kubernetes/).
|
||||
有关每个 control 的更多信息，包括详细描述和未通过测试的补救措施，请参考 CIS Kubernetes Benchmark v1.23 的相应部分。你可以在[互联网安全中心 (CIS)](https://www.cisecurity.org/benchmark/kubernetes/)创建免费账户后下载 benchmark。
|
||||
|
||||
## Testing Methodology
|
||||
## 测试方法
|
||||
|
||||
Each control in the CIS Kubernetes Benchmark was evaluated against a K3s cluster that was configured according to the accompanying hardening guide.
|
||||
每个 CIS Kubernetes Benchmark 中的 control 都根据附带的加固指南评估了针对 K3s 集群的配置。
|
||||
|
||||
Where control audits differ from the original CIS benchmark, the audit commands specific to K3s are provided for testing.
|
||||
当 control 审计与原始的 CIS benchmark 不同的时候，提供了针对 K3s 的特定审计命令，以供测试使用。
|
||||
|
||||
These are the possible results for each control:
|
||||
以下是每个 control 可能的结果：
|
||||
|
||||
- **Pass** - The K3s cluster passes the audit outlined in the benchmark.
|
||||
- **Not Applicable** - The control is not applicable to K3s because of how it is designed to operate. The remediation section explains why.
|
||||
- **Warn** - The control is manual in the CIS benchmark and it depends on the cluster's use-case or some other factor that must be determined by the cluster operator. These controls have been evaluated to ensure K3s doesn't prevent their implementation, but no further configuration or auditing of the cluster has been performed.
|
||||
- **Pass（通过）** - K3s 集群通过了 benchmark 中概述的审计。
|
||||
- **Not Applicable（不适用）** - 由于 K3s 的设计方式，该 control 不适用于 K3s。在补救措施部分解释了原因。
|
||||
- **Warn（警告）** - 在 CIS benchmark 中，该 control 是手动的，它取决于集群的使用情况或其他必须由集群操作员确定的因素。这些 control 措施已经过评估，以确保 K3s 不会阻止其实施，但尚未对集群进行进一步的配置或审计。
|
||||
|
||||
This guide makes the assumption that K3s is running as a Systemd unit. Your installation may vary. Adjust the "audit" commands to fit your scenario.
|
||||
本指南假设 K3s 作为 Systemd 单元运行。你的安装可能会有所不同。调整"审计"命令以适合你的场景。
|
||||
|
||||
:::note
|
||||
|
||||
This guide only covers `automated` (previously called `scored`) tests.
|
||||
本指南仅涵盖 `automated`（之前称为 `scored`）测试。
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+3208
File diff suppressed because it is too large
Load Diff
+3215
File diff suppressed because it is too large
Load Diff
+515
@@ -0,0 +1,515 @@
|
||||
---
|
||||
title: RKE 加固指南
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security/hardening-guides/rke1-hardening-guide"/>
|
||||
</head>
|
||||
|
||||
本文档提供了针对生产环境的 RKE 集群进行加固的具体指导，以便在使用 Rancher 部署之前进行配置。它概述了满足信息安全中心（Center for Information Security, CIS）Kubernetes benchmark controls 所需的配置和控制。
|
||||
|
||||
:::note
|
||||
这份加固指南描述了如何确保你集群中的节点安全。我们建议你在安装 Kubernetes 之前遵循本指南。
|
||||
:::
|
||||
|
||||
此加固指南适用于 RKE 集群，并与以下版本的 CIS Kubernetes Benchmark、Kubernetes 和 Rancher 相关联：
|
||||
|
||||
| Rancher 版本 | CIS Benchmark 版本 | Kubernetes 版本 |
|
||||
|-----------------|-----------------------|------------------------------|
|
||||
| Rancher v2.7 | Benchmark v1.23 | Kubernetes v1.23 |
|
||||
| Rancher v2.7 | Benchmark v1.24 | Kubernetes v1.24 |
|
||||
| Rancher v2.7 | Benchmark v1.7 | Kubernetes v1.25 至 v1.26 |
|
||||
|
||||
:::note
|
||||
- 在 Benchmark v1.24 及更高版本中，检查 id `4.1.7 Ensure that the certificate authorities file permissions are set to 600 or more restrictive (Automated)` 可能会失败，因为 `/etc/kubernetes/ssl/kube-ca.pem` 默认设置为 644。
|
||||
- 在 Benchmark v1.7 中，不再需要 `--protect-kernel-defaults` (`4.2.6`) 参数，并已被 CIS 删除。
|
||||
:::
|
||||
|
||||
有关如何评估加固的 RKE 集群与官方 CIS benchmark 的更多细节，请参考特定 Kubernetes 和 CIS benchmark 版本的 RKE 自我评估指南。
|
||||
|
||||
## 主机级别要求
|
||||
|
||||
### 配置 Kernel 运行时参数
|
||||
|
||||
建议对群集中的所有节点类型使用以下 `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
|
||||
```
|
||||
|
||||
运行 `sysctl -p /etc/sysctl.d/90-kubelet.conf` 以启用设置。
|
||||
|
||||
### 配置 `etcd` 用户和组
|
||||
|
||||
在安装 RKE 之前，需要设置 **etcd** 服务的用户帐户和组。
|
||||
|
||||
#### 创建 `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
|
||||
```
|
||||
|
||||
在通过集群配置文件 `config.yml` 部署RKE时，请更新 `etcd` 用户的 `uid` 和 `gid`：
|
||||
|
||||
```yaml
|
||||
services:
|
||||
etcd:
|
||||
gid: 52034
|
||||
uid: 52034
|
||||
```
|
||||
|
||||
## Kubernetes 运行时要求
|
||||
|
||||
### 配置 `default` Service Account
|
||||
|
||||
#### 设置 `automountServiceAccountToken` 为 `false` 用于 `default` service accounts
|
||||
|
||||
Kubernetes 提供了一个 default service account，供集群工作负载使用，其中没有为 pod 分配特定的 service account。
|
||||
如果需要从 pod 访问 Kubernetes API，则应为该 pod 创建特定的 service account，并向该 service account 授予权限。
|
||||
应配置 default service account，使其不提供 service account 令牌，并且不应具有任何明确的权限分配。
|
||||
|
||||
对于标准 RKE 安装上的每个命名空间（包括 `default` 和 `kube-system`），`default` service account 必须包含以下值：
|
||||
|
||||
```yaml
|
||||
automountServiceAccountToken: false
|
||||
```
|
||||
|
||||
将以下配置保存到名为 `account_update.yaml` 的文件中。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: default
|
||||
automountServiceAccountToken: false
|
||||
```
|
||||
|
||||
创建一个名为 `account_update.yaml` 的 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
|
||||
```
|
||||
|
||||
执行此脚本将 `account_update.yaml` 配置应用到所有命名空间中的 `default` service account。
|
||||
|
||||
### 配置网络策略
|
||||
|
||||
#### 确保所有命名空间都定义了网络策略
|
||||
|
||||
在同一个 Kubernetes 集群上运行不同的应用程序会带来风险，即某个受感染的应用程序可能会攻击相邻的应用程序。为确保容器只与其预期通信的容器进行通信，网络分段至关重要。网络策略规定了哪些 Pod 可以互相通信，以及与其他网络终端通信的方式。
|
||||
|
||||
网络策略是命名空间范围的。当在特定命名空间引入网络策略时，所有未被策略允许的流量将被拒绝。然而，如果在命名空间中没有网络策略，那么所有流量将被允许进入和离开该命名空间中的 Pod。要强制执行网络策略，必须启用容器网络接口（container network interface, 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 站点上找到。
|
||||
|
||||
:::caution
|
||||
此网络策略只是一个示例，不建议用于生产用途。
|
||||
:::
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
执行此脚本以将 `default-allow-all.yaml` 配置和 **permissive** 的 `NetworkPolicy` 应用于所有命名空间。
|
||||
|
||||
## 已知限制
|
||||
|
||||
- 当注册自定义节点仅提供公共 IP 时，Rancher **exec shell** 和 **查看 pod 日志** 在加固设置中**不起作用**。 此功能需要在注册自定义节点时提供私有 IP。
|
||||
- 当根据 Rancher [提供](../../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md)的 Pod 安全策略 (Pod Security Policies, PSP) 将 `default_pod_security_policy_template_id:` 设置为 `restricted` 或 `restricted-noroot` 时，Rancher 会在 `default` service accounts 上创建 `RoleBindings` 和 `ClusterRoleBindings`。CIS 检查 5.1.5 要求除了默认角色之外，`default` service accounts 不应绑定其他角色或集群角色。此外，`default` service accounts 应配置为不提供服务账户令牌，也不具有任何明确的权限分配。
|
||||
|
||||
## 加固的 RKE `cluster.yml` 配置参考
|
||||
|
||||
参考的 `cluster.yml` 文件是由 RKE CLI 使用的，它提供了实现 RKE 加固安装所需的配置。
|
||||
RKE [文档](https://rancher.com/docs/rke/latest/en/installation/)提供了有关配置项的更多详细信息。这里参考的 `cluster.yml` 不包括必需的 `nodes` 指令，因为它取决于你的环境。在 RKE 中有关节点配置的文档可以在[这里](https://rancher.com/docs/rke/latest/en/config-options/nodes/)找到。
|
||||
|
||||
示例 `cluster.yml` 配置文件中包含了一个 Admission Configuration 策略，在 `services.kube-api.admission_configuration` 字段中指定。这个[示例](../../psa-restricted-exemptions.md)策略包含了命名空间的豁免规则，这对于在Rancher中正确运行导入的RKE集群非常必要，类似于Rancher预定义的 [`rancher-restricted`](../../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/psa-config-templates.md) 策略。
|
||||
|
||||
如果你希望使用 RKE 的默认 `restricted` 策略，则将 `services.kube-api.admission_configuration` 字段留空，并将 `services.pod_security_configuration` 设置为 `restricted`。你可以在 [RKE 文档](https://rke.docs.rancher.com/config-options/services/pod-security-admission)中找到更多信息。
|
||||
|
||||
<Tabs groupId="rke1-version">
|
||||
<TabItem value="v1.25 及更新版本" default>
|
||||
|
||||
:::note
|
||||
如果你打算将一个 RKE 集群导入到 Rancher 中，请参考此[文档](../../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/psa-config-templates.md)以了解如何配置 PSA 以豁免 Rancher 系统命名空间。
|
||||
:::
|
||||
|
||||
```yaml
|
||||
# 如果你打算在离线环境部署 Kubernetes，
|
||||
# 请查阅文档以了解如何配置自定义的 RKE 镜像。
|
||||
nodes: []
|
||||
kubernetes_version: # 定义 RKE 版本
|
||||
services:
|
||||
etcd:
|
||||
uid: 52034
|
||||
gid: 52034
|
||||
kube-api:
|
||||
secrets_encryption_config:
|
||||
enabled: true
|
||||
audit_log:
|
||||
enabled: true
|
||||
event_rate_limit:
|
||||
enabled: true
|
||||
# 如果你在 `admission_configuration` 中设置了自定义策略，
|
||||
# 请将 `pod_security_configuration` 字段留空。
|
||||
# 否则，将其设置为 `restricted` 以使用 RKE 预定义的受限策略，
|
||||
# 并删除 `admission_configuration` 字段中的所有内容。
|
||||
#
|
||||
# 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-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-provisioning-capi-system,
|
||||
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]
|
||||
kube-controller:
|
||||
extra_args:
|
||||
feature-gates: RotateKubeletServerCertificate=true
|
||||
kubelet:
|
||||
extra_args:
|
||||
feature-gates: RotateKubeletServerCertificate=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 及更早版本">
|
||||
|
||||
```yaml
|
||||
# 如果你打算在离线环境部署 Kubernetes，
|
||||
# 请查阅文档以了解如何配置自定义的 RKE 镜像。
|
||||
nodes: []
|
||||
kubernetes_version: # 定义 RKE 版本
|
||||
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>
|
||||
|
||||
## 加固后的 RKE 集群模板配置参考
|
||||
|
||||
参考的 RKE 集群模板提供了实现 Kubernetes 加固安装所需的最低配置。RKE 模板用于提供 Kubernetes 并定义 Rancher 设置。有关安装 RKE 及其模板详情的其他信息，请参考 Rancher [文档](../../../../getting-started/installation-and-upgrade/installation-and-upgrade.md) 。
|
||||
|
||||
<Tabs groupId="rke1-version">
|
||||
<TabItem value="v1.25 及更新版本" default>
|
||||
|
||||
```yaml
|
||||
#
|
||||
# 集群配置
|
||||
#
|
||||
default_pod_security_admission_configuration_template_name: rancher-restricted
|
||||
enable_network_policy: true
|
||||
local_cluster_auth_endpoint:
|
||||
enabled: true
|
||||
name: # 定义集群名称
|
||||
|
||||
#
|
||||
# Rancher 配置
|
||||
#
|
||||
rancher_kubernetes_engine_config:
|
||||
addon_job_timeout: 45
|
||||
authentication:
|
||||
strategy: x509|webhook
|
||||
kubernetes_version: # 定义 RKE 版本
|
||||
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
|
||||
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 及更早版本">
|
||||
|
||||
```yaml
|
||||
#
|
||||
# 集群配置
|
||||
#
|
||||
default_pod_security_policy_template_id: restricted-noroot
|
||||
enable_network_policy: true
|
||||
local_cluster_auth_endpoint:
|
||||
enabled: true
|
||||
name: # 定义集群名称
|
||||
|
||||
#
|
||||
# Rancher 配置
|
||||
#
|
||||
rancher_kubernetes_engine_config:
|
||||
addon_job_timeout: 45
|
||||
authentication:
|
||||
strategy: x509|webhook
|
||||
kubernetes_version: # 定义 RKE 版本
|
||||
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>
|
||||
|
||||
## 结论
|
||||
|
||||
如果你按照本指南操作，由 Rancher 提供的 RKE 自定义集群将配置为通过 CIS Kubernetes Benchmark 测试。你可以查看我们的 RKE 自我评估指南，了解我们是如何验证每个 benchmarks 的，并且你可以在你的集群上执行相同的操作。
|
||||
+15
-11
@@ -1,30 +1,34 @@
|
||||
---
|
||||
title: RKE Self-Assessment Guide - CIS Benchmark v1.23 - K8s v1.23
|
||||
title: RKE 自我评估指南 - CIS Benchmark v1.23 - K8s v1.23
|
||||
---
|
||||
|
||||
This document is a companion to the [RKE Hardening Guide](../../../../pages-for-subheaders/rke1-hardening-guide.md), which provides prescriptive guidance on how to harden RKE clusters that are running in production and managed by Rancher. This benchmark guide helps you evaluate the security of a hardened cluster against each control in the CIS Kubernetes Benchmark.
|
||||
<head>
|
||||
<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>
|
||||
|
||||
This guide corresponds to the following versions of Rancher, CIS Benchmarks, and Kubernetes:
|
||||
本文档是 [RKE 加固指南](rke1-hardening-guide.md)的配套文档，该指南提供了关于如何加固正在生产环境中运行并由 Rancher 管理的 RKE 集群的指导方针。本 benchmark 指南可帮助你根据 CIS Kubernetes Benchmark 中的每个 control 来评估加固集群的安全性。
|
||||
|
||||
| Rancher Version | CIS Benchmark Version | Kubernetes Version |
|
||||
本指南对应以下版本的 Rancher、CIS Benchmarks 和 Kubernetes：
|
||||
|
||||
| Rancher 版本 | CIS Benchmark 版本 | Kubernetes 版本 |
|
||||
|-----------------|-----------------------|--------------------|
|
||||
| Rancher v2.7 | Benchmark v1.23 | Kubernetes v1.23 |
|
||||
|
||||
This guide walks through the various controls and provide updated example commands to audit compliance in Rancher created clusters. Because Rancher and RKE install Kubernetes services as Docker containers, many of the control verification checks in the CIS Kubernetes Benchmark don't apply. These checks will return a result of `Not Applicable`.
|
||||
本指南将介绍各种 controls，并提供更新的示例命令来审计 Rancher 创建的集群中的合规性。由于 Rancher 和 RKE 将 Kubernetes 服务安装为 Docker 容器，因此 CIS Kubernetes Benchmark 中的许多 control 验证检查不适用。这些检查将返回 `Not Applicable` 的结果。
|
||||
|
||||
This document is for Rancher operators, security teams, auditors and decision makers.
|
||||
本文档适用于 Rancher 运维人员、安全团队、审计员和决策者。
|
||||
|
||||
For more information about each control, including detailed descriptions and remediations for failing tests, refer to the corresponding section of the CIS Kubernetes Benchmark v1.23. You can download the benchmark, after creating a free account, at [Center for Internet Security (CIS)](https://www.cisecurity.org/benchmark/kubernetes/).
|
||||
有关每个 control 的更多信息，包括详细描述和未通过测试的补救措施，请参考 CIS Kubernetes Benchmark v1.23 的相应部分。你可以在[互联网安全中心 (CIS)](https://www.cisecurity.org/benchmark/kubernetes/)创建免费账户后下载 benchmark。
|
||||
|
||||
## Testing Methodology
|
||||
## 测试方法
|
||||
|
||||
Rancher and RKE install Kubernetes services via Docker containers. Configuration is defined by arguments passed to the container at the time of initialization, not via configuration files.
|
||||
Rancher 和 RKE 通过 Docker 容器安装 Kubernetes 服务。配置是通过初始化时传递给容器的参数定义的，而不是通过配置文件。
|
||||
|
||||
Where control audits differ from the original CIS benchmark, the audit commands specific to Rancher are provided for testing. When performing the tests, you will need access to the command line on the hosts of all RKE nodes. The commands also make use of the [kubectl](https://kubernetes.io/docs/tasks/tools/) (with a valid configuration file) and [jq](https://stedolan.github.io/jq/) tools, which are required in the testing and evaluation of test results.
|
||||
在 control 审计与原始 CIS benchmark 不同时，提供了针对 Rancher 的特定审计命令以进行测试。在执行测试时，你将需要访问所有 RKE 节点主机上的命令行。这些命令还使用了 [kubectl](https://kubernetes.io/docs/tasks/tools/)（带有有效的配置文件）和 [jq](https://stedolan.github.io/jq/) 工具，在测试和评估测试结果时这些工具是必需的。
|
||||
|
||||
:::note
|
||||
|
||||
This guide only covers `automated` (previously called `scored`) tests.
|
||||
本指南仅涵盖 `automated`（之前称为 `scored`）测试。
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+3046
File diff suppressed because it is too large
Load Diff
+2862
File diff suppressed because it is too large
Load Diff
+273
@@ -0,0 +1,273 @@
|
||||
---
|
||||
title: RKE2 加固指南
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security/hardening-guides/rke2-hardening-guide"/>
|
||||
</head>
|
||||
|
||||
本文档提供了针对生产环境的 RKE2 集群进行加固的具体指导，以便在使用 Rancher 部署之前进行配置。它概述了满足信息安全中心（Center for Information Security, CIS）Kubernetes benchmark controls 制所需的配置和控制。
|
||||
|
||||
:::note
|
||||
这份加固指南描述了如何确保你集群中的节点安全。我们建议你在安装 Kubernetes 之前遵循本指南。
|
||||
:::
|
||||
|
||||
此加固指南适用于 RKE2 集群，并与以下版本的 CIS Kubernetes Benchmark、Kubernetes 和 Rancher 相关联：
|
||||
|
||||
| Rancher 版本 | CIS Benchmark 版本 | Kubernetes 版本 |
|
||||
|-----------------|-----------------------|------------------------------|
|
||||
| Rancher v2.7 | Benchmark v1.23 | Kubernetes v1.23 |
|
||||
| Rancher v2.7 | Benchmark v1.24 | Kubernetes v1.24 |
|
||||
| Rancher v2.7 | Benchmark v1.7 | Kubernetes v1.25 至 v1.26 |
|
||||
|
||||
:::note
|
||||
- 在 Benchmark v1.24 及更高版本中，由于新的文件权限要求（600 而不是 644），一些检查 ID 可能会失败。受影响的检查 ID 包括：`1.1.1`, `1.1.3`, `1.1.5`, `1.1.7`, `1.1.13`, `1.1.15`, `1.1.17`, `4.1.3`, `4.1.5` 和 `4.1.9`。
|
||||
- 在 Benchmark v1.7 中，不再需要 `--protect-kernel-defaults` (4.2.6) 参数，并已被 CIS 删除。
|
||||
:::
|
||||
|
||||
有关如何评估加固的 RKE2 集群与官方 CIS benchmark 的更多细节，请参考特定 Kubernetes 和 CIS benchmark 版本的 RKE2 自我评估指南。
|
||||
|
||||
RKE2 在不需要修改的情况下通过了许多 Kubernetes CIS controls，因为它默认应用了几个安全缓解措施。然而，有一些值得注意的例外情况，需要手动干预才能完全符合 CIS Benchmark 要求：
|
||||
|
||||
1. RKE2 不会修改主机操作系统。因此，作为运维人员，你必须进行一些主机级别的修改。
|
||||
2. 某些 CIS controls 对于网络策略和 Pod 安全标准（或 RKE2 v1.25 之前的 Pod 安全策略 (PSP)）将限制集群的功能。你必须选择让 RKE2 为你配置这些功能。为了确保满足这些要求，可以启动 RKE2 并设置 profile 标志为 `cis-1.23`（适用于 v1.25 及更新版本）或 `cis-1.6`（适用于 v1.24 及更早版本）。
|
||||
|
||||
## 主机级别要求
|
||||
|
||||
主机级要求有两个方面：内核参数和 etcd 进程/目录配置。这些在本节中进行了概述。
|
||||
|
||||
### 确保 `protect-kernel-defaults` 已经设置
|
||||
|
||||
<Tabs groupId="k3s-version">
|
||||
<TabItem value="v1.25 及更新版本" default>
|
||||
|
||||
自 CIS benchmark 1.7 开始，不再需要`protect-kernel-defaults`。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="v1.24 及更早版本">
|
||||
|
||||
这是一个 kubelet 标志，如果所需的内核参数未设置或设置为与 kubelet 的默认值不同的值，将导致 kubelet 退出。
|
||||
|
||||
可以在 Rancher 的集群配置中设置 `protect-kernel-defaults` 标志。
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
rkeConfig:
|
||||
machineSelectorConfig:
|
||||
- config:
|
||||
protect-kernel-defaults: true
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### 设置内核参数
|
||||
|
||||
建议为集群中的所有节点类型设置以下 `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` 以启用设置。
|
||||
|
||||
### 确保 etcd 配置正确
|
||||
|
||||
CIS Benchmark 要求 etcd 数据目录由 `etcd` 用户和组拥有。这意味着 etcd 进程必须以主机级别的 `etcd` 用户身份运行。为了实现这一点，在使用有效的 `cis-1.xx` 配置文件启动 RKE2 时，RKE2 会采取以下几个步骤：
|
||||
|
||||
1. 检查主机上是否存在 `etcd` 用户和组。如果不存在，则显示错误并退出。
|
||||
2. 使用 `etcd` 作为用户和组所有者创建 etcd 的数据目录。
|
||||
3. 通过适当设置 etcd 静态 Pod 的 `SecurityContext`，确保 etcd 进程以 `etcd` 用户和组的身份运行。
|
||||
|
||||
为满足上述要求，你必须执行以下操作：
|
||||
|
||||
#### 创建 etcd 用户
|
||||
|
||||
在某些 Linux 发行版中，`useradd` 命令不会创建组。下面包含了 `-U` 标志来解决这个问题。这个标志告诉 `useradd` 创建一个与用户同名的组。
|
||||
|
||||
```bash
|
||||
sudo useradd -r -c "etcd user" -s /sbin/nologin -M etcd -U
|
||||
```
|
||||
|
||||
## Kubernetes 运行时要求
|
||||
|
||||
通过 CIS Benchmark 测试的运行时要求主要集中在 Pod 安全、网络策略和内核参数上。当使用有效的 `cis-1.xx` 配置文件时，大部分都会被 RKE2 自动处理，但需要一些额外的运维人员干预是。本节概述了这些内容。
|
||||
|
||||
### Pod 安全
|
||||
|
||||
RKE2 始终以一定程度的 Pod 安全性运行。
|
||||
|
||||
<Tabs groupId="rke2-version">
|
||||
<TabItem value="v1.25 及更新版本" default>
|
||||
|
||||
在 v1.25 及更高版本中，[Pod 安全准入(PSAs)](https://kubernetes.io/docs/concepts/security/pod-security-admission/)用于保证 pod 安全。
|
||||
|
||||
以下是确保加固 RKE2 通过 Rancher 中提供的 CIS v1.23 加固配置文件 `rke2-cis-1.7-hardened` 所需的最低配置。
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
defaultPodSecurityAdmissionConfigurationTemplateName: rancher-restricted
|
||||
rkeConfig:
|
||||
machineSelectorConfig:
|
||||
- config:
|
||||
profile: cis-1.23
|
||||
```
|
||||
|
||||
当同时设置了 `defaultPodSecurityAdmissionConfigurationTemplateName` 和 `profile` 标志时，Rancher 和 RKE2 会执行以下操作：
|
||||
|
||||
1. 检查是否已满足主机级要求。如果未满足，RKE2 将以致命错误退出，并描述未满足的要求。
|
||||
2. 应用允许群集传递关联 controls 的网络策略。
|
||||
3. 配置 Pod 安全准入控制器（PSA）使用 PSA 配置模板 `rancher-restricted`，以在所有命名空间中强制执行受限模式，除了模板豁免列表中的命名空间。
|
||||
这些命名空间被豁免，以允许系统 Pod 在没有限制的情况下运行，这是集群正常运行所必需的。
|
||||
|
||||
:::note
|
||||
如果你打算将一个 RKE 集群导入到 Rancher 中，请参考[文档](../../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/psa-config-templates.md)了解如何配置 PSA 以豁免 Rancher system 命名空间。
|
||||
:::
|
||||
|
||||
</TabItem>
|
||||
|
||||
<TabItem value="v1.24 及更早版本">
|
||||
|
||||
在 Kubernetes v1.24 及更早版本中，`PodSecurityPolicy` 准入控制器始终是启用的。
|
||||
|
||||
以下是确保 RKE2 加固以通过 Rancher 中提供的 CIS v1.23 加固配置文件 `rke2-cis-1.23-hardened` 所需的最低配置。
|
||||
|
||||
:::note
|
||||
在下面的示例中，配置文件设置为`cis-1.6`，这是在上游 RKE2 中定义的值，但集群实际上配置为传递 CIS v1.23 加固配置文件
|
||||
:::
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
defaultPodSecurityPolicyTemplateName: restricted-noroot
|
||||
rkeConfig:
|
||||
machineSelectorConfig:
|
||||
- config:
|
||||
profile: cis-1.6
|
||||
```
|
||||
|
||||
|
||||
当同时设置了 `defaultPodSecurityPolicyTemplateName` 和 `profile` 标志时，Rancher 和 RKE2 会执行以下操作：
|
||||
|
||||
1. 检查是否已满足主机级要求。如果未满足，RKE2 将以致命错误退出，并描述未满足的要求。
|
||||
2. 应用网络策略，以确保集群通过相关的 controls 要求。
|
||||
3. 配置运行时 Pod 安全策略，以确保集群通过相关的 controls 要求。
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
:::note
|
||||
Kubernetes control plane 组件以及关键的附加组件，如 CNI、DNS 和 Ingress，都作为 `kube-system` 命名空间中的 Pod 运行。因此，这个命名空间的限制政策较少，从而使这些组件能够正常运行。
|
||||
:::
|
||||
|
||||
### 网络策略
|
||||
|
||||
当使用有效的 `cis-1.xx` 配置文件运行时，RKE2 将设置适当的 `NetworkPolicies`，以满足 Kubernetes 内置命名空间的 CIS Benchmark 要求。这些命名空间包括：`kube-system`、`kube-public`、`kube-node-lease` 和 `default`。
|
||||
|
||||
所使用的 `NetworkPolicy` 仅允许同一命名空间内的 Pod 相互通信。值得注意的例外是允许 DNS 请求进行解析。
|
||||
|
||||
:::note
|
||||
运维人员必须像管理其他命名空间一样管理额外创建的命名空间的网络策略。
|
||||
:::
|
||||
|
||||
### 配置 `default` service account
|
||||
|
||||
**将 `default` service accountsSet 的 `automountServiceAccountToken` 设置为 `false`**
|
||||
|
||||
Kubernetes 提供了一个 `default` service account，用于集群工作负载，在 pod 没有分配特定 service account 时使用。如果需要从 pod 访问 Kubernetes API，则应为该 pod 创建一个特定的 service account，并授予该 service account 权限。`default` service account 应配置为不提供 service account 令牌，并且不具有任何明确的权限分配。
|
||||
|
||||
对于标准的 RKE2 安装中的每个命名空间，包括 `default` 和 `kube-system`，`default` service account 必须包含此值：
|
||||
|
||||
```yaml
|
||||
automountServiceAccountToken: false
|
||||
```
|
||||
|
||||
对于由集群操作员创建的命名空间，可以使用以下脚本和配置文件来配置 `default` service account。
|
||||
|
||||
以下配置必须保存到一个名为 `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` service account。
|
||||
|
||||
### API server 审计配置
|
||||
|
||||
CIS 要求 1.2.19 至 1.2.22 与为 API server 配置审计日志有关。当 RKE2 在设置配置文件标志的情况下启动时，它将自动在 API server 中配置加固的 `--audit-log-` 参数以通过这些 CIS 检查。
|
||||
|
||||
RKE2 的默认审计策略被配置为不记录 API server 中的请求。这样做是为了允许集群操作员灵活地定制符合其审计要求和需求的审计策略，因为这些策略是针对每个用户的环境和政策而特定的。
|
||||
|
||||
当使用 `profile` 标志启动 RKE2 时，RKE2 会创建一个默认的审计策略。该策略定义在 `/etc/rancher/rke2/audit-policy.yaml` 中。
|
||||
|
||||
```yaml
|
||||
apiVersion: audit.k8s.io/v1
|
||||
kind: Policy
|
||||
metadata:
|
||||
creationTimestamp: null
|
||||
rules:
|
||||
- level: None
|
||||
```
|
||||
|
||||
## 加固的 RKE2 模板配置参考
|
||||
|
||||
参考模板配置用于在 Rancher 中创建加固的 RKE2 自定义集群。该参考不包括其他必需的**集群配置**指令，这些指令会根据你的环境而有所不同。
|
||||
|
||||
<Tabs groupId="rke2-version">
|
||||
<TabItem value="v1.25 及更新版本" default>
|
||||
|
||||
```yaml
|
||||
apiVersion: provisioning.cattle.io/v1
|
||||
kind: Cluster
|
||||
metadata:
|
||||
name: # 定义集群名称
|
||||
spec:
|
||||
defaultPodSecurityAdmissionConfigurationTemplateName: rancher-restricted
|
||||
kubernetesVersion: # 定义 RKE2 版本
|
||||
rkeConfig:
|
||||
machineSelectorConfig:
|
||||
- config:
|
||||
profile: cis-1.23
|
||||
```
|
||||
</TabItem>
|
||||
|
||||
<TabItem value="v1.24 及更早版本">
|
||||
|
||||
```yaml
|
||||
apiVersion: provisioning.cattle.io/v1
|
||||
kind: Cluster
|
||||
metadata:
|
||||
name: # 定义集群名称
|
||||
spec:
|
||||
defaultPodSecurityPolicyTemplateName: restricted-noroot
|
||||
kubernetesVersion: # 定义 RKE2 版本
|
||||
rkeConfig:
|
||||
machineSelectorConfig:
|
||||
- config:
|
||||
profile: cis-1.6
|
||||
protect-kernel-defaults: true
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## 结论
|
||||
|
||||
如果你按照本指南操作，由 Rancher 提供的 RKE2 自定义集群将配置为通过 CIS Kubernetes Benchmark 测试。你可以查看我们的 RKE2 自我评估指南，了解我们是如何验证每个 benchmarks 的，并且你可以在你的集群上执行相同的操作。
|
||||
+15
-11
@@ -1,30 +1,34 @@
|
||||
---
|
||||
title: RKE2 Self-Assessment Guide - CIS Benchmark v1.23 - K8s v1.23
|
||||
title: RKE2 自我评估指南 - CIS Benchmark v1.23 - K8s v1.23
|
||||
---
|
||||
|
||||
This document is a companion to the [RKE2 Hardening Guide](../../../../pages-for-subheaders/rke2-hardening-guide.md), which provides prescriptive guidance on how to harden RKE2 clusters that are running in production and managed by Rancher. This benchmark guide helps you evaluate the security of a hardened cluster against each control in the CIS Kubernetes Benchmark.
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security/hardening-guides/rke2-hardening-guide/rke2-self-assessment-guide-with-cis-v1.23-k8s-v1.23"/>
|
||||
</head>
|
||||
|
||||
This guide corresponds to the following versions of Rancher, CIS Benchmarks, and Kubernetes:
|
||||
本文档是 [RKE2 加固指南](rke2-hardening-guide.md)的配套文档，该指南提供了关于如何加固正在生产环境中运行并由 Rancher 管理的 RKE2 集群的指导方针。本 benchmark 指南可帮助你根据 CIS Kubernetes Benchmark 中的每个 control 来评估加固集群的安全性。
|
||||
|
||||
| Rancher Version | CIS Benchmark Version | Kubernetes Version |
|
||||
本指南对应以下版本的 Rancher、CIS Benchmarks 和 Kubernetes：
|
||||
|
||||
| Rancher 版本 | CIS Benchmark 版本 | Kubernetes 版本 |
|
||||
|-----------------|-----------------------|--------------------|
|
||||
| Rancher v2.7 | Benchmark v1.23 | Kubernetes v1.23 |
|
||||
|
||||
This guide walks through the various controls and provide updated example commands to audit compliance in Rancher created clusters. Because Rancher and RKE2 install Kubernetes services as Docker containers, many of the control verification checks in the CIS Kubernetes Benchmark don't apply. These checks will return a result of `Not Applicable`.
|
||||
本指南将介绍各种 controls，并提供更新的示例命令来审计 Rancher 创建的集群中的合规性。由于 Rancher 和 RKE2 将 Kubernetes 服务安装为 Docker 容器，因此 CIS Kubernetes Benchmark 中的许多 control 验证检查不适用。这些检查将返回 `Not Applicable` 的结果。
|
||||
|
||||
This document is for Rancher operators, security teams, auditors and decision makers.
|
||||
本文档适用于 Rancher 运维人员、安全团队、审计员和决策者。
|
||||
|
||||
For more information about each control, including detailed descriptions and remediations for failing tests, refer to the corresponding section of the CIS Kubernetes Benchmark v1.23. You can download the benchmark, after creating a free account, at [Center for Internet Security (CIS)](https://www.cisecurity.org/benchmark/kubernetes/).
|
||||
有关每个 control 的更多信息，包括详细描述和未通过测试的补救措施，请参考 CIS Kubernetes Benchmark v1.23 的相应部分。你可以在[互联网安全中心 (CIS)](https://www.cisecurity.org/benchmark/kubernetes/)创建免费账户后下载 benchmark。
|
||||
|
||||
## Testing Methodology
|
||||
## 测试方法
|
||||
|
||||
RKE2 launches control plane components as static pods, managed by the kubelet, and uses containerd as the container runtime. Configuration is defined by arguments passed to the container at the time of initialization or via configuration file.
|
||||
RKE2 将 control plane 组件作为静态 Pod 启动，由 kubelet 管理，并使用 containerd 作为容器运行时。配置是由初始化时或通过配置文件传递给容器的参数定义的。
|
||||
|
||||
Where control audits differ from the original CIS benchmark, the audit commands specific to Rancher are provided for testing. When performing the tests, you will need access to the command line on the hosts of all RKE2 nodes. The commands also make use of the [kubectl](https://kubernetes.io/docs/tasks/tools/) (with a valid configuration file) and [jq](https://stedolan.github.io/jq/) tools, which are required in the testing and evaluation of test results.
|
||||
在 control 审计与原始 CIS benchmark 不同时，提供了针对 Rancher 的特定审计命令以进行测试。在执行测试时，你将需要访问所有 RKE2 节点主机上的命令行。这些命令还使用了 [kubectl](https://kubernetes.io/docs/tasks/tools/)（带有有效的配置文件）和 [jq](https://stedolan.github.io/jq/) 工具，在测试和评估测试结果时这些工具是必需的。
|
||||
|
||||
:::note
|
||||
|
||||
This guide only covers `automated` (previously called `scored`) tests.
|
||||
本指南仅涵盖 `automated`（之前称为 `scored`）测试。
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+3202
File diff suppressed because one or more lines are too long
+2967
File diff suppressed because it is too large
Load Diff
+21
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: Rancher 安全最佳实践
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security/rancher-security-best-practices"/>
|
||||
</head>
|
||||
|
||||
### 限制对 /version 和 /rancherversion 的公共访问
|
||||
|
||||
上游（本地） Rancher 实例提供正在运行的 Rancher 版本和用于构建它的 Go 版本信息。这些信息可以通过 `/version` 路径访问，该路径用于诸如自动化版本升级或确认部署成功等任务。上游实例还提供了可通过 `/rancherversion` 路径访问的 Rancher 版本信息。
|
||||
|
||||
攻击者可能会滥用这些信息来识别正在运行的 Rancher 版本，并与潜在的漏洞相关联以进行利用。如果你的上游 Rancher 实例在网上是公开可访问的，请使用 7 层防火墙来阻止 `/version` 和 `/rancherversion` 路径。
|
||||
|
||||
更多关于保护服务器的详细信息，请参阅 [OWASP Web Application Security Testing - Enumerate Infrastructure and Application Admin Interfaces](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/05-Enumerate_Infrastructure_and_Application_Admin_Interfaces.html)。
|
||||
|
||||
### 会话管理
|
||||
|
||||
某些环境可能需要额外的安全控制来管理会话。例如，你可能希望限制用户的并发活动会话或限制可以从哪些地理位置发起这些会话。Rancher 默认情况下不支持这些功能。
|
||||
|
||||
如果你需要此类功能，请将 7 层防火墙与[外部认证](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config/authentication-config.md#外部认证与本地认证)结合使用。
|
||||
+95
@@ -0,0 +1,95 @@
|
||||
---
|
||||
title: 安全
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security"/>
|
||||
</head>
|
||||
|
||||
<table width="100%">
|
||||
<tr style={{verticalAlign: 'top'}}>
|
||||
<td width="30%" style={{border: 'none'}}>
|
||||
<h4>安全策略</h4>
|
||||
<p style={{padding: '8px'}}>Rancher Labs 会负责任地披露问题，并致力于在合理的时间内解决所有问题。 </p>
|
||||
</td>
|
||||
<td width="30%" style={{border: 'none'}}>
|
||||
<h4>报告流程</h4>
|
||||
<p style={{padding: '8px'}}>请将安全问题发送至 <a href="mailto:security-rancher@suse.com">security-rancher@suse.com</a>。</p>
|
||||
</td>
|
||||
<td width="30%" style={{border: 'none'}}>
|
||||
<h4>公告</h4>
|
||||
<p style={{padding:'8px'}}>订阅 <a href="https://forums.rancher.com/c/announcements">Rancher 公告论坛</a>以获取版本更新。</p>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
安全是 Rancher 全部功能的基础。Rancher 集成了全部主流认证工具和服务，并提供了企业级的 [RBAC 功能](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/manage-role-based-access-control-rbac.md)，让你的 Kubernetes 集群更加安全。
|
||||
|
||||
本文介绍了安全相关的文档以及资源，让你的 Rancher 安装和下游 Kubernetes 集群更加安全。
|
||||
|
||||
### NeuVector 与 Rancher 的集成
|
||||
|
||||
NeuVector 是一个开源的、以容器为中心的安全应用程序，现已集成到 Rancher 中。NeuVector 提供生产安全、DevOps 漏洞保护和容器防火墙等功能。请参阅 [Rancher 文档](../../integrations-in-rancher/neuvector/neuvector.md) 和 [NeuVector 文档](https://open-docs.neuvector.com/)了解更多信息。
|
||||
|
||||
### 在 Kubernetes 集群上运行 CIS 安全扫描
|
||||
|
||||
Rancher 使用 [kube-bench](https://github.com/aquasecurity/kube-bench) 来运行安全扫描，从而检查 Kubernetes 是否按照 [CIS](https://www.cisecurity.org/cis-benchmarks/)（Center for Internet Security，互联网安全中心）Kubernetes Benchmark 中定义的安全最佳实践进行部署。
|
||||
|
||||
CIS Kubernetes Benchmark 是一个参考文档，用于为 Kubernetes 建立安全配置基线。
|
||||
|
||||
CIS 是一个 501(c\)(3) 非营利组织，成立于 2000 年 10 月，其使命是识别、开发、验证、促进和维持网络防御的最佳实践方案，并建立和指导社区，以在网络空间中营造信任的环境。
|
||||
|
||||
CIS Benchmark 是目标系统安全配置的最佳实践。CIS Benchmark 是由安全专家、技术供应商、公开和私人社区成员，以及 CIS Benchmark 开发团队共同志愿开发的。
|
||||
|
||||
Benchmark 提供两种类型的建议，分别是自动（Automated）和手动（Manual）。我们只运行 Automated 相关的测试。
|
||||
|
||||
Rancher 在集群上运行 CIS 安全扫描时会生成一份报告，该报告会显示每个测试的结果，包括测试概要以及 `passed`、`skipped` 和 `failed` 的测试数量。报告还包括失败测试的修正步骤。
|
||||
|
||||
有关详细信息，请参阅[安全扫描](../../how-to-guides/advanced-user-guides/cis-scan-guides/cis-scan-guides.md)。
|
||||
|
||||
### SELinux RPM
|
||||
|
||||
[安全增强型 Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) 是对 Linux 的安全增强。被政府机构使用之后，SELinux 已成为行业标准，并在 CentOS 7 和 8 上默认启用。
|
||||
|
||||
我们提供了 `rancher-selinux` 和 `rke2-selinux` 两个 RPM（Red Hat 软件包），让 Rancher 产品能够在 SELinux 主机上正常运行。有关详细信息，请参阅[此页面](selinux-rpm/selinux-rpm.md)。
|
||||
|
||||
### Rancher 加固指南
|
||||
|
||||
Rancher 加固指南基于 <a href="https://www.cisecurity.org/benchmark/kubernetes/" target="_blank">CIS Kubernetes Benchmark</a>。
|
||||
|
||||
加固指南为加固 Rancher 的生产安装提供了说明性指导。有关安全管控的完整列表，请参阅 Rancher 的 [CIS Kubernetes Benchmark 自我评估](#cis-benchmark-和自我评估)指南。
|
||||
|
||||
> 加固指南描述了如何保护集群中的节点，建议在安装 Kubernetes 之前参考加固指南中的步骤。
|
||||
|
||||
每个加固指南版本都针对特定的 CIS Kubernetes Benchmark、Kubernetes 和 Rancher 版本。
|
||||
|
||||
### CIS Benchmark 和自我评估
|
||||
|
||||
Benchmark 自我评估是 Rancher 安全加固指南的辅助。加固指南展示了如何加固集群，而 Benchmark 指南旨在帮助你评估加固集群的安全级别。
|
||||
|
||||
由于 Rancher 和 RKE 将 Kubernetes 服务安装为 Docker 容器，因此 CIS Kubernetes Benchmark 中的许多管控验证检查都不适用。本指南将介绍各种 controls，并提供更新的示例命令来审计 Rancher 创建的集群的合规性。你可以前往 [CIS 网站](https://www.cisecurity.org/benchmark/kubernetes/)下载原始的 Benchmark 文档。
|
||||
|
||||
Rancher 自我评估指南的每个版本都对应于强化指南、Rancher、Kubernetes 和 CIS Benchmark 的特定版本。
|
||||
|
||||
### 第三方渗透测试报告
|
||||
|
||||
Rancher 会定期聘请第三方对 Rancher 软件栈进行安全审计和渗透测试。被测环境遵循 Rancher 在测试时提供的强化指南。以前的渗透测试报告如下。
|
||||
|
||||
结果：
|
||||
|
||||
- [Cure53 渗透测试 - 2019 年 7 月](https://releases.rancher.com/documents/security/pen-tests/2019/RAN-01-cure53-report.final.pdf)
|
||||
- [Untamed Theory 渗透测试 - 2019 年 3 月](https://releases.rancher.com/documents/security/pen-tests/2019/UntamedTheory-Rancher_SecurityAssessment-20190712_v5.pdf)
|
||||
|
||||
请注意，新报告不再共享或公开发布。
|
||||
|
||||
### Rancher 安全公告和 CVE
|
||||
|
||||
Rancher 致力于向社区通报我们产品中的安全问题。有关我们已解决的问题的 CVE（常见漏洞和暴露）列表，请参阅[此页](security-advisories-and-cves.md)。
|
||||
|
||||
### Kubernetes 安全最佳实践
|
||||
|
||||
有关保护 Kubernetes 集群的建议，请参阅 [Kubernetes 安全最佳实践](kubernetes-security-best-practices.md)指南。
|
||||
|
||||
### Rancher 安全最佳实践
|
||||
|
||||
有关保护 Rancher Manager 部署的建议，请参阅 [Rancher 安全最佳实践](rancher-security-best-practices.md)指南。
|
||||
+11
-3
@@ -2,10 +2,18 @@
|
||||
title: 安全公告和 CVE
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security/security-advisories-and-cves"/>
|
||||
</head>
|
||||
|
||||
Rancher 致力于向社区披露我们产品的安全问题。我们会针对已解决的问题发布安全公告和 CVE（Common Vulnerabilities and Exposures，通用漏洞披露）。Rancher GitHub 上的[安全页面](https://github.com/rancher/rancher/security/advisories)也会发布新的安全公告。
|
||||
|
||||
| ID | 描述 | 日期 | 解决 |
|
||||
|----|-------------|------|------------|
|
||||
| [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) |
|
||||
| [CVE-2023-32194](https://github.com/rancher/rancher/security/advisories/GHSA-c85r-fwc7-45vc) | 在 Rancher 2.6.13、2.7.9 和 2.8.1 及之前的版本中发现了一个问题。当为 “namespace” 资源类型授予 `create` 或 `*` 全局角色时，任何 API 组中拥有权限的用户可以管理核心 API 组中的 namespace。 | 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-22648](https://github.com/rancher/rancher/security/advisories/GHSA-vf6j-6739-78m8) | 在 Rancher 2.6.12 和 2.7.3 及之前的版本中发现了一个问题。在用户注销并重新登录到 Rancher UI 之前，Azure AD 中的权限更改不会反映给用户。 | 2023 年 5 月 31 日 | Rancher [v2.7.4](https://github.com/rancher/rancher/releases/tag/v2.7.4) |
|
||||
| [CVE-2022-43760](https://github.com/rancher/rancher/security/advisories/GHSA-46v3-ggjg-qq3x) | 在 Rancher 2.6.12 和 2.7.3 及之前的版本中发现了一个问题。攻击者可以通过 Rancher UI 利用多个跨站脚本 (XSS) 漏洞。 | 2023 年 5 月 31 日 | Rancher [v2.7.4](https://github.com/rancher/rancher/releases/tag/v2.7.4) |
|
||||
| [CVE-2020-10676](https://github.com/rancher/rancher/security/advisories/GHSA-8vhc-hwhc-cpj4) | 在 Rancher 2.6.12 和 2.7.3 及之前的版本中发现了一个问题。具有更新命名空间权限的用户可以将该命名空间移动到他们无权访问的项目中。 | 2023 年 5 月 31 日 | Rancher [v2.7.4](https://github.com/rancher/rancher/releases/tag/v2.7.4) |
|
||||
@@ -19,10 +27,10 @@ Rancher 致力于向社区披露我们产品的安全问题。我们会针对已
|
||||
| [CVE-2022-31247](https://github.com/rancher/rancher/security/advisories/GHSA-6x34-89p7-95wg) | 在 Rancher 2.5.15 和 2.6.6 及之前的版本中发现了一个问题。授权逻辑缺陷允许在下游集群中通过集群角色模板绑定 (CRTB) 和项目角色模板绑定 (PRTB) 来提升权限。任何有权限创建/编辑 CRTB 或 PRTB 的用户（例如 `cluster-owner`、`manage cluster members`、`project-owner` 和 `manage project members`）都可以利用该漏洞，在同一集群的另一个项目或不同下游集群的另一个项目中获得所有者权限。 | 2022 年 8 月 18 日 | [Rancher 2.6.7](https://github.com/rancher/rancher/releases/tag/v2.6.7) 和 [Rancher 2.5.16](https://github.com/rancher/rancher/releases/tag/v2.5.16) |
|
||||
| [CVE-2021-36783](https://github.com/rancher/rancher/security/advisories/GHSA-8w87-58w6-hfv8) | 2.5.12 到 2.6.3 的 Rancher 版本无法正确清理集群模板 answer 中的凭证。此错误可能会导致明文存储以及凭证、密码和 API 令牌被暴露。在 Rancher 中，已认证的 `Cluster Owner`、`Cluster Member`、`Project Owner` 和 `Project Member` 可以在 `/v1/management.cattle.io.clusters`、`/v3/clusters` 和 `/k8s/clusters/local/apis/management.cattle.io/v3/clusters` 端点上看到暴露的凭证。 | 2022 年 8 月 18 日 | [Rancher 2.6.7](https://github.com/rancher/rancher/releases/tag/v2.6.7) 和 [Rancher 2.5.16](https://github.com/rancher/rancher/releases/tag/v2.5.16) |
|
||||
| [CVE-2021-36782](https://github.com/rancher/rancher/security/advisories/GHSA-g7j7-h4q8-8w2f) | 在 2.5.15 到 2.6.6 的 Rancher 版本中发现了一个问题，其中密码、API 密钥和 Rancher 的 ServiceAccount 令牌（用于配置集群）等敏感字段直接以明文形式存储在 `Cluster` 等 Kubernetes 对象上（例如，`cluster.management.cattle.io`）。任何能够读取 Kubernetes API 中的对象的用户都可以检索这些敏感数据的明文版本。该问题由 Florian Struck（来自 [Continum AG](https://www.continum.net/)）和 [Marco Stuurman](https://github.com/fe-ax)（来自 [Shock Media B.V.](https://www.shockmedia.nl/)）发现并报告。 | 2022 年 8 月 18 日 | [Rancher 2.6.7](https://github.com/rancher/rancher/releases/tag/v2.6.7) 和 [Rancher 2.5.16](https://github.com/rancher/rancher/releases/tag/v2.5.16) |
|
||||
| [CVE-2022-21951](https://github.com/rancher/rancher/security/advisories/GHSA-vrph-m5jj-c46c) | 此漏洞仅影响通过 [RKE 模板](https://rancher.com/docs/rancher/v2.6/en/admin-settings/rke-templates/)配置 [Weave](https://rancher.com/docs/rancher/v2.6/en/faq/networking/cni-providers/#weave) 容器网络接口 (CNI) 的客户。在 Rancher 2.5.0 到 2.5.13 和 Rancher 2.6.0 到 2.6.4 版本中发现了一个漏洞。如果将 CNI 选为 Weave，RKE 模板的用户界面 (UI) 不包括 Weave 密码的值。如果基于上述模板创建集群，并且将 Weave 配置为 CNI，则 Weave 中不会为[网络加密](https://www.weave.works/docs/net/latest/tasks/manage/security-untrusted-networks/)创建密码。因此，集群中的网络流量将不加密发送。 | 2022 年 5 月 24 日 | [Rancher 2.6.5](https://github.com/rancher/rancher/releases/tag/v2.6.5) 和 [Rancher 2.5.14](https://github.com/rancher/rancher/releases/tag/v2.5.14) |
|
||||
| [CVE-2021-36784](https://github.com/rancher/rancher/security/advisories/GHSA-jwvr-vv7p-gpwq) | 在 Rancher 2.5.0 到 2.5.12 和 Rancher 2.6.0 到 2.6.3 中发现了一个漏洞，该漏洞允许能创建或更新[全局角色](https://rancher.com/docs/rancher/v2.6/en/admin-settings/rbac/)的用户将他们或其他用户升级为管理员。全局角色能授予用户 Rancher 级别的权限，例如能创建集群。在已识别的 Rancher 版本中，如果用户被授予了编辑或创建全局角色的权限，他们不仅仅能授予他们已经拥有的权限。此漏洞影响使用能够创建或编辑全局角色的非管理员用户的客户。此场景最常见的用例是 `restricted-admin` 角色。 | 2022 年 4 月 14 日 | [Rancher 2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) 和 [Rancher 2.5.13](https://github.com/rancher/rancher/releases/tag/v2.5.13) |
|
||||
| [CVE-2022-21951](https://github.com/rancher/rancher/security/advisories/GHSA-vrph-m5jj-c46c) | 此漏洞仅影响通过 [RKE 模板](../../pages-for-subheaders/about-rke1-templates.md)配置 [Weave](../../faq/container-network-interface-providers.md#weave) 容器网络接口 (CNI) 的客户。在 Rancher 2.5.0 到 2.5.13 和 Rancher 2.6.0 到 2.6.4 版本中发现了一个漏洞。如果将 CNI 选为 Weave，RKE 模板的用户界面 (UI) 不包括 Weave 密码的值。如果基于上述模板创建集群，并且将 Weave 配置为 CNI，则 Weave 中不会为[网络加密](https://www.weave.works/docs/net/latest/tasks/manage/security-untrusted-networks/)创建密码。因此，集群中的网络流量将不加密发送。 | 2022 年 5 月 24 日 | [Rancher 2.6.5](https://github.com/rancher/rancher/releases/tag/v2.6.5) 和 [Rancher 2.5.14](https://github.com/rancher/rancher/releases/tag/v2.5.14) |
|
||||
| [CVE-2021-36784](https://github.com/rancher/rancher/security/advisories/GHSA-jwvr-vv7p-gpwq) | 在 Rancher 2.5.0 到 2.5.12 和 Rancher 2.6.0 到 2.6.3 中发现了一个漏洞，该漏洞允许能创建或更新[全局角色](../../pages-for-subheaders/manage-role-based-access-control-rbac.md)的用户将他们或其他用户升级为管理员。全局角色能授予用户 Rancher 级别的权限，例如能创建集群。在已识别的 Rancher 版本中，如果用户被授予了编辑或创建全局角色的权限，他们不仅仅能授予他们已经拥有的权限。此漏洞影响使用能够创建或编辑全局角色的非管理员用户的客户。此场景最常见的用例是 `restricted-admin` 角色。 | 2022 年 4 月 14 日 | [Rancher 2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) 和 [Rancher 2.5.13](https://github.com/rancher/rancher/releases/tag/v2.5.13) |
|
||||
| [CVE-2021-4200](https://github.com/rancher/rancher/security/advisories/GHSA-hx8w-ghh8-r4xf) | 此漏洞仅影响在 Rancher 中使用 `restricted-admin` 角色的客户。在 Rancher 2.5.0 到 2.5.12 和 2.6.0 到 2.6.3 中发现了一个漏洞，其中 `cattle-global-data` 命名空间中的 `global-data` 角色授予了应用商店的写权限。由于具有任何级别的应用商店访问权限的用户都会绑定到 `global-data` 角色，因此这些用户都能写入模板 `CatalogTemplates`) 和模板版本 (`CatalogTemplateVersions`)。在 Rancher 中创建的新用户默认分配到 `user` 角色（普通用户），该角色本不该具有写入应用商店的权限。此漏洞提升了能写入应用商店模板和应用商店模板版本资源的用户的权限。 | 2022 年 4 月 14 日 | [Rancher 2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) 和 [Rancher 2.5.13](https://github.com/rancher/rancher/releases/tag/v2.5.13) |
|
||||
| [GHSA-wm2r-rp98-8pmh](https://github.com/rancher/rancher/security/advisories/GHSA-wm2r-rp98-8pmh) | 此漏洞仅影响使用经过认证的 Git 和/或 Helm 仓库通过 [Fleet](https://rancher.com/docs/rancher/v2.6/en/deploy-across-clusters/fleet/) 进行持续交付的客户。在 [`v1.5.11`](https://github.com/hashicorp/go-getter/releases/tag/v1.5.11) 之前版本中的 `go-getter` 库中发现了一个问题，错误消息中没有删除 Base64 编码的 SSH 私钥，导致该信息暴露。Rancher 中 [`v0.3.9`](https://github.com/rancher/fleet/releases/tag/v0.3.9) 之前的 Fleet 版本使用了该库的漏洞版本。此问题影响 Rancher 2.5.0 到 2.5.12（包括 2.5.12）以及 2.6.0 到 2.6.3（包括 2.6.3）。该问题由 Raft Engineering 的 Dagan Henderson 发现并报告。 | 2022 年 4 月 14 日 | [Rancher 2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) 和 [Rancher 2.5.13](https://github.com/rancher/rancher/releases/tag/v2.5.13) |
|
||||
| [GHSA-wm2r-rp98-8pmh](https://github.com/rancher/rancher/security/advisories/GHSA-wm2r-rp98-8pmh) | 此漏洞仅影响使用经过认证的 Git 和/或 Helm 仓库通过 [Fleet](../../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md) 进行持续交付的客户。在 [`v1.5.11`](https://github.com/hashicorp/go-getter/releases/tag/v1.5.11) 之前版本中的 `go-getter` 库中发现了一个问题，错误消息中没有删除 Base64 编码的 SSH 私钥，导致该信息暴露。Rancher 中 [`v0.3.9`](https://github.com/rancher/fleet/releases/tag/v0.3.9) 之前的 Fleet 版本使用了该库的漏洞版本。此问题影响 Rancher 2.5.0 到 2.5.12（包括 2.5.12）以及 2.6.0 到 2.6.3（包括 2.6.3）。该问题由 Raft Engineering 的 Dagan Henderson 发现并报告。 | 2022 年 4 月 14 日 | [Rancher 2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) 和 [Rancher 2.5.13](https://github.com/rancher/rancher/releases/tag/v2.5.13) |
|
||||
| [CVE-2021-36778](https://github.com/rancher/rancher/security/advisories/GHSA-4fc7-hc63-7fjg) | 在 Rancher 2.5.0 到 2.5.11 和 Rancher 2.6.0 到 2.6.2 中发现了一个漏洞，当从配置的私有仓库下载 Helm Chart 时，对同源策略的检查不足可能导致仓库凭证暴露给第三方提供商。仅当用户在 Rancher 的`应用 & 应用市场 > 仓库`中配置私有仓库的访问凭证时才会出现此问题。该问题由 Martin Andreas Ullrich 发现并报告。 | 2022 年 4 月 14 日 | [Rancher 2.6.3](https://github.com/rancher/rancher/releases/tag/v2.6.3) 和 [Rancher 2.5.12](https://github.com/rancher/rancher/releases/tag/v2.5.12) |
|
||||
| [GHSA-hwm2-4ph6-w6m5](https://github.com/rancher/rancher/security/advisories/GHSA-hwm2-4ph6-w6m5) | 在 Rancher 2.0 到 2.6.3 中发现了一个漏洞。Rancher 提供的 `restricted` Pod 安全策略（PSP）与 Kubernetes 提供的上游 `restricted` 策略有差别，因此 Rancher 的 PSP 将 `runAsUser` 设置为 `runAsAny`，而上游将 `runAsUser` 设置为 `MustRunAsNonRoot`。因此，即使 Rancher 的 `restricted` 策略是在项目或集群级别上强制执行的，容器也可以以任何用户身份运行，包括特权用户 (`root`)。 | 2022 年 3 月 31 日 | [Rancher 2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) |
|
||||
| [CVE-2021-36775](https://github.com/rancher/rancher/security/advisories/GHSA-28g7-896h-695v) | 在 Rancher 2.4.17、2.5.11 和 2.6.2 以及更高的版本中发现了一个漏洞。从项目中删除与某个组关联的`项目角色`后，能让这些使用者访问集群级别资源的绑定（Binding）不会被删除。导致问题的原因是不完整的授权逻辑检查。如果用户是受影响组中的成员，且能对 Rancher 进行认证访问，那么用户可以利用此漏洞访问他们不应该能访问的资源。暴露级别取决于受影响项目角色的原始权限级别。此漏洞仅影响在 Rancher 中基于组进行身份验证的客户。 | 2022 年 3 月 31 日 | [Rancher 2.6.3](https://github.com/rancher/rancher/releases/tag/v2.6.3)、[Rancher 2.5.12](https://github.com/rancher/rancher/releases/tag/v2.5.12) 和 [Rancher 2.4.18](https://github.com/rancher/rancher/releases/tag/v2.4.18) |
|
||||
|
||||
+20
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: SELinux RPM
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security/selinux-rpm"/>
|
||||
</head>
|
||||
|
||||
[安全增强型 Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) 是对 Linux 的安全增强。
|
||||
|
||||
它由 Red Hat 开发，是 Linux 上 MAC（mandatory access controls，强制访问控制）的实现。系统管理员可以使用 MAC 设置应用程序和用户是如何访问不同资源的，例如文件、设备、网络和进程间的通信。SELinux 还通过默认限制操作系统来增强安全性。
|
||||
|
||||
被政府机构使用之后，SELinux 已成为行业标准，并在 CentOS 7 和 8 上默认启用。要检查 SELinux 是否在你的系统上启用和执行，请使用 `getenforce`：
|
||||
|
||||
```
|
||||
# getenforce
|
||||
Enforcing
|
||||
```
|
||||
|
||||
我们提供了 [`rancher-selinux`](about-rancher-selinux.md) 和 [`rke2-selinux`](about-rke2-selinux.md) 两个 RPM（Red Hat 软件包），让 Rancher 产品能够在 SELinux 主机上正常运行。
|
||||
+115
-1
@@ -2,10 +2,37 @@
|
||||
title: Rancher Webhook
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-webhook"/>
|
||||
</head>
|
||||
|
||||
Rancher-Webhook 是 Rancher 的重要组件，它与 Kubernetes 结合使用，用于增强安全性并为 Rancher 管理的集群启用关键功能。
|
||||
|
||||
如 [Kubernetes 文档](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/)中所述，它与 Kubernetes 的可扩展准入控制器集成，允许 Rancher-Webhook 检查发送到 Kubernetes API Server 的特定请求，添加自定义和 Rancher 相关的验证，以及 Rancher 相关请求的变化。Rancher-Webhook 使用 `rancher.cattle.io` `ValidatingWebhookConfiguration` 和 `rancher.cattle.io` `MutatingWebhookConfiguration` 管理要验证的资源，并覆盖任何手动编辑。
|
||||
Rancher 将 Rancher-Webhook 作为单独的 deployment 和服务部署在 local 和下游集群中。Rancher 使用 Helm 管理 Rancher-Webhook。需要注意的是，Rancher 可能会覆盖用户对 Helm 版本所做的修改。
|
||||
|
||||
Rancher 将 Rancher-Webhook 作为单独的 deployment 和服务部署在 local 和下游集群中。Rancher 使用 Helm 管理 Rancher-Webhook。需要注意的是，Rancher 可能会覆盖用户对 Helm 版本所做的修改。要安全地修改这些值，请参阅[自定义 Rancher-Webhook 配置](#自定义-rancher-webhook-配置)
|
||||
|
||||
每个 Rancher 版本都设计为与某个具体版本的 Webhook 兼容，为方便起见，下面提供了各版本的兼容列表。
|
||||
|
||||
**注意：** Rancher 负责管理 webhook 的部署和升级。在多数情况下，不需要用户干预来确保 webhook 版本与你正在运行的 Rancher 版本兼容。
|
||||
|
||||
<!-- releaseTask -->
|
||||
|
||||
| Rancher Version | Webhook Version | Availability in Prime | Availability in Community |
|
||||
| --------------- | --------------- | --------------------- | ------------------------- |
|
||||
| v2.7.12 | v0.3.7 | ✓ | N/A |
|
||||
| v2.7.11 | v0.3.7 | ✓ | N/A |
|
||||
| v2.7.10 | v0.3.6 | ✓ | ✓ |
|
||||
| v2.7.9 | v0.3.6 | ✗ | ✓ |
|
||||
| v2.7.8 | v0.3.6 | ✗ | ✓ |
|
||||
| v2.7.7 | v0.3.6 | ✓ | ✓ |
|
||||
| v2.7.6 | v0.3.5 | ✓ | ✓ |
|
||||
| v2.7.5 | v0.3.5 | ✓ | ✓ |
|
||||
| v2.7.4 | v0.3.4 | ✓ | ✓ |
|
||||
| v2.7.3 | v0.3.3 | ✓ | ✓ |
|
||||
| v2.7.2 | v0.3.2 | ✓ | ✓ |
|
||||
| v2.7.1 | v0.3.0 | ✓ | ✓ |
|
||||
| v2.7.0 | v0.3.0 | ✓ | ✓ |
|
||||
|
||||
## 为什么我们需要它？
|
||||
|
||||
@@ -13,6 +40,58 @@ Rancher-Webhook 对于让 Rancher 保护集群免受恶意攻击并启用各种
|
||||
Rancher 依赖 Rancher-Webhook 作为其功能的组成部分。如果没有 Webhook，Rancher 将不是一个完整的产品。
|
||||
它为 Rancher 管理的集群提供了必要的保护，防止安全漏洞并确保集群的一致性和稳定性。
|
||||
|
||||
## Webhook 验证哪些资源?
|
||||
|
||||
你可以在 [webhook 仓库](https://github.com/rancher/webhook/blob/release/v0.4/docs.md)中找到 webhook 当前验证的资源列表。这些文档按组/版本（顶级标题）和资源（下一级标题）进行组织。可以通过查看与特定版本标签关联的 `docs.md` 文件来找到特定于一个版本的检查。请注意，`v0.3.6` 之前的 webhook 版本没有此文件。
|
||||
|
||||
## 绕过 Webhook
|
||||
|
||||
有时，你必须绕过 Rancher 的 webhook 验证才能执行紧急还原操作或修复其他关键问题。避开操作是彻底的，这意味着在使用它时不会应用任何 webhook 验证或更改。不可能指定绕过某些验证，而让其他验证仍然可用。它们要么全部被绕过，要么全部处于活动状态。
|
||||
|
||||
:::danger
|
||||
|
||||
Rancher 的 webhook 提供关键的安全保护。只有在所有其他选项都用尽之后，管理员才需要在特定情况下绕过 webhook。此外，应仔细控制绕过 webhook 的权限，切勿将该权限授予非管理员用户。
|
||||
|
||||
:::
|
||||
|
||||
要绕过 webhook，请模拟 `rancher-webhook-sudo` 服务账号和 `system:masters` 组（两者都是必需的）：
|
||||
|
||||
```bash
|
||||
kubectl create -f example.yaml --as=system:serviceaccount:cattle-system:rancher-webhook-sudo --as-group=system:masters
|
||||
```
|
||||
|
||||
## 自定义 Rancher-Webhook 配置
|
||||
|
||||
你可以通过 Helm 安装 Rancher-Webhook 时添加自定义 Helm values。在 Rancher-Webhook chart 的安装过程中，Rancher 会检查自定义的 Helm values。这些自定义值必须在 `cattle-system` 命名空间中，名称为 `rancher-config` 的 ConfigMap 的 data 属性下，增加 `rancher-webhook` 的配置定义。此键的值必须是有效的 YAML。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: rancher-config
|
||||
namespace: cattle-system
|
||||
labels:
|
||||
app.kubernetes.io/part-of: "rancher"
|
||||
data:
|
||||
rancher-webhook: '{"port": 9553, "priorityClassName": "system-node-critical"}'
|
||||
```
|
||||
|
||||
Rancher 会在检测到对 ConfigMap 值的更改时重新部署 Rancher-Webhook Chart。
|
||||
|
||||
### 在 Rancher 安装过程中自定义 Rancher-Webhook
|
||||
|
||||
使用 Helm 安装 Rancher chart 时，可以在 local 集群中将自定义的 Helm values 添加到 Rancher-Webhook。Rancher-Webhook Chart 中的所有值都可以通过 `webhook` 名称下的嵌套变量访问。
|
||||
|
||||
这些值在安装过程中会同步到 `rancher-config` ConfigMap 中。
|
||||
|
||||
```bash
|
||||
helm install rancher rancher-<CHART_REPO>/rancher \
|
||||
--namespace cattle-system \
|
||||
...
|
||||
--set webhook.port=9553 \
|
||||
--set webhook.priorityClassName="system-node-critical"
|
||||
```
|
||||
|
||||
## 常见问题
|
||||
|
||||
### 带有 Calico CNI 的 EKS 集群
|
||||
@@ -24,8 +103,11 @@ Rancher 依赖 Rancher-Webhook 作为其功能的组成部分。如果没有 Web
|
||||
helm repo add rancher-charts https://charts.rancher.io
|
||||
helm upgrade --reuse-values rancher-webhook rancher-chart/rancher-webhook -n cattle-system --set global.hostNetwork=true
|
||||
```
|
||||
|
||||
**注意**：这个临时解决方法可能会违反环境的安全策略。此解决方法还要求主机网络上未使用端口 9443。
|
||||
|
||||
**注意：** 默认情况下，Helm 使用 secrets。这是某些 webhook 版本验证用于存储信息的数据类型。在这种情况下，请使用 kubectl 更新 deployment 设置 `hostNetwork=true`，然后按照上述配置更新 webhook。
|
||||
|
||||
### 私有 GKE 集群
|
||||
|
||||
使用私有 GKE 集群时可能会发生错误，导致 Kubernetes API Server 无法与 Webhook 通信。以下错误消息可能会出现：
|
||||
@@ -33,4 +115,36 @@ helm upgrade --reuse-values rancher-webhook rancher-chart/rancher-webhook -n ca
|
||||
```
|
||||
Internal error occurred: failed calling webhook "rancher.cattle.io.namespaces.create-non-kubesystem": failed to call webhook: Post "https://rancher-webhook.cattle-system.svc:443/v1/webhook/validation/namespaces?timeout=10s": context deadline exceeded
|
||||
```
|
||||
|
||||
出现此问题的原因是防火墙规则限制了 API Server 与私有集群之间的通信。要解决此通信问题，你必须通过添加防火墙规则来允许 GKE Control Plane 通过端口 9443 与 Rancher-Webhook 进行通信。请参阅 [GKE 文档](https://cloud.google.com/kubernetes-engine/docs/how-to/private-clusters#add_firewall_rules)，了解更新防火墙规则的详细信息和步骤。
|
||||
|
||||
### 由于 rancher-webhook 阻止访问导致应用部署失败
|
||||
|
||||
webhook 在 [namespaces](https://github.com/rancher/webhook/blob/release/v0.4/docs.md#psa-label-validation) 上提供额外的验证。其中一项验证可确保用户只有在具有适当权限的情况下才能更新 PSA 相关标签（`updatepsa` for `projects` in `management.cattle.io`）。这可能导致特定 operator（如 Tigera 或 Trident）在尝试部署带有 PSA 标签的命名空间时失败。有几种方法可以解决此问题：
|
||||
|
||||
- 将应用程序配置为创建没有 PSA 标签的命名空间。如果用户希望将 PSA 应用于这些命名空间，则可以在配置后将它们添加到具有所需 PSA 的项目中。请参阅[设置 PSS 和 PSA 资源的文档](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/pod-security-standards.md)获取更具体的操作方法。
|
||||
- 这是首选选项，但并非所有应用程序都可以以这种方式进行配置。
|
||||
- 手动授予操作员管理命名空间下的 PSA 的权限。
|
||||
- 此选项将引入安全风险，因为运营商现在将能够为其有权访问的命名空间设置 PSA。这可能允许操作员部署特权 Pod，或通过其他方式实现集群接管。
|
||||
- 具有适当权限的用户帐户可以使用适当的配置预先创建命名空间。
|
||||
- 此选项取决于应用程序处理现有资源的能力。
|
||||
|
||||
## 特定版本的问题
|
||||
|
||||
**注意：** 以下是影响特定 Rancher/webhook 版本的高严重性问题的不完整列表。在大多数情况下，这些问题可以通过升级到更新的 Rancher 版本来解决。
|
||||
|
||||
### 回滚到不兼容的 Webhook 版本
|
||||
|
||||
**注意：** 这会影响回滚到 Rancher v2.7.5 或更早版本。
|
||||
|
||||
如果回滚到 Rancher v2.7.5 或更早版本，您可能会看到 webhook 版本太新，无法与运行 v2.7.5 之前版本的 Rancher 的下游集群兼容。这可能会导致各种不兼容问题。例如，项目成员可能无法创建命名空间。此外，当您回滚到下游集群中安装 webhook 之前的版本时，webhook 可能仍保持安装状态，这会导致类似的不兼容问题。
|
||||
|
||||
为了帮助缓解这些问题，您可以在回滚后运行 [adjust-downstream-webhook](https://github.com/rancherlabs/support-tools/tree/master/adjust-downstream-webhook) shell 脚本。该脚本为相应的 Rancher 版本选择并安装正确的 webhook 版本（或完全删除 webhook）。
|
||||
|
||||
### 项目用户无法创建命名空间
|
||||
|
||||
**注意：** 以下内容影响 Rancher v2.7.2 - v2.7.4。
|
||||
|
||||
项目用户可能无法在项目中创建命名空间，这包括项目所有者。此问题是由于 Rancher 自动将 webhook 升级到与当前安装的 Rancher 版本更新的版本不兼容而导致的。
|
||||
|
||||
为了帮助缓解这些问题，您可以在回滚后运行 [adjust-downstream-webhook](https://github.com/rancherlabs/support-tools/tree/master/adjust-downstream-webhook) shell 脚本。该脚本为相应的 Rancher 版本选择并安装正确的 webhook 版本（或完全删除 webhook）。
|
||||
|
||||
+9
@@ -0,0 +1,9 @@
|
||||
---
|
||||
title: Docker 中的单节点 Rancher
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/single-node-rancher-in-docker"/>
|
||||
</head>
|
||||
|
||||
以下文档将讨论 Docker 安装的 [HTTP 代理配置](http-proxy-configuration.md)和[高级选项](advanced-options.md)。
|
||||
+19
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: 用户设置
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/user-settings"/>
|
||||
</head>
|
||||
|
||||
在 Rancher 中，每个用户都有很多与登录相关的设置，例如个人偏好、API 密钥等。你可以从**用户设置**菜单中配置这些设置。你可以单击主菜单中的头像来打开此菜单。
|
||||
|
||||
|
||||
|
||||
可用的用户设置包括：
|
||||
|
||||
- [API & 密钥](api-keys.md)：如果你想以编程方式与 Rancher 交互，你需要一个 API 密钥。你可以按照本节中的说明获取密钥。
|
||||
- [云凭证](manage-cloud-credentials.md)：管理[节点模板](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#节点模板)使用的云凭证，从而[为集群配置节点](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md)。
|
||||
- [节点模板](manage-node-templates.md)：管理 [Rancher 用来为集群配置节点](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md)的模板。
|
||||
- [偏好设置](user-preferences.md)：设置 Rancher UI 的表面首选项。
|
||||
- 登出：结束你的用户会话。
|
||||
Reference in New Issue
Block a user