mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-05-05 12:43:16 +00:00
Archiving the v2.6/v2.7 zh docs. Updating the zh sidebar version JSON files to reflect archived messaging in navigation dropdown.
Signed-off-by: Sunil Singh <sunil.singh@suse.com>
This commit is contained in:
Sunil Singh
+15
@@ -0,0 +1,15 @@
|
||||
---
|
||||
title: Kubernetes 安全最佳实践
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/reference-guides/rancher-security/kubernetes-security-best-practices"/>
|
||||
</head>
|
||||
|
||||
### 限制云元数据 API 访问
|
||||
|
||||
AWS、Azure、DigitalOcean 或 GCP 等云提供商通常会在本地向实例公开元数据服务。默认情况下，此端点可被运行在云实例上的 pod 访问，包括在托管的 Kubernetes（如 EKS、AKS、DigitalOcean Kubernetes 或 GKE）中的 pod，并且可以包含该节点的云凭证、配置数据（如 kubelet 凭证）以及其他敏感数据。为了降低在云平台上运行的这种风险，请遵循 [Kubernetes 安全建议](https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/#restricting-cloud-metadata-api-access)，即限制授予实例凭证的权限，使用网络策略限制 pod 对元数据 API 的访问，并避免使用配置数据来传递密文。
|
||||
|
||||
建议你参阅你使用的云提供商的安全最佳实践，获取限制对云实例元数据 API 访问的建议和详情。
|
||||
|
||||
要获取更多参考资料，请参阅 MITRE ATT&CK 知识库 - [不安全凭证：云实例元数据 API](https://attack.mitre.org/techniques/T1552/005/)。
|
||||
@@ -0,0 +1,87 @@
|
||||
---
|
||||
title: Rancher 安全指南
|
||||
---
|
||||
|
||||
<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 的集成
|
||||
|
||||
_v2.6.5 中的新功能_
|
||||
|
||||
NeuVector 是一个开源的、以容器为中心的安全应用程序，现已集成到 Rancher 中。NeuVector 提供生产安全、DevOps 漏洞保护和容器防火墙等功能。请参阅 [Rancher 文档](../../integrations-in-rancher/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 2.x 软件栈进行安全审计和渗透测试。被测环境遵循 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)。
|
||||
+50
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: Rancher v2.6 的自我评估和强化指南
|
||||
---
|
||||
|
||||
Rancher 为每个受支持的 Rancher 的 Kubernetes 发行版提供了特定的安全强化指南。
|
||||
|
||||
## Rancher Kubernetes 发行版
|
||||
|
||||
Rancher 使用以下 Kubernetes 发行版：
|
||||
|
||||
- [**RKE**](https://rancher.com/docs/rke/latest/en/), Rancher Kubernetes Engine 是一个经过 CNCF 认证的 Kubernetes 发行版，完全在 Docker 容器中运行。
|
||||
- [**RKE2**](https://docs.rke2.io/) 是一个完全符合的 Kubernetes 发行版，专注于安全性和合规性。
|
||||
- [**K3s**](https://rancher.com/docs/k3s/latest/en/) 是一个完全合规的，轻量级 Kubernetes 发行版。它易于安装，内存需求只有上游 Kubernetes 的一半，所有组件都在一个小于 100 MB 的二进制文件中。
|
||||
|
||||
要加固运行未列出的发行版的 Kubernetes 集群，请参阅 Kubernetes 提供商文档。
|
||||
|
||||
## 强化指南和 Benchmark 版本
|
||||
|
||||
这些指南已经与 Rancher v2.6 版本一起进行了测试。每个自我评估指南都附有强化指南，并在特定的 Kubernetes 版本和 CIS 基准版本上进行了测试。如果 CIS 基准尚未针对你的 Kubernetes 版本进行验证，你可以选择使用现有指南，直到添加更新版本。
|
||||
|
||||
### RKE 指南
|
||||
|
||||
| Kubernetes 版本 | CIS Benchmark 版本 | 自我评估指南 | 强化指南 |
|
||||
| ------------------------- | ------------------ | ------------------------------------------------------------- | ------------------------------------------------------- |
|
||||
| Kubernetes v1.18 至 v1.23 | CIS v1.6 | [链接](rke1-self-assessment-guide-with-cis-v1.6-benchmark.md) | [链接](rke1-hardening-guide-with-cis-v1.6-benchmark.md) |
|
||||
|
||||
:::note
|
||||
|
||||
- Kubernetes v1.19 和 v1.20 的 CIS v1.20 Benchmark 测试版本尚未作为 Rancher 的 CIS Benchmark chart 中的配置文件发布。
|
||||
|
||||
:::
|
||||
|
||||
### RKE2 指南
|
||||
|
||||
| 类型 | Kubernetes 版本 | CIS Benchmark 版本 | 自我评估指南 | 强化指南 |
|
||||
| -------------------------------- | ------------------------- | ------------------ | ------------------------------------------------------------- | ------------------------------------------------------- |
|
||||
| Rancher provisioned RKE2 cluster | Kubernetes v1.21 至 v1.23 | CIS v1.6 | [链接](rke2-self-assessment-guide-with-cis-v1.6-benchmark.md) | [链接](rke2-hardening-guide-with-cis-v1.6-benchmark.md) |
|
||||
| Standalone RKE2 | Kubernetes v1.21 至 v1.23 | CIS v1.6 | [链接](https://docs.rke2.io/security/cis_self_assessment16) | [链接](https://docs.rke2.io/security/hardening_guide) |
|
||||
|
||||
### K3s 指南
|
||||
|
||||
| Kubernetes 版本 | CIS Benchmark 版本 | 自我评估指南 | 强化指南 |
|
||||
| ------------------------- | ------------------ | ------------------------------------------------------------------------ | ------------------------------------------------------------------------ |
|
||||
| Kubernetes v1.21 和 v1.22 | CIS v1.6 | [链接](https://rancher.com/docs/k3s/latest/en/security/self_assessment/) | [链接](https://rancher.com/docs/k3s/latest/en/security/hardening_guide/) |
|
||||
|
||||
## 在 SELinux 上使用 Rancher
|
||||
|
||||
[Security-Enhanced Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) 是对 Linux 的安全性增强。SELinux 在历史上被政府机构使用后，现在是行业标准，并且在 RHEL 和 CentOS 上默认启用。
|
||||
|
||||
要将 Rancher 与 SELinux 结合使用，我们建议按照[此页面](../selinux-rpm/about-rancher-selinux.md#installing-the-rancher-selinux-rpm)上的说明安装 `rancher-selinux`。
|
||||
+646
@@ -0,0 +1,646 @@
|
||||
---
|
||||
title: 使用 CIS 1.6 Benchmark 的 RKE 强化指南
|
||||
---
|
||||
|
||||
<EOLRKE1Warning />
|
||||
|
||||
本文档提供了用于强化 RKE 集群（使用 Rancher 2.6 进行配置）生产安装的说明。此处概述了遵循 CIS 的 Kubernetes Benchmark 管控所需的配置和控制。
|
||||
|
||||
:::note
|
||||
|
||||
本强化指南介绍了如何保护集群中的节点。建议你在安装 Kubernetes 之前参考本指南。
|
||||
|
||||
:::
|
||||
|
||||
本强化指南适用于 RKE 集群，并对应以下 CIS Kubernetes Benchmark、Kubernetes 和 Rancher 版本：
|
||||
|
||||
| Rancher 版本 | CIS Benchmark 版本 | Kubernetes 版本 |
|
||||
| --------------- | --------------------- | ------------------ |
|
||||
| Rancher v2.6 | Benchmark v1.6 | Kubernetes v1.18 到 v1.23 |
|
||||
|
||||
[点击此处下载本文档的 PDF 版本](https://releases.rancher.com/documents/security/2.6/Rancher_v2-6_CIS_v1-6_Hardening_Guide.pdf)。
|
||||
|
||||
|
||||
### 概述
|
||||
|
||||
本文档介绍了强化 RKE 集群的说明，该集群使用 Kubernetes 1.18 至 1.23 版本安装 Rancher 2.6，或在 Rancher 2.6 中配置使用 Kubernetes 1.18 至 1.23 版本的 RKE 集群。此处概述了遵循 CIS 的 Kubernetes Benchmark 管控所需的配置。
|
||||
|
||||
有关根据官方 CIS Benchmark 评估强化集群的更多详细信息，请参阅 [CIS 1.6 Benchmark - 自我评估指南 - Rancher 2.6](./rke1-self-assessment-guide-with-cis-v1.6-benchmark.md)。
|
||||
|
||||
#### 已知问题
|
||||
|
||||
- 如果注册自定义节点时仅提供公共 IP，CIS 1.6 强化设置中用于 Pod 的 Rancher **exec shell** 和 **view logs** 将**不起作用**。此功能要求在注册自定义节点时提供私有 IP。
|
||||
- 如果把 `default_pod_security_policy_template_id:` 设置为 `restricted` 或 `restricted-noroot`，根据 Rancher 提供的 [Pod 安全策略 (PSP)](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md)，Rancher 会在默认 ServiceAccount 上创建 **RoleBindings** 和 **ClusterRoleBindings**。CIS 1.6 检查 5.1.5 时会要求默认 ServiceAccount 除了默认值之外没有绑定到其他角色或集群角色。此外，你还需要配置默认 ServiceAccount，使其不提供 ServiceAccount 令牌并且没有显式分配任何权限。
|
||||
|
||||
### 配置内核运行时参数
|
||||
|
||||
建议为集群中所有类型的节点使用以下 `sysctl` 配置。在 `/etc/sysctl.d/90-kubelet.conf` 中设置如下参数：
|
||||
|
||||
```ini
|
||||
vm.overcommit_memory=1
|
||||
vm.panic_on_oom=0
|
||||
kernel.panic=10
|
||||
kernel.panic_on_oops=1
|
||||
kernel.keys.root_maxbytes=25000000
|
||||
```
|
||||
|
||||
运行 `sysctl -p /etc/sysctl.d/90-kubelet.conf` 以启用设置。
|
||||
|
||||
### 配置 `etcd` 用户和组
|
||||
|
||||
在安装 RKE 之前，你需要设置 **etcd** 服务的用户账号和组。在安装期间，**etcd** 用户的 **uid** 和 **gid** 将用于在 RKE **config.yml** 中设置适当的文件和目录权限。
|
||||
|
||||
#### 创建 `etcd` 用户和组
|
||||
|
||||
要创建 **etcd** 用户和组，请运行以下控制台命令。下面的命令使用 `52034` 作为 **uid** 和 **gid**。该值只是一个示例。你可以使用有效且未被使用的 **uid** 或 **gid** 来代替 `52034`。
|
||||
|
||||
```bash
|
||||
groupadd --gid 52034 etcd
|
||||
useradd --comment "etcd service account" --uid 52034 --gid 52034 etcd --shell /usr/sbin/nologin
|
||||
```
|
||||
|
||||
使用 **etcd** 用户的 **uid** 和 **gid** 来更新 RKE **config.yml**：
|
||||
|
||||
```yaml
|
||||
services:
|
||||
etcd:
|
||||
gid: 52034
|
||||
uid: 52034
|
||||
```
|
||||
|
||||
### 配置 `default` ServiceAccount
|
||||
|
||||
#### 将 `default` ServiceAccount 的 `automountServiceAccountToken` 设置为 `false`
|
||||
|
||||
Kubernetes 为集群工作负载提供了一个 default ServiceAccount，但没有为 pod 分配特定 ServiceAccount。如果需要从 pod 访问 Kubernetes API，则需要为该 pod 创建一个特定的 ServiceAccount 并授予权限。你还需要配置 default ServiceAccount，使其不提供 ServiceAccount 令牌并且没有任何显式的权限分配。
|
||||
|
||||
对于标准 RKE 中的每个命名空间（包括 **default** 和 **kube-system**），**default** ServiceAccount 必须包含以下值：
|
||||
|
||||
```yaml
|
||||
automountServiceAccountToken: false
|
||||
```
|
||||
|
||||
将以下配置保存到名为 `account_update.yaml` 的文件中:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: default
|
||||
automountServiceAccountToken: false
|
||||
```
|
||||
|
||||
创建一个名为 `account_update.sh` 的 bash 脚本文件。确保为脚本设置了 `chmod +x account_update.sh`，使脚本具有执行权限：
|
||||
|
||||
```bash
|
||||
#!/bin/bash -e
|
||||
|
||||
for namespace in $(kubectl get namespaces -A -o=jsonpath="{.items[*]['metadata.name']}"); do
|
||||
kubectl patch serviceaccount default -n ${namespace} -p "$(cat account_update.yaml)"
|
||||
done
|
||||
```
|
||||
|
||||
### 配置网络策略
|
||||
|
||||
#### 确保所有命名空间都定义了网络策略
|
||||
|
||||
如果你在同一个 Kubernetes 集群上运行不同的应用程序，被感染的应用程序可能会攻击相邻的应用程序。要确保容器只进行所需的通信，网络分段非常重要。网络策略指的是如何允许 Pod 与其他 Pod 以及与其他网络端点进行通信。
|
||||
|
||||
网络策略是命名空间范围的。为某个命名空间配置网络策略后，该策略不允许的所有其他流量都会被拒绝。但是，如果命名空间没有配置网络策略，则所有流量都会允许进出该命名空间中的 Pod。要执行网络策略，你必须启用 CNI（容器网络接口）插件。本指南使用 [Canal](https://github.com/projectcalico/canal) 来执行策略。有关 CNI 网络插件的更多信息，请参阅[这里](https://www.suse.com/c/rancher_blog/comparing-kubernetes-cni-providers-flannel-calico-canal-and-weave/)。
|
||||
|
||||
在集群上启用了 CNI 网络插件后，你就可以应用默认网络策略了。以下提供了一个供参考的 **permissive** 示例。如果要允许所有流量发送到命名空间中的所有 pod（即使添加了导致某些 pod 被“隔离”的策略），你可以显式创建一个策略来允许该命名空间中的所有流量。将以下配置保存为 `default-allow-all.yaml`。如需查看网络策略相关的其他[文档](https://kubernetes.io/docs/concepts/services-networking/network-policies/)，请前往 Kubernetes 网站。
|
||||
|
||||
:::note
|
||||
|
||||
此 `NetworkPolicy` 只是一个示例，不建议用于生产环境。
|
||||
|
||||
:::
|
||||
|
||||
```yaml
|
||||
---
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: NetworkPolicy
|
||||
metadata:
|
||||
name: default-allow-all
|
||||
spec:
|
||||
podSelector: {}
|
||||
ingress:
|
||||
- {}
|
||||
egress:
|
||||
- {}
|
||||
policyTypes:
|
||||
- Ingress
|
||||
- Egress
|
||||
```
|
||||
|
||||
创建一个名为 `apply_networkPolicy_to_all_ns.sh` 的 bash 脚本文件。确保为脚本设置了 `chmod +x apply_networkPolicy_to_all_ns.sh`，使脚本具有执行权限：
|
||||
|
||||
```bash
|
||||
#!/bin/bash -e
|
||||
|
||||
for namespace in $(kubectl get namespaces -A -o=jsonpath="{.items[*]['metadata.name']}"); do
|
||||
kubectl apply -f default-allow-all.yaml -n ${namespace}
|
||||
done
|
||||
```
|
||||
|
||||
执行此脚本能将具有 **permissive** `NetworkPolicy` 的 `default-allow-all.yaml` 配置应用于所有命名空间。
|
||||
|
||||
### 强化 RKE `cluster.yml` 配置参考
|
||||
|
||||
RKE CLI 能使用 `cluster.yml` 配置参考，该文件提供了实现 Rancher Kubernetes Engine (RKE) 的强化安装所需的配置。RKE 的[安装文档](https://rancher.com/docs/rke/latest/en/installation/)介绍了有关配置项的其他详细信息。此 `cluster.yml` 参考不包括所需的 **nodes** 参数，该参数会因你的环境而异。如需查看 RKE 中节点配置的文档，请参阅[此处](https://rancher.com/docs/rke/latest/en/config-options/nodes/)。
|
||||
|
||||
:::note 重要提示：
|
||||
|
||||
对于 Kubernetes 1.18 集群，请从 `PodSecurityPolicy` 中删除 `spec.volumes: 'ephemeral'` 配置，因为此 Kubernetes 版本不支持它。
|
||||
|
||||
:::
|
||||
|
||||
```yaml
|
||||
# 如果你打算在离线环境中部署 Kubernetes，
|
||||
# 请查阅配置自定义 RKE 镜像的文档。
|
||||
# https://rancher.com/docs/rke/latest/en/installation/
|
||||
|
||||
# nodes 参数是必需的，并且会根据你的环境而有所不同。
|
||||
# 节点配置的文档可以在这里找到：
|
||||
# https://rancher.com/docs/rke/latest/en/config-options/nodes/
|
||||
nodes: []
|
||||
services:
|
||||
etcd:
|
||||
image: ""
|
||||
extra_args: {}
|
||||
extra_binds: []
|
||||
extra_env: []
|
||||
win_extra_args: {}
|
||||
win_extra_binds: []
|
||||
win_extra_env: []
|
||||
external_urls: []
|
||||
ca_cert: ""
|
||||
cert: ""
|
||||
key: ""
|
||||
path: ""
|
||||
uid: 52034
|
||||
gid: 52034
|
||||
snapshot: false
|
||||
retention: ""
|
||||
creation: ""
|
||||
backup_config: null
|
||||
kube-api:
|
||||
image: ""
|
||||
extra_args: {}
|
||||
extra_binds: []
|
||||
extra_env: []
|
||||
win_extra_args: {}
|
||||
win_extra_binds: []
|
||||
win_extra_env: []
|
||||
service_cluster_ip_range: ""
|
||||
service_node_port_range: ""
|
||||
pod_security_policy: true
|
||||
always_pull_images: false
|
||||
secrets_encryption_config:
|
||||
enabled: true
|
||||
custom_config: null
|
||||
audit_log:
|
||||
enabled: true
|
||||
configuration: null
|
||||
admission_configuration: null
|
||||
event_rate_limit:
|
||||
enabled: true
|
||||
configuration: null
|
||||
kube-controller:
|
||||
image: ""
|
||||
extra_args:
|
||||
feature-gates: RotateKubeletServerCertificate=true
|
||||
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
|
||||
bind-address: 127.0.0.1
|
||||
extra_binds: []
|
||||
extra_env: []
|
||||
win_extra_args: {}
|
||||
win_extra_binds: []
|
||||
win_extra_env: []
|
||||
cluster_cidr: ""
|
||||
service_cluster_ip_range: ""
|
||||
scheduler:
|
||||
image: ""
|
||||
extra_args:
|
||||
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
|
||||
bind-address: 127.0.0.1
|
||||
extra_binds: []
|
||||
extra_env: []
|
||||
win_extra_args: {}
|
||||
win_extra_binds: []
|
||||
win_extra_env: []
|
||||
kubelet:
|
||||
image: ""
|
||||
extra_args:
|
||||
feature-gates: RotateKubeletServerCertificate=true
|
||||
protect-kernel-defaults: true
|
||||
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
|
||||
extra_binds: []
|
||||
extra_env: []
|
||||
win_extra_args: {}
|
||||
win_extra_binds: []
|
||||
win_extra_env: []
|
||||
cluster_domain: cluster.local
|
||||
infra_container_image: ""
|
||||
cluster_dns_server: ""
|
||||
fail_swap_on: false
|
||||
generate_serving_certificate: true
|
||||
kubeproxy:
|
||||
image: ""
|
||||
extra_args: {}
|
||||
extra_binds: []
|
||||
extra_env: []
|
||||
win_extra_args: {}
|
||||
win_extra_binds: []
|
||||
win_extra_env: []
|
||||
network:
|
||||
plugin: ""
|
||||
options: {}
|
||||
mtu: 0
|
||||
node_selector: {}
|
||||
update_strategy: null
|
||||
authentication:
|
||||
strategy: ""
|
||||
sans: []
|
||||
webhook: null
|
||||
addons: |
|
||||
# Upstream Kubernetes restricted PSP policy
|
||||
# https://github.com/kubernetes/website/blob/564baf15c102412522e9c8fc6ef2b5ff5b6e766c/content/en/examples/policy/restricted-psp.yaml
|
||||
apiVersion: policy/v1beta1
|
||||
kind: PodSecurityPolicy
|
||||
metadata:
|
||||
name: restricted-noroot
|
||||
spec:
|
||||
privileged: false
|
||||
# Required to prevent escalations to root.
|
||||
allowPrivilegeEscalation: false
|
||||
requiredDropCapabilities:
|
||||
- ALL
|
||||
# Allow core volume types.
|
||||
volumes:
|
||||
- 'configMap'
|
||||
- 'emptyDir'
|
||||
- 'projected'
|
||||
- 'secret'
|
||||
- 'downwardAPI'
|
||||
# Assume that ephemeral CSI drivers & persistentVolumes set up by the cluster admin are safe to use.
|
||||
- 'csi'
|
||||
- 'persistentVolumeClaim'
|
||||
- 'ephemeral'
|
||||
hostNetwork: false
|
||||
hostIPC: false
|
||||
hostPID: false
|
||||
runAsUser:
|
||||
# Require the container to run without root privileges.
|
||||
rule: 'MustRunAsNonRoot'
|
||||
seLinux:
|
||||
# This policy assumes the nodes are using AppArmor rather than SELinux.
|
||||
rule: 'RunAsAny'
|
||||
supplementalGroups:
|
||||
rule: 'MustRunAs'
|
||||
ranges:
|
||||
# Forbid adding the root group.
|
||||
- min: 1
|
||||
max: 65535
|
||||
fsGroup:
|
||||
rule: 'MustRunAs'
|
||||
ranges:
|
||||
# Forbid adding the root group.
|
||||
- min: 1
|
||||
max: 65535
|
||||
readOnlyRootFilesystem: false
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: psp:restricted-noroot
|
||||
rules:
|
||||
- apiGroups:
|
||||
- extensions
|
||||
resourceNames:
|
||||
- restricted-noroot
|
||||
resources:
|
||||
- podsecuritypolicies
|
||||
verbs:
|
||||
- use
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRoleBinding
|
||||
metadata:
|
||||
name: psp:restricted-noroot
|
||||
roleRef:
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
kind: ClusterRole
|
||||
name: psp:restricted-noroot
|
||||
subjects:
|
||||
- apiGroup: rbac.authorization.k8s.io
|
||||
kind: Group
|
||||
name: system:serviceaccounts
|
||||
- apiGroup: rbac.authorization.k8s.io
|
||||
kind: Group
|
||||
name: system:authenticated
|
||||
---
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: NetworkPolicy
|
||||
metadata:
|
||||
name: default-allow-all
|
||||
spec:
|
||||
podSelector: {}
|
||||
ingress:
|
||||
- {}
|
||||
egress:
|
||||
- {}
|
||||
policyTypes:
|
||||
- Ingress
|
||||
- Egress
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: default
|
||||
automountServiceAccountToken: false
|
||||
addons_include: []
|
||||
system_images:
|
||||
etcd: ""
|
||||
alpine: ""
|
||||
nginx_proxy: ""
|
||||
cert_downloader: ""
|
||||
kubernetes_services_sidecar: ""
|
||||
kubedns: ""
|
||||
dnsmasq: ""
|
||||
kubedns_sidecar: ""
|
||||
kubedns_autoscaler: ""
|
||||
coredns: ""
|
||||
coredns_autoscaler: ""
|
||||
nodelocal: ""
|
||||
kubernetes: ""
|
||||
flannel: ""
|
||||
flannel_cni: ""
|
||||
calico_node: ""
|
||||
calico_cni: ""
|
||||
calico_controllers: ""
|
||||
calico_ctl: ""
|
||||
calico_flexvol: ""
|
||||
canal_node: ""
|
||||
canal_cni: ""
|
||||
canal_controllers: ""
|
||||
canal_flannel: ""
|
||||
canal_flexvol: ""
|
||||
weave_node: ""
|
||||
weave_cni: ""
|
||||
pod_infra_container: ""
|
||||
ingress: ""
|
||||
ingress_backend: ""
|
||||
metrics_server: ""
|
||||
windows_pod_infra_container: ""
|
||||
ssh_key_path: ""
|
||||
ssh_cert_path: ""
|
||||
ssh_agent_auth: false
|
||||
authorization:
|
||||
mode: ""
|
||||
options: {}
|
||||
ignore_docker_version: false
|
||||
kubernetes_version: ""
|
||||
private_registries: []
|
||||
ingress:
|
||||
provider: ""
|
||||
options: {}
|
||||
node_selector: {}
|
||||
extra_args: {}
|
||||
dns_policy: ""
|
||||
extra_envs: []
|
||||
extra_volumes: []
|
||||
extra_volume_mounts: []
|
||||
update_strategy: null
|
||||
http_port: 0
|
||||
https_port: 0
|
||||
network_mode: ""
|
||||
cluster_name:
|
||||
cloud_provider:
|
||||
name: ""
|
||||
prefix_path: ""
|
||||
win_prefix_path: ""
|
||||
addon_job_timeout: 0
|
||||
bastion_host:
|
||||
address: ""
|
||||
port: ""
|
||||
user: ""
|
||||
ssh_key: ""
|
||||
ssh_key_path: ""
|
||||
ssh_cert: ""
|
||||
ssh_cert_path: ""
|
||||
monitoring:
|
||||
provider: ""
|
||||
options: {}
|
||||
node_selector: {}
|
||||
update_strategy: null
|
||||
replicas: null
|
||||
restore:
|
||||
restore: false
|
||||
snapshot_name: ""
|
||||
dns: null
|
||||
upgrade_strategy:
|
||||
max_unavailable_worker: ""
|
||||
max_unavailable_controlplane: ""
|
||||
drain: null
|
||||
node_drain_input: null
|
||||
```
|
||||
|
||||
### 强化 RKE 模板配置参考
|
||||
|
||||
RKE 模板参考提供了实现 Kubernetes 强化安装所需的配置。RKE 模板用于配置 Kubernetes 和定义 Rancher 设置。如需了解安装以及 RKE 模板的详细信息，请参阅 Rancher [文档](../../../pages-for-subheaders/installation-and-upgrade.md)。
|
||||
|
||||
```yaml
|
||||
#
|
||||
# Cluster Config
|
||||
#
|
||||
default_pod_security_policy_template_id: restricted-noroot
|
||||
docker_root_dir: /var/lib/docker
|
||||
enable_cluster_alerting: false
|
||||
enable_cluster_monitoring: false
|
||||
enable_network_policy: true
|
||||
local_cluster_auth_endpoint:
|
||||
enabled: true
|
||||
name: ''
|
||||
#
|
||||
# Rancher Config
|
||||
#
|
||||
rancher_kubernetes_engine_config:
|
||||
addon_job_timeout: 45
|
||||
authentication:
|
||||
strategy: x509
|
||||
dns:
|
||||
nodelocal:
|
||||
ip_address: ''
|
||||
node_selector: null
|
||||
update_strategy: {}
|
||||
enable_cri_dockerd: false
|
||||
ignore_docker_version: true
|
||||
#
|
||||
# # 目前仅支持 Nginx ingress provider
|
||||
# # 要禁用 Ingress controller，设置 `provider: none`
|
||||
# # 要在指定节点上禁用 Ingress，使用 node_selector，例如：
|
||||
# provider: nginx
|
||||
# node_selector:
|
||||
# app: ingress
|
||||
#
|
||||
ingress:
|
||||
default_backend: false
|
||||
default_ingress_class: true
|
||||
http_port: 0
|
||||
https_port: 0
|
||||
provider: nginx
|
||||
kubernetes_version: v1.21.8-rancher1-1
|
||||
monitoring:
|
||||
provider: metrics-server
|
||||
replicas: 1
|
||||
#
|
||||
# 如果你在 AWS 使用 Calico
|
||||
#
|
||||
# network:
|
||||
# plugin: calico
|
||||
# calico_network_provider:
|
||||
# cloud_provider: aws
|
||||
#
|
||||
# # 要指定 Flannel 接口
|
||||
#
|
||||
# network:
|
||||
# plugin: flannel
|
||||
# flannel_network_provider:
|
||||
# iface: eth1
|
||||
#
|
||||
# # 要为 Canal 插件指定 Flannel 接口
|
||||
#
|
||||
# network:
|
||||
# plugin: canal
|
||||
# canal_network_provider:
|
||||
# iface: eth1
|
||||
#
|
||||
network:
|
||||
mtu: 0
|
||||
options:
|
||||
flannel_backend_type: vxlan
|
||||
plugin: canal
|
||||
rotate_encryption_key: false
|
||||
#
|
||||
# services:
|
||||
# kube-api:
|
||||
# service_cluster_ip_range: 10.43.0.0/16
|
||||
# kube-controller:
|
||||
# cluster_cidr: 10.42.0.0/16
|
||||
# service_cluster_ip_range: 10.43.0.0/16
|
||||
# kubelet:
|
||||
# cluster_domain: cluster.local
|
||||
# cluster_dns_server: 10.43.0.10
|
||||
#
|
||||
services:
|
||||
scheduler:
|
||||
extra_args:
|
||||
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
|
||||
bind-address: 127.0.0.1
|
||||
etcd:
|
||||
backup_config:
|
||||
enabled: true
|
||||
interval_hours: 12
|
||||
retention: 6
|
||||
safe_timestamp: false
|
||||
timeout: 300
|
||||
creation: 12h
|
||||
extra_args:
|
||||
election-timeout: 5000
|
||||
heartbeat-interval: 500
|
||||
retention: 72h
|
||||
snapshot: false
|
||||
uid: 52034
|
||||
gid: 52034
|
||||
kube_api:
|
||||
always_pull_images: false
|
||||
audit_log:
|
||||
enabled: true
|
||||
event_rate_limit:
|
||||
enabled: true
|
||||
pod_security_policy: true
|
||||
secrets_encryption_config:
|
||||
enabled: true
|
||||
service_node_port_range: 30000-32767
|
||||
kube-controller:
|
||||
extra_args:
|
||||
feature-gates: RotateKubeletServerCertificate=true
|
||||
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
|
||||
bind-address: 127.0.0.1
|
||||
kubelet:
|
||||
extra_args:
|
||||
feature-gates: RotateKubeletServerCertificate=true
|
||||
protect-kernel-defaults: true
|
||||
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
|
||||
fail_swap_on: false
|
||||
generate_serving_certificate: true
|
||||
ssh_agent_auth: false
|
||||
upgrade_strategy:
|
||||
max_unavailable_controlplane: '1'
|
||||
max_unavailable_worker: 10%
|
||||
windows_prefered_cluster: false
|
||||
```
|
||||
|
||||
### 强化 `cloud-config` 配置参考
|
||||
|
||||
**cloud-config** 配置文件通常用于云基础设施环境中，能让你管理计算实例的配置。此参考 config 配置了安装 Kubernetes 之前所需的 SUSE Linux Enterprise Server (SLES)、openSUSE Leap、Red Hat Enterprise Linux (RHEL) 和 Ubuntu 操作系统级别的设置。
|
||||
|
||||
#### 针对 SUSE Linux Enterprise Server 15 (SLES 15) 和 openSUSE Leap 15 的强化 **cloud-config** 参考
|
||||
|
||||
```yaml
|
||||
#cloud-config
|
||||
system_info:
|
||||
default_user:
|
||||
groups:
|
||||
- docker
|
||||
write_files:
|
||||
- path: "/etc/sysctl.d/90-kubelet.conf"
|
||||
owner: root:root
|
||||
permissions: '0644'
|
||||
content: |
|
||||
vm.overcommit_memory=1
|
||||
vm.panic_on_oom=0
|
||||
kernel.panic=10
|
||||
kernel.panic_on_oops=1
|
||||
kernel.keys.root_maxbytes=25000000
|
||||
package_update: true
|
||||
ssh_pwauth: false
|
||||
runcmd:
|
||||
# Docker 应该已在 SLES 15 SP3 中安装
|
||||
- zypper install docker containerd
|
||||
- systemctl daemon-reload
|
||||
- systemctl enable docker.service
|
||||
- systemctl start --no-block docker.service
|
||||
- sysctl -p /etc/sysctl.d/90-kubelet.conf
|
||||
- groupadd --gid 52034 etcd
|
||||
- useradd --comment "etcd service account" --uid 52034 --gid 52034 etcd --shell /usr/sbin/nologin
|
||||
```
|
||||
|
||||
#### 针对 Red Hat Enterprise Linux 8 (RHEL 8) 和 Ubuntu 20.04 LTS 的强化 **cloud-config** 参考
|
||||
|
||||
```yaml
|
||||
#cloud-config
|
||||
system_info:
|
||||
default_user:
|
||||
groups:
|
||||
- docker
|
||||
write_files:
|
||||
- path: "/etc/sysctl.d/90-kubelet.conf"
|
||||
owner: root:root
|
||||
permissions: '0644'
|
||||
content: |
|
||||
vm.overcommit_memory=1
|
||||
vm.panic_on_oom=0
|
||||
kernel.panic=10
|
||||
kernel.panic_on_oops=1
|
||||
kernel.keys.root_maxbytes=25000000
|
||||
package_update: true
|
||||
ssh_pwauth: false
|
||||
runcmd:
|
||||
# 使用 Rancher 的 Docker 安装脚本来安装 Docker - github.com/rancher/install-docker
|
||||
- curl https://releases.rancher.com/install-docker/20.10.sh | sh
|
||||
- sysctl -p /etc/sysctl.d/90-kubelet.conf
|
||||
- groupadd --gid 52034 etcd
|
||||
- useradd --comment "etcd service account" --uid 52034 --gid 52034 etcd --shell /usr/sbin/nologin
|
||||
```
|
||||
+2955
File diff suppressed because it is too large
Load Diff
+409
@@ -0,0 +1,409 @@
|
||||
---
|
||||
title: 使用 CIS 1.6 Benchmark 的 RKE2 强化指南
|
||||
---
|
||||
|
||||
本文档提供了用于强化 RKE2 集群（使用 Rancher 2.6.5 进行配置）生产安装的说明。此处概述了遵循 CIS 的 Kubernetes Benchmark 管控所需的配置和控制。
|
||||
|
||||
:::note
|
||||
|
||||
本强化指南介绍了如何保护集群中的节点。建议你在安装 Kubernetes 之前参考本指南。
|
||||
|
||||
:::
|
||||
|
||||
本强化指南适用于 RKE2 集群，并对应以下 CIS Kubernetes Benchmark、Kubernetes 和 Rancher 版本：
|
||||
|
||||
| Rancher 版本 | CIS Benchmark 版本 | Kubernetes 版本 |
|
||||
| --------------- | --------------------- | ------------------ |
|
||||
| Rancher v2.6.5+ | Benchmark v1.6 | Kubernetes v1.21 到 v1.23 |
|
||||
|
||||
[点击此处下载本文档的 PDF 版本](https://releases.rancher.com/documents/security/2.6/Rancher_RKE2_v2-6_CIS_v1-6_Hardening_Guide.pdf)。
|
||||
|
||||
|
||||
### 概述
|
||||
|
||||
本文档提供了强化使用了 Rancher 2.6.5+ 和 Kubernetes 1.21 到 1.23 版本的 RKE2 集群的说明。此处概述了遵循 CIS 的 Kubernetes Benchmark 管控所需的配置。
|
||||
|
||||
有关根据官方 CIS Benchmark 评估强化 RKE2 集群的更多详细信息，请参阅 [RKE2 - CIS 1.6 Benchmark - 自我评估指南 - Rancher 2.6](rke2-self-assessment-guide-with-cis-v1.6-benchmark.md)。
|
||||
|
||||
RKE2 是“默认强化”的，因此无需进行修改即可通过大部分 Kubernetes CIS 管控。但是也有一些例外情况是需要人工干预才能完全通过 CIS Benchmark：
|
||||
|
||||
1. RKE2 不会修改主机操作系统。因此，操作人员必须进行一些主机级别的修改。
|
||||
2. `PodSecurityPolicies` 和 `NetworkPolicies` 的某些 CIS 策略会限制集群功能。你必须让 RKE2 开箱即用地配置它们。
|
||||
|
||||
要满足上述要求，你可以在 `profile` 标志设置为 `cis-1.6` 的情况下启动 RKE2。该标志通常执行以下两个操作：
|
||||
|
||||
1. 检查是否满足主机级别的要求。如果没有，RKE2 将退出并显示未满足要求的致命错误描述。
|
||||
2. 配置能让集群通过相关管控的运行时 pod 安全策略和网络策略。
|
||||
|
||||
:::note
|
||||
|
||||
配置文件标志的有效值是 `cis-1.5` 或 `cis-1.6`。它接受一个字符串值以允许以后使用其他配置文件。
|
||||
|
||||
:::
|
||||
|
||||
以下概述了当 `profile` 标志设置为 `cis-1.6` 时采取的具体操作。
|
||||
|
||||
### 主机级别要求
|
||||
|
||||
主机级别的要求有两个方面，分别是内核参数和 etcd 进程/目录配置。本节会概述这些内容。
|
||||
|
||||
#### 确保设置了 `protect-kernel-defaults`
|
||||
|
||||
这是一个 kubelet 标志，如果所需的内核参数未设置或设置为与 kubelet 默认值不同的值，它会导致 kubelet 退出。
|
||||
|
||||
如果设置了 `profile` 标志，RKE2 会将标志设置为 `true`。
|
||||
|
||||
:::caution
|
||||
|
||||
`protect-kernel-defaults` 作为 RKE2 的配置标志公开。如果你已将 `profile` 设置为 `cis-1.x` 并将 `protect-kernel-defaults` 设置为 `false`，则 RKE2 将退出并提示错误。
|
||||
|
||||
:::
|
||||
|
||||
RKE2 还将检查与 kubelet 相同的内核参数，并按照 kubelet 相同的规则退出并提示错误。这样，操作人员可以更快、更轻松地识别出与 kubelet 默认值不一致的内核参数。
|
||||
|
||||
`protect-kernel-defaults` 和 `profile` 标志都可以在 RKE2 模板配置文件中设置。
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
rkeConfig:
|
||||
machineSelectorConfig:
|
||||
- config:
|
||||
profile: cis-1.6
|
||||
protect-kernel-defaults: true
|
||||
```
|
||||
|
||||
#### 确保 etcd 配置正确
|
||||
|
||||
CIS Benchmark 要求 etcd 数据目录由 `etcd` 用户和组拥有。换言之，它要求 etcd 进程由主机级别的 `etcd` 用户运行。为了实现这一点，RKE2 在使用有效的 `cis-1.x` 配置文件启动时采取了几个步骤：
|
||||
|
||||
1. 检查主机上是否存在 `etcd` 用户和组。如果没有，则退出并提示错误。
|
||||
2. 以 `etcd` 作为用户和组所有者来创建 etcd 的数据目录。
|
||||
3. 正确设置 etcd 静态 pod 的 `SecurityContext`，从而确保 etcd 进程以 `etcd` 用户和组的身份运行。
|
||||
|
||||
### 设置主机
|
||||
|
||||
本节提供了满足上述要求所需的主机配置命令。
|
||||
|
||||
#### 设置内核参数
|
||||
|
||||
建议为集群中所有类型的节点使用以下 `sysctl` 配置。在 `/etc/sysctl.d/90-kubelet.conf` 中设置如下参数：
|
||||
|
||||
```ini
|
||||
vm.panic_on_oom=0
|
||||
vm.overcommit_memory=1
|
||||
kernel.panic=10
|
||||
kernel.panic_on_oops=1
|
||||
```
|
||||
|
||||
运行 `sudo sysctl -p /etc/sysctl.d/90-kubelet.conf` 以启用设置。
|
||||
|
||||
在通过 Rancher 实际部署 RKE2 之前，请仅在全新安装上执行此步骤。
|
||||
|
||||
#### 创建 etcd 用户
|
||||
|
||||
在某些 Linux 发行版上，`useradd` 命令不会创建组。以下命令使用了 `-U` 标志来解决这一问题。这个标志能让 `useradd` 创建一个与用户同名的组。
|
||||
|
||||
```bash
|
||||
sudo useradd -r -c "etcd user" -s /sbin/nologin -M etcd -U
|
||||
```
|
||||
|
||||
### Kubernetes 运行时要求
|
||||
|
||||
如果运行时要通过 CIS Benchmark，则需要重视 pod 安全和网络策略。本节会概述这些内容。
|
||||
|
||||
#### `PodSecurityPolicies`
|
||||
|
||||
RKE2 总是在 `PodSecurityPolicy` 准入控制器打开的情况下运行。但是，当它**不是**使用有效的 `cis-1.x` 配置文件启动时，RKE2 将设置一个不受限制的策略，该策略允许 Kubernetes 像 `PodSecurityPolicy` 准入控制器未启用一样运行。
|
||||
|
||||
使用有效的 `cis-1.x` 配置文件运行时，RKE2 将设置一组更具限制性的策略。这些策略符合 CIS Benchmark 5.2 节中的要求。
|
||||
|
||||
> Kubernetes controlplane 组件和关键附加组件（例如 CNI、DNS 和 Ingress）在 `kube-system` 命名空间中作为 pod 运行。因此，此命名空间的策略限制会更低，以便这些组件可以正常运行。
|
||||
|
||||
#### `NetworkPolicies`
|
||||
|
||||
使用有效的 `cis-1.x` 配置文件运行时，RKE2 将设置 `NetworkPolicies` 以通过 Kubernetes 内置命名空间的 CIS Benchmark。这些命名空间是分别是 `kube-system`、`kube-public`、`kube-node-lease` 和 `default`。
|
||||
|
||||
使用的 `NetworkPolicy` 只允许同一命名空间内的 Pod 相互通信。一个例外情况是它允许解析 DNS 请求。
|
||||
|
||||
:::note
|
||||
|
||||
操作人员需要照常管理其他命名空间的网络策略。
|
||||
|
||||
:::
|
||||
#### 配置 `default` ServiceAccount
|
||||
|
||||
**将 `default` ServiceAccount 的 `automountServiceAccountToken` 设置为 `false`**
|
||||
|
||||
Kubernetes 为集群工作负载提供了一个 `default` ServiceAccount，但没有为 pod 分配特定 ServiceAccount 。如果需要从 pod 访问 Kubernetes API，则需要为该 pod 创建一个特定的 ServiceAccount 并授予权限。你还需要配置 `default` ServiceAccount，使其不提供 ServiceAccount 令牌并且没有任何显式的权限分配。
|
||||
|
||||
对于标准 RKE2 中的每个命名空间（包括 `default` 和 `kube-system`），`default` ServiceAccount 必须包含以下值：
|
||||
|
||||
```yaml
|
||||
automountServiceAccountToken: false
|
||||
```
|
||||
|
||||
对于集群操作人员创建的命名空间，你可以使用以下脚本和配置文件来配置 `default` ServiceAccount。
|
||||
|
||||
请将下面的配置保存到名为 `account_update.yaml` 的文件中：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: default
|
||||
automountServiceAccountToken: false
|
||||
```
|
||||
|
||||
创建一个名为 `account_update.sh` 的 bash 脚本文件。确保为脚本设置了 `sudo chmod +x account_update.sh`，使脚本具有执行权限：
|
||||
|
||||
```bash
|
||||
#!/bin/bash -e
|
||||
|
||||
for namespace in $(kubectl get namespaces -A -o=jsonpath="{.items[*]['metadata.name']}"); do
|
||||
echo -n "Patching namespace $namespace - "
|
||||
kubectl patch serviceaccount default -n ${namespace} -p "$(cat account_update.yaml)"
|
||||
done
|
||||
```
|
||||
|
||||
执行此脚本，将 `account_update.yaml` 配置应用到所有命名空间中的 `default` ServiceAccount。
|
||||
|
||||
### API Server 审计配置
|
||||
|
||||
CIS 1.2.22 到 1.2.25 要求为 API Server 配置审计日志。如果 RKE2 在 `profile` 标志设置为 `cis-1.6` 的情况下启动，它会自动在 API Server 中配置强化的 `--audit-log-` 参数来通过这些 CIS 检查。
|
||||
|
||||
RKE2 的默认审计策略不会在 API Server 中记录请求。这样，集群操作人员就能灵活地定制符合其审计要求和需求的审计策略，从而满足不同用户的不同环境和策略需求。
|
||||
|
||||
如果启动时 `profile` 标志设置为 `cis-1.6`，RKE2 会创建默认审计策略。该策略在 `/etc/rancher/rke2/audit-policy.yaml` 中定义。
|
||||
|
||||
```yaml
|
||||
apiVersion: audit.k8s.io/v1
|
||||
kind: Policy
|
||||
metadata:
|
||||
creationTimestamp: null
|
||||
rules:
|
||||
- level: None
|
||||
```
|
||||
|
||||
要开始记录对 API Server 的请求，你至少必须修改 `level` 参数，例如将其修改为 `Metadata`。有关 API Server 策略配置的详细信息，请参阅 [Kubernetes 文档](https://kubernetes.io/docs/tasks/debug-application-cluster/audit/)。
|
||||
|
||||
调整审计策略后，RKE2 必须重新启动才能加载新配置。
|
||||
|
||||
```shell
|
||||
sudo systemctl restart rke2-server.service
|
||||
```
|
||||
|
||||
API Server 审计日志将写入 `/var/lib/rancher/rke2/server/logs/audit.log`。
|
||||
|
||||
### 已知问题
|
||||
|
||||
以下是 RKE2 目前没有通过的管控。此处将解释各个差距，以及这些差距是否可以通过手动干预或在未来的版本中解决。
|
||||
|
||||
#### 管控 1.1.12
|
||||
确保 etcd 数据目录所有权设置为 `etcd:etcd`
|
||||
|
||||
**原因**
|
||||
etcd 是 Kubernetes deployment 使用的高可用键值存储，用于持久存储其所有 REST API 对象。你需要保护此数据目录，避免任何未经授权的读取或写入。它的所有者应该是 `etcd:etcd`。
|
||||
|
||||
**修正措施**
|
||||
创建如上所述的 `etcd` 用户和组。
|
||||
|
||||
#### 管控 5.1.5
|
||||
确保未主动使用默认 ServiceAccount
|
||||
|
||||
**原因**：Kubernetes 为集群工作负载提供了一个 `default` ServiceAccount，但没有为 pod 分配特定 ServiceAccount 。
|
||||
|
||||
如果需要从 pod 访问 Kubernetes API，则需要为该 pod 创建一个特定的 ServiceAccount 并授予权限。
|
||||
|
||||
你还需要配置 `default` ServiceAccount，使其不提供 ServiceAccount 令牌并且没有任何显式的权限分配。
|
||||
|
||||
可以通过将每个命名空间中 `default` ServiceAccount 的 `automountServiceAccountToken` 字段更新为 `false` 来解决此问题。
|
||||
|
||||
**修正措施**
|
||||
手动更新集群中服务账户上的此字段。
|
||||
|
||||
#### 管控 5.3.2
|
||||
确保所有命名空间都定义了网络策略
|
||||
|
||||
**原因**
|
||||
如果你在同一个 Kubernetes 集群上运行不同的应用程序，被感染的应用程序可能会攻击相邻的应用程序。要确保容器只进行所需的通信，网络分段非常重要。网络策略指的是如何允许 Pod 与其他 Pod 以及与其他网络端点进行通信。
|
||||
|
||||
网络策略是命名空间范围的。为某个命名空间配置网络策略后，该策略不允许的所有其他流量都会被拒绝。但是，如果命名空间没有配置网络策略，则所有流量都会允许进出该命名空间中的 Pod。
|
||||
|
||||
**修正措施**
|
||||
在 RKE2 模板配置文件中设置 `profile: "cis-1.6"`。你可以在下方找到示例。
|
||||
|
||||
### 强化 RKE2 模板配置参考
|
||||
|
||||
模板配置参考可用于在 Rancher 中创建强化的 RKE2 自定义集群。此参考不包括其他必需的**集群配置**参数，该参数会因你的环境而异。
|
||||
|
||||
```yaml
|
||||
apiVersion: provisioning.cattle.io/v1
|
||||
kind: Cluster
|
||||
metadata:
|
||||
name: <replace_with_cluster_name>
|
||||
annotations:
|
||||
{}
|
||||
# key: string
|
||||
labels:
|
||||
{}
|
||||
# key: string
|
||||
namespace: fleet-default
|
||||
spec:
|
||||
defaultPodSecurityPolicyTemplateName: ''
|
||||
kubernetesVersion: <replace_with_kubernetes_version>
|
||||
localClusterAuthEndpoint:
|
||||
caCerts: ''
|
||||
enabled: false
|
||||
fqdn: ''
|
||||
rkeConfig:
|
||||
chartValues:
|
||||
rke2-canal:
|
||||
{}
|
||||
etcd:
|
||||
disableSnapshots: false
|
||||
s3:
|
||||
# bucket: string
|
||||
# cloudCredentialName: string
|
||||
# endpoint: string
|
||||
# endpointCA: string
|
||||
# folder: string
|
||||
# region: string
|
||||
# skipSSLVerify: boolean
|
||||
snapshotRetention: 5
|
||||
snapshotScheduleCron: 0 */5 * * *
|
||||
machineGlobalConfig:
|
||||
cni: canal
|
||||
machinePools:
|
||||
# - cloudCredentialSecretName: string
|
||||
# controlPlaneRole: boolean
|
||||
# displayName: string
|
||||
# drainBeforeDelete: boolean
|
||||
# etcdRole: boolean
|
||||
# labels:
|
||||
# key: string
|
||||
# machineConfigRef:
|
||||
# apiVersion: string
|
||||
# fieldPath: string
|
||||
# kind: string
|
||||
# name: string
|
||||
# namespace: string
|
||||
# resourceVersion: string
|
||||
# uid: string
|
||||
# machineDeploymentAnnotations:
|
||||
# key: string
|
||||
# machineDeploymentLabels:
|
||||
# key: string
|
||||
# machineOS: string
|
||||
# maxUnhealthy: string
|
||||
# name: string
|
||||
# nodeStartupTimeout: string
|
||||
# paused: boolean
|
||||
# quantity: int
|
||||
# rollingUpdate:
|
||||
# maxSurge: string
|
||||
# maxUnavailable: string
|
||||
# taints:
|
||||
# - effect: string
|
||||
# key: string
|
||||
# timeAdded: string
|
||||
# value: string
|
||||
# unhealthyNodeTimeout: string
|
||||
# unhealthyRange: string
|
||||
# workerRole: boolean
|
||||
machineSelectorConfig:
|
||||
- config:
|
||||
profile: cis-1.6
|
||||
protect-kernel-defaults: true
|
||||
# - config:
|
||||
#
|
||||
# machineLabelSelector:
|
||||
# matchExpressions:
|
||||
# - key: string
|
||||
# operator: string
|
||||
# values:
|
||||
# - string
|
||||
# matchLabels:
|
||||
# key: string
|
||||
registries:
|
||||
configs:
|
||||
{}
|
||||
#authConfigSecretName: string
|
||||
# caBundle: string
|
||||
# insecureSkipVerify: boolean
|
||||
# tlsSecretName: string
|
||||
mirrors:
|
||||
{}
|
||||
#endpoint:
|
||||
# - string
|
||||
# rewrite:
|
||||
# key: string
|
||||
upgradeStrategy:
|
||||
controlPlaneConcurrency: 10%
|
||||
controlPlaneDrainOptions:
|
||||
# deleteEmptyDirData: boolean
|
||||
# disableEviction: boolean
|
||||
# enabled: boolean
|
||||
# force: boolean
|
||||
# gracePeriod: int
|
||||
# ignoreDaemonSets: boolean
|
||||
# ignoreErrors: boolean
|
||||
# postDrainHooks:
|
||||
# - annotation: string
|
||||
# preDrainHooks:
|
||||
# - annotation: string
|
||||
# skipWaitForDeleteTimeoutSeconds: int
|
||||
# timeout: int
|
||||
workerConcurrency: 10%
|
||||
workerDrainOptions:
|
||||
# deleteEmptyDirData: boolean
|
||||
# disableEviction: boolean
|
||||
# enabled: boolean
|
||||
# force: boolean
|
||||
# gracePeriod: int
|
||||
# ignoreDaemonSets: boolean
|
||||
# ignoreErrors: boolean
|
||||
# postDrainHooks:
|
||||
# - annotation: string
|
||||
# preDrainHooks:
|
||||
# - annotation: string
|
||||
# skipWaitForDeleteTimeoutSeconds: int
|
||||
# timeout: int
|
||||
# additionalManifest: string
|
||||
# etcdSnapshotCreate:
|
||||
# generation: int
|
||||
# etcdSnapshotRestore:
|
||||
# generation: int
|
||||
# name: string
|
||||
# restoreRKEConfig: string
|
||||
# infrastructureRef:
|
||||
# apiVersion: string
|
||||
# fieldPath: string
|
||||
# kind: string
|
||||
# name: string
|
||||
# namespace: string
|
||||
# resourceVersion: string
|
||||
# uid: string
|
||||
# provisionGeneration: int
|
||||
# rotateCertificates:
|
||||
# generation: int
|
||||
# services:
|
||||
# - string
|
||||
# rotateEncryptionKeys:
|
||||
# generation: int
|
||||
machineSelectorConfig:
|
||||
- config: {}
|
||||
# agentEnvVars:
|
||||
# - name: string
|
||||
# value: string
|
||||
# cloudCredentialSecretName: string
|
||||
# clusterAPIConfig:
|
||||
# clusterName: string
|
||||
# defaultClusterRoleForProjectMembers: string
|
||||
# enableNetworkPolicy: boolean
|
||||
# redeploySystemAgentGeneration: int
|
||||
__clone: true
|
||||
```
|
||||
|
||||
### 结论
|
||||
|
||||
如果你遵循本指南，Rancher 配置的 RKE2 自定义集群将能通过 CIS Kubernetes Benchmark。如需了解我们验证 Benchmark 的方式，以及你如何在集群上执行相同的操作，请参阅 Rancher 的 [RKE2 CIS Benchmark 自我评估指南 1.6](rke2-self-assessment-guide-with-cis-v1.6-benchmark.md)。
|
||||
+3164
File diff suppressed because it is too large
Load Diff
+49
@@ -0,0 +1,49 @@
|
||||
---
|
||||
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.6.13](https://github.com/rancher/rancher/releases/tag/v2.6.13) |
|
||||
| [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.6.13](https://github.com/rancher/rancher/releases/tag/v2.6.13) |
|
||||
| [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.6.13](https://github.com/rancher/rancher/releases/tag/v2.6.13) |
|
||||
| [CVE-2023-22647](https://github.com/rancher/rancher/security/advisories/GHSA-p976-h52c-26p6) | 在 Rancher 2.6.12 和 2.7.3 及之前的版本中发现了一个问题。Standard 及以上用户能够将他们的权限提升为 local 集群中的管理员。 | 2023 年 5 月 31 日 | Rancher [v2.6.13](https://github.com/rancher/rancher/releases/tag/v2.6.13) |
|
||||
| [CVE-2022-43759](https://github.com/rancher/rancher/security/advisories/GHSA-7m72-mh5r-6j3r) | 在 Rancher 2.5.0 至 2.5.16 和 2.6.0 至 2.6.9 中发现了一个问题，授权逻辑缺陷导致允许通过项目角色模板绑定 (PRTB) 和 `-promoted` 角色进行权限升级。 | 2023 年 1 月 24 日 | Rancher [v2.6.10](https://github.com/rancher/rancher/releases/tag/v2.6.10) 和 [v2.5.17](https://github.com/rancher/rancher/releases/tag/v2.5.17) |
|
||||
| [CVE-2022-43758](https://github.com/rancher/rancher/security/advisories/GHSA-34p5-jp77-fcrc) | 在 Rancher 2.5.0 至 2.5.16、2.6.0 至 2.6.9 和 2.7.0 版本中发现了一个问题，Rancher Git 包中存在命令注入漏洞。这个包使用 Rancher 容器镜像中可用的底层 Git 二进制文件来执行 Git 操作。特制的命令如果没有消除歧义，可能会在通过 Git 执行时造成混淆，导致在底层 Rancher 主机中进行命令注入。 | 2023 年 1 月 24 日 | Rancher [v2.7.1](https://github.com/rancher/rancher/releases/tag/v2.7.1)、[v2.6.10](https://github.com/rancher/rancher/releases/tag/v2.6.10) 和 [v2.5.17](https://github.com/rancher/rancher/releases/tag/v2.5.17) |
|
||||
| [CVE-2022-43757](https://github.com/rancher/rancher/security/advisories/GHSA-cq4p-vp5q-4522) | 此问题影响 Rancher 2.5.0 到 2.5.16，2.6.0 至 2.6.9 和 2.7.0。我们发现 Rancher 之前发布的安全公告 [CVE-2021-36782](https://github.com/advisories/GHSA-g7j7-h4q8-8w2f) 没有解决某些敏感字段、Secret Token、加密密钥和 SSH 密钥，这些字段仍然以明文形式直接存储在 Kubernetes 上 `Clusters` 之类的对象。在 Rancher 中，集群中已认证的 `Cluster Owners`、`Cluster Members`、`Project Owners` 和 `Project Members` 可以看到公开的凭证。 | 2023 年 1 月 24 日 | Rancher [v2.7.1](https://github.com/rancher/rancher/releases/tag/v2.7.1)、[v2.6.10](https://github.com/rancher/rancher/releases/tag/v2.6.10) 和 [v2.5.17](https://github.com/rancher/rancher/releases/tag/v2.5.17) |
|
||||
| [CVE-2022-43755](https://github.com/rancher/rancher/security/advisories/GHSA-8c69-r38j-rpfj) | 在 Rancher 2.6.9 和 2.7.0 及之前的版本中发现了一个问题。`cattle-cluster-agent` 使用的 `cattle-token` Secret 是可预测的。重新生成 Token 之后，Token 的值依然相同。如果 Token 被泄露并且出于安全目的需要重新创建，这可能会造成严重的问题。Rancher 的 `cattle-cluster-agent` 使用 `cattle-token` 来连接到 Rancher 配置的下游集群 Kubernetes API。 | 2023 年 1 月 24 日 | Rancher [v2.7.1](https://github.com/rancher/rancher/releases/tag/v2.7.1) 和 [v2.6.10](https://github.com/rancher/rancher/releases/tag/v2.6.10) |
|
||||
| [CVE-2022-21953](https://github.com/rancher/rancher/security/advisories/GHSA-g25r-gvq3-wrq7) | 在 Rancher 2.5.16、2.6.9 和 2.7.0 及之前的版本中发现了一个问题。由于授权逻辑缺陷，任何下游集群上经过身份认证的用户都能在 Rancher `local` 集群中打开一个 shell pod (1)，而且对 kubectl 具有有限的访问权限 (2)。预期的行为是：除非明确授予权限，否则用户在 Rancher `local` 集群中没有这样的访问权限。 | 2023 年 1 月 24 日 | Rancher [v2.7.1](https://github.com/rancher/rancher/releases/tag/v2.7.1)、[v2.6.10](https://github.com/rancher/rancher/releases/tag/v2.6.10) 和 [v2.5.17](https://github.com/rancher/rancher/releases/tag/v2.5.17) |
|
||||
| [GHSA-c45c-39f6-6gw9](https://github.com/rancher/rancher/security/advisories/GHSA-c45c-39f6-6gw9) | 此问题影响 Rancher 2.5.0 到 2.5.16，2.6.0 至 2.6.9 和 2.7.0。只会影响配置了或配置过外部身份认证提供程序的 Rancher 设置。我们发现，当在 Rancher 中配置外部身份认证提供程序然后将其禁用时，Rancher 生成的 Token 如果关联了通过现已禁用的身份认证提供程序授予访问权限的用户，那么 Token 不会被撤销。 | 2023 年 1 月 24 日 | Rancher [v2.7.1](https://github.com/rancher/rancher/releases/tag/v2.7.1)、[v2.6.10](https://github.com/rancher/rancher/releases/tag/v2.6.10) 和 [v2.5.17](https://github.com/rancher/rancher/releases/tag/v2.5.17) |
|
||||
| [CVE-2022-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://github.com/weaveworks/weave/blob/master/site/tasks/manage/security-untrusted-networks.md)创建密码。因此，集群中的网络流量将不加密发送。 | 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-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) |
|
||||
| [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) |
|
||||
| [CVE-2021-36776](https://github.com/rancher/rancher/security/advisories/GHSA-gvh9-xgrq-r8hw) | 在 Rancher 2.5.0 到 2.5.9 中发现了一个漏洞，该漏洞允许经过认证用户通过 API 代理模拟集群上的任何用户，而无需知道被模拟用户的凭证。问题的原因是 API 代理在将请求发送到 Kubernetes API 之前未删除模拟标头。能认证访问 Rancher 的恶意用户可以冒充另一个在 Rancher 认证用户，从而对集群进行管理员级别的访问。 | 2022 年 3 月 31 日 | [Rancher 2.6.0](https://github.com/rancher/rancher/releases/tag/v2.6.0) 和 [Rancher 2.5.10](https://github.com/rancher/rancher/releases/tag/v2.5.10) |
|
||||
| [CVE-2021-25318](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-25318) | Rancher 2.0 的不可编辑版本发现了一个漏洞，在该版本中，无论资源的 API 组如何，用户都可以访问资源。例如，Rancher 应该允许用户访问 `apps.catalog.cattle.io`，但却错误地授予了对 `apps.*` 的访问权限。你可以在[这里](https://github.com/rancher/rancher/security/advisories/GHSA-f9xf-jq4j-vqw4)找到**下游集群**和 **Rancher 管理集群**中受影响的资源。除了升级到打了补丁的 Rancher 版本之外，暂时没有直接的缓解措施。 | 2021 年 7 月 14 日 | [Rancher 2.5.9](https://github.com/rancher/rancher/releases/tag/v2.5.9) 和 [Rancher 2.4.16](https://github.com/rancher/rancher/releases/tag/v2.4.16) |
|
||||
| [CVE-2021-31999](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31999) | Rancher 2.0.0 的补丁版本发现了一个漏洞，恶意的 Rancher 用户可以针对托管集群的 Kubernetes API 的代理发起一个 API 请求，以获取他们无权访问的信息。这是通过在 Connection 标头中传递 “Impersonate-User” 或 “Impersonate-Group” 标头来实现的，然后代理会删除该标头。此时，请求不会模拟用户及其权限，而是会类似 Rancher management server 的请求，并错误地返回信息。该漏洞仅影响对集群具有一定级别权限的 Rancher 用户。除了升级到打了补丁的 Rancher 版本之外，暂时没有直接的缓解措施。 | 2021 年 7 月 14 日 | [Rancher 2.5.9](https://github.com/rancher/rancher/releases/tag/v2.5.9) 和 [Rancher 2.4.16](https://github.com/rancher/rancher/releases/tag/v2.4.16) |
|
||||
| [CVE-2021-25320](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-25320) | Rancher 2.2.0 的补丁版本发现了一个漏洞，云凭证没有正确通过 Rancher API 验证。具体地说，是通过用于与云提供商通信的代理。任何登录并具有有效云提供商云凭证 ID 的 Rancher 用户都可以通过代理 API 调用该云提供商的 API，并且云凭证会被绑定。该漏洞仅影响有效的 Rancher 用户。除了升级到打了补丁的 Rancher 版本之外，暂时没有直接的缓解措施。 | 2021 年 7 月 14 日 | [Rancher 2.5.9](https://github.com/rancher/rancher/releases/tag/v2.5.9) 和 [Rancher 2.4.16](https://github.com/rancher/rancher/releases/tag/v2.4.16) |
|
||||
| [CVE-2021-25313](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-25313) | 所有 Rancher 2 版本上都发现了一个安全漏洞。使用浏览器访问 Rancher API 时，URL 没有正确转义，导致它容易受到 XSS 攻击。这些 API 端点的特制 URL 可能包括嵌入页面并在浏览器中执行的 JavaScript。暂时没有直接的缓解措施。请不要单击指向 Rancher Server 的不受信任链接。 | 2021 年 3 月 2 日 | [Rancher v2.5.6](https://github.com/rancher/rancher/releases/tag/v2.5.6)、[Rancher v2.4.14](https://github.com/rancher/rancher/releases/tag/v2.4.14) 和 [Rancher v2.3.11](https://github.com/rancher/rancher/releases/tag/v2.3.11) |
|
||||
| [CVE-2019-14435](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14435) | 此漏洞让已验证的用户可以通过 Rancher 使用的系统服务容器可访问的 IP 提取私有数据。这包括但不限于云提供商元数据服务等服务。虽然 Rancher 允许用户为系统服务配置白名单域，但这个漏洞仍然可以被精心设计的 HTTP 请求利用。该问题由 Workiva 的 Matt Belisle 和 Alex Stevenson 发现并报告。 | 2019 年 8 月 5 日 | [Rancher 2.2.7](https://github.com/rancher/rancher/releases/tag/v2.2.7) 和 [Rancher 2.1.12](https://github.com/rancher/rancher/releases/tag/v2.1.12) |
|
||||
| [CVE-2019-14436](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14436) | 该漏洞允许有权编辑角色绑定的项目成员为自己或其他用户分配集群级别的角色，从而授予他们对该集群的管理员访问权限。该问题由 Nokia 的 Michal Lipinski 发现并报告。 | 2019 年 8 月 5 日 | [Rancher 2.2.7](https://github.com/rancher/rancher/releases/tag/v2.2.7) 和 [Rancher 2.1.12](https://github.com/rancher/rancher/releases/tag/v2.1.12) |
|
||||
| [CVE-2019-13209](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13209) | 该漏洞被称为[跨网页 Websocket 劫持攻击](https://www.christian-schneider.net/CrossSiteWebSocketHijacking.html)。该攻击允许攻击者以受害用户的角色/权限访问由 Rancher 管理的集群。它让受害用户登录到 Rancher Server，然后访问由攻击者托管的第三方站点。完成后，攻击者就可以使用受害用户的权限和身份对 Kubernetes API 执行命令。该问题由 Workiva 的 Matt Belisle 和 Alex Stevenson 报告。 | 2019 年 7 月 15 日 | [Rancher 2.2.5](https://github.com/rancher/rancher/releases/tag/v2.2.5)、[Rancher 2.1.11](https://github.com/rancher/rancher/releases/tag/v2.1.11) 和 [Rancher 2.0.16](https://github.com/rancher/rancher/releases/tag/v2.0.16) |
|
||||
| [CVE-2019-12303](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12303) | 项目所有者可以注入额外的 fluentd 日志配置，从而在 fluentd 容器内读取文件或执行任意命令。该问题由 Untamed Theory 的 Tyler Welton 报告。 | 2019 年 6 月 5 日 | [Rancher 2.2.4](https://github.com/rancher/rancher/releases/tag/v2.2.4)、[Rancher 2.1.10](https://github.com/rancher/rancher/releases/tag/v2.1.10) 和 [Rancher 2.0.15](https://github.com/rancher/rancher/releases/tag/v2.0.15) |
|
||||
| [CVE-2019-12274](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12274) | 如果节点使用的内置主机驱动使用了文件路径选项，则节点可以读取 Rancher Server 容器内的任意文件，包括敏感文件。 | 2019 年 6 月 5 日 | [Rancher 2.2.4](https://github.com/rancher/rancher/releases/tag/v2.2.4)、[Rancher 2.1.10](https://github.com/rancher/rancher/releases/tag/v2.1.10) 和 [Rancher 2.0.15](https://github.com/rancher/rancher/releases/tag/v2.0.15) |
|
||||
| [CVE-2019-11202](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11202) | 即使已被显式删除，Rancher 的默认管理员会在 Rancher 重启时重新创建。 | 2019 年 4 月 16 日 | [Rancher 2.2.2](https://github.com/rancher/rancher/releases/tag/v2.2.2)、[Rancher 2.1.9](https://github.com/rancher/rancher/releases/tag/v2.1.9) 和 [Rancher 2.0.14](https://github.com/rancher/rancher/releases/tag/v2.0.14) |
|
||||
| [CVE-2019-6287](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6287) | 如果将项目成员添加到多个项目中，则成员还能继续访问被删除的项目中的命名空间。 | 2019 年 1 月 29 日 | [Rancher 2.1.6](https://github.com/rancher/rancher/releases/tag/v2.1.6) 和 [Rancher 2.0.11](https://github.com/rancher/rancher/releases/tag/v2.0.11) |
|
||||
| [CVE-2018-20321](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20321) | 任何有权访问 `default` 命名空间的项目成员都可以在 pod 中挂载 `netes-default` ServiceAccount，然后使用该 pod 对 Kubernetes 集群执行管理特权命令。 | 2019 年 1 月 29 日 | [Rancher 2.1.6](https://github.com/rancher/rancher/releases/tag/v2.1.6) 和 [Rancher 2.0.11](https://github.com/rancher/rancher/releases/tag/v2.0.11) - 对于这些版本或更高版本，我们有对应的[回滚说明](../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rollbacks.md)。 |
|
||||
+66
@@ -0,0 +1,66 @@
|
||||
---
|
||||
title: 关于 rancher-selinux
|
||||
---
|
||||
|
||||
要让 Rancher 使用 SELinux，你必须手动为 SELinux 节点启用一些功能。为了解决这个问题，Rancher 提供了一个 SELinux RPM。
|
||||
|
||||
The `rancher-selinux` RPM contains a set of SELinux policies designed to grant the necessary privileges to various Rancher components running on Linux systems with SELinux enabled.
|
||||
|
||||
`rancher-selinux` 的 GitHub 仓库在[这里](https://github.com/rancher/rancher-selinux)。
|
||||
|
||||
## 安装 rancher-selinux RPM
|
||||
|
||||
:::note 要求
|
||||
|
||||
rancher-selinux RPM 已在 CentOS 7 和 8 上进行了测试。
|
||||
|
||||
:::
|
||||
|
||||
### 1. 设置 yum 仓库
|
||||
|
||||
设置 yum 仓库，从而直接在集群中的所有主机上安装 `rancher-selinux`。
|
||||
|
||||
要使用 RPM 仓库，在 CentOS 7 或 RHEL 7 系统上运行以下 bash 代码片段：
|
||||
|
||||
```
|
||||
# cat << EOF > /etc/yum.repos.d/rancher.repo
|
||||
[rancher]
|
||||
name=Rancher
|
||||
baseurl=https://rpm.rancher.io/rancher/production/centos/7/noarch
|
||||
enabled=1
|
||||
gpgcheck=1
|
||||
gpgkey=https://rpm.rancher.io/public.key
|
||||
EOF
|
||||
```
|
||||
|
||||
要使用 RPM 仓库，在 CentOS 8 或 RHEL 8 系统上运行以下 bash 代码片段：
|
||||
|
||||
```
|
||||
# cat << EOF > /etc/yum.repos.d/rancher.repo
|
||||
[rancher]
|
||||
name=Rancher
|
||||
baseurl=https://rpm.rancher.io/rancher/production/centos/8/noarch
|
||||
enabled=1
|
||||
gpgcheck=1
|
||||
gpgkey=https://rpm.rancher.io/public.key
|
||||
EOF
|
||||
```
|
||||
### 2. 安装 RPM
|
||||
|
||||
安装 RPM：
|
||||
|
||||
```
|
||||
yum -y install rancher-selinux
|
||||
```
|
||||
|
||||
## 配置 Logging 应用程序以使用 SELinux
|
||||
|
||||
:::note 要求
|
||||
|
||||
Logging v2 已在 RHEL/CentOS 7 和 8 上使用 SELinux 进行了测试。
|
||||
|
||||
:::
|
||||
|
||||
在主机上安装 `rancher-selinux` RPM 后，应用程序不会自动运行。它们需要在 RPM 提供的允许的 SELinux 容器域中运行。
|
||||
|
||||
要将 `rancher-logging` Chart 配置为支持 SELinux，请在安装 Chart 时将 `values.yaml` 中的 `global.seLinux.enabled` 更改为 true。
|
||||
+9
@@ -0,0 +1,9 @@
|
||||
---
|
||||
title: 关于 rke2-selinux
|
||||
---
|
||||
|
||||
`rke2-selinux` 为 RKE2 提供策略。如果 RKE2 安装程序脚本检测到它运行在基于 RPM 的发行版上，它会自动安装。
|
||||
|
||||
`rke2-selinux` 的 GitHub 仓库在[这里](https://github.com/rancher/rke2-selinux)。
|
||||
|
||||
有关在启用 SELinux 的主机上安装 RKE2 的更多信息，请参阅 [RKE2 文档](https://docs.rke2.io/install/methods#rpm)。
|
||||
+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 主机上正常运行。
|
||||
Reference in New Issue
Block a user