mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-26 04:58:07 +00:00
Translate v2.7 and v2.6 docs
This commit is contained in:
vickyhella
+1
-1
@@ -39,7 +39,7 @@ title: 在 vSphere 环境中安装 Rancher
|
||||
|
||||
### 根据 Rancher 文档确定虚拟机的大小
|
||||
|
||||
请参见[安装要求](https://rancher.com/docs/rancher/v2.6/en/installation/requirements/)来确定虚拟机的大小。
|
||||
请参阅[安装要求](../../../pages-for-subheaders/installation-requirements.md)。
|
||||
|
||||
### 利用虚拟机模板来构建环境
|
||||
|
||||
|
||||
+1
-1
@@ -7,7 +7,7 @@ Rancher CLI（命令行界面）是一个命令行工具，可用于与 Rancher
|
||||
|
||||
### 下载 Rancher CLI
|
||||
|
||||
你可以直接 UI 下载二进制文件。链接位于 UI 页脚的右侧。我们提供用于 Windows、Mac 和 Linux 的二进制文件。你还可以访问我们的 CLI [发布页面](https://github.com/rancher/cli/releases)直接下载二进制文件。
|
||||
你可以直接 UI 下载二进制文件。
|
||||
|
||||
1. 点击左上角的 **☰**。
|
||||
1. 单击底部的 **v2.6.x**，**v2.6.x** 是一个超链接文本，表示已安装的 Rancher 版本。
|
||||
|
||||
+1
@@ -3,6 +3,7 @@ title: EC2 节点模板配置
|
||||
---
|
||||
|
||||
有关 EC2 和节点的更多详细信息，请参阅 [EC2 管理控制台](https://aws.amazon.com/ec2)的官方文档。
|
||||
|
||||
### 区域
|
||||
|
||||
在**区域**字段中，选择创建云凭证时使用的同一区域。
|
||||
|
||||
+12
-3
@@ -10,15 +10,24 @@ title: Azure 节点模板配置
|
||||
- **Network** 配置集群中使用的网络。
|
||||
- **Instance** 自定义你的 VM 配置。
|
||||
|
||||
:::note
|
||||
:::note
|
||||
|
||||
如果在与 VM 不同的资源组中使用 VNet，则 VNet 名称需要以资源组名称作为前缀。例如，`<resource group>:<vnet>`。
|
||||
如果在与 VM 不同的资源组中使用 VNet，则 VNet 名称需要以资源组名称作为前缀。例如，`<resource group>:<vnet>`。
|
||||
|
||||
:::
|
||||
:::
|
||||
|
||||
如果你使用 Docker，[Docker daemon](https://docs.docker.com/engine/docker-overview/#the-docker-daemon) 配置选项包括：
|
||||
|
||||
- **标签**：有关标签的信息，请参阅 [Docker 对象标签文档](https://docs.docker.com/config/labels-custom-metadata/)。
|
||||
- **Docker 引擎安装 URL**：确定要在实例上安装的 Docker 版本。
|
||||
|
||||
:::note
|
||||
|
||||
如果要配置 Red Hat Enterprise Linux (RHEL) 或 CentOS 节点，请将 **Docker Install URL** 字段保留为默认值，或选择 **none**。由于 Docker 已经安装在这些节点上，因此将绕过 Docker 安装检查。
|
||||
|
||||
如果没有将 **Docker Install URL** 设置为默认值或 **none**，你可能会看到错误消息：`Error creating machine: RHEL ssh command error: command: sudo -E yum install -y curl err: exit status 1 output: Updating Subscription Management repositories`。
|
||||
|
||||
:::
|
||||
|
||||
- **镜像仓库 mirror**：Docker daemon 使用的 Docker 镜像仓库镜像。
|
||||
- **其他高级选项**：参见 [Docker daemon 选项参考](https://docs.docker.com/engine/reference/commandline/dockerd/)。
|
||||
|
||||
+10
@@ -54,3 +54,13 @@ title: Nutanix 节点模板配置
|
||||
不建议使用基于 cloud-init 的网络配置，仅支持使用用户数据 `runcmd`，不支持 NoCloud 或其他网络配置数据源。
|
||||
|
||||
建议使用 Nutanix IP Address Management（IPAM) 或其他 DHCP 服务。
|
||||
|
||||
## 引擎选项
|
||||
|
||||
在节点模板的**引擎选项**中，你可以配置容器 daemon。你可能需要指定容器版本或容器镜像仓库 Mirror。
|
||||
|
||||
:::note
|
||||
如果要配置 Red Hat Enterprise Linux (RHEL) 或 CentOS 节点，请将 **Docker Install URL** 字段保留为默认值，或选择 **none**。由于 Docker 已经安装在这些节点上，因此将绕过 Docker 安装检查。
|
||||
|
||||
如果没有将 **Docker Install URL** 设置为默认值或 **none**，你可能会看到错误消息：`Error creating machine: RHEL ssh command error: command: sudo -E yum install -y curl err: exit status 1 output: Updating Subscription Management repositories`。
|
||||
:::
|
||||
+10
@@ -83,3 +83,13 @@ title: vSphere 节点模板配置
|
||||
要使用 cloud-init 初始化，请使用有效的 YAML 语法创建一个 cloud config 文件，并将文件内容粘贴到 **Cloud Init** 字段中。要获取支持的 cloud config 指令的注释示例集，请参阅 [cloud-init 文档](https://cloudinit.readthedocs.io/en/latest/topics/examples.html)。
|
||||
|
||||
请注意，使用 ISO 创建方法时不支持 cloud-init。
|
||||
|
||||
## 引擎选项
|
||||
|
||||
在节点模板的**引擎选项**中，你可以配置容器 daemon。你可能需要指定容器版本或容器镜像仓库 Mirror。
|
||||
|
||||
:::note
|
||||
如果要配置 Red Hat Enterprise Linux (RHEL) 或 CentOS 节点，请将 **Docker Install URL** 字段保留为默认值，或选择 **none**。由于 Docker 已经安装在这些节点上，因此将绕过 Docker 安装检查。
|
||||
|
||||
如果没有将 **Docker Install URL** 设置为默认值或 **none**，你可能会看到错误消息：`Error creating machine: RHEL ssh command error: command: sudo -E yum install -y curl err: exit status 1 output: Updating Subscription Management repositories`。
|
||||
:::
|
||||
+12
-2
@@ -20,6 +20,16 @@ title: Rancher Server 和 Components
|
||||
|
||||
Rancher 的 Docker 安装仅推荐用于开发和测试环境中。Rancher 版本决定了能否将 Rancher 迁移到高可用集群。
|
||||
|
||||
Rancher backup operator 可将 Rancher 从单个 Docker 容器迁移到高可用 Kubernetes 集群上。详情请参见[把 Rancher 迁移到新集群](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md)。
|
||||
要查看已部署的资源，运行以下命令：
|
||||
|
||||
不管 Rancher Server 是如何安装的，它都应该运行在与其管理的下游集群不同节点上。如果 Rancher 安装在高可用的 Kubernetes 集群上，它需要运行在与其管理的集群不同的集群上。
|
||||
```bash
|
||||
kubectl get all -n <namespace>
|
||||
```
|
||||
如果你具有管理员权限，你还可以在 Rancher UI 中看到列出的资源：
|
||||
|
||||
1. 单击 **☰** 并选择一个集群。
|
||||
1. 从侧面导航菜单中选择**更多资源**，从而按类型查看已部署的资源。
|
||||
1. 从侧面导航菜单中选择**集群** > **项目/命名空间**，然后选择一个命名空间，从而按命名空间查看已部署的资源。
|
||||
Rancher backup operator 可将 Rancher 从单个 Docker 容器迁移到高可用 Kubernetes 集群上。有关详细信息，请参阅[将 Rancher 迁移到新集群](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md)。
|
||||
|
||||
不管 Rancher Server 是如何安装的，它都应该运行在与其管理的下游集群不同节点上。如果 Rancher 安装在高可用的 Kubernetes 集群上，它需要运行在与其管理的集群不同的集群上。
|
||||
|
||||
+3148
File diff suppressed because it is too large
Load Diff
+3148
File diff suppressed because it is too large
Load Diff
+3148
File diff suppressed because it is too large
Load Diff
+3083
File diff suppressed because one or more lines are too long
+3084
File diff suppressed because one or more lines are too long
+3085
File diff suppressed because one or more lines are too long
+3196
File diff suppressed because one or more lines are too long
+3196
File diff suppressed because one or more lines are too long
+3196
File diff suppressed because one or more lines are too long
+62
@@ -0,0 +1,62 @@
|
||||
---
|
||||
title: PodSecurityConfiguration 示例
|
||||
---
|
||||
|
||||
以下 PodSecurityConfiguration 包含了 `rancher-restricted` 集群正常运行所需的 Rancher 命名空间豁免。
|
||||
|
||||
```yaml
|
||||
apiVersion: apiserver.config.k8s.io/v1
|
||||
kind: AdmissionConfiguration
|
||||
plugins:
|
||||
- name: PodSecurity
|
||||
configuration:
|
||||
apiVersion: pod-security.admission.config.k8s.io/v1
|
||||
kind: PodSecurityConfiguration
|
||||
defaults:
|
||||
enforce: "restricted"
|
||||
enforce-version: "latest"
|
||||
audit: "restricted"
|
||||
audit-version: "latest"
|
||||
warn: "restricted"
|
||||
warn-version: "latest"
|
||||
exemptions:
|
||||
usernames: []
|
||||
runtimeClasses: []
|
||||
namespaces: [calico-apiserver,
|
||||
calico-system,
|
||||
cattle-alerting,
|
||||
cattle-csp-adapter-system,
|
||||
cattle-elemental-system,
|
||||
cattle-epinio-system,
|
||||
cattle-externalip-system,
|
||||
cattle-fleet-local-system,
|
||||
cattle-fleet-system,
|
||||
cattle-gatekeeper-system,
|
||||
cattle-global-data,
|
||||
cattle-global-nt,
|
||||
cattle-impersonation-system,
|
||||
cattle-istio,
|
||||
cattle-istio-system,
|
||||
cattle-logging,
|
||||
cattle-logging-system,
|
||||
cattle-monitoring-system,
|
||||
cattle-neuvector-system,
|
||||
cattle-prometheus,
|
||||
cattle-resources-system,
|
||||
cattle-sriov-system,
|
||||
cattle-system,
|
||||
cattle-ui-plugin-system,
|
||||
cattle-windows-gmsa-system,
|
||||
cert-manager,
|
||||
cis-operator-system,
|
||||
fleet-default,
|
||||
ingress-nginx,
|
||||
istio-system,
|
||||
kube-node-lease,
|
||||
kube-public,
|
||||
kube-system,
|
||||
longhorn-system,
|
||||
rancher-alerting-drivers,
|
||||
security-scan,
|
||||
tigera-operator]
|
||||
```
|
||||
-644
@@ -1,644 +0,0 @@
|
||||
---
|
||||
title: 使用 CIS 1.6 Benchmark 的 RKE 强化指南
|
||||
---
|
||||
|
||||
本文档提供了用于强化 RKE 集群（使用 Rancher 2.6 进行配置）生产安装的说明。此处概述了遵循 CIS 的 Kubernetes Benchmark 管控所需的配置和控制。
|
||||
|
||||
:::note
|
||||
|
||||
本强化指南介绍了如何保护集群中的节点。建议你在安装 Kubernetes 之前参考本指南。
|
||||
|
||||
:::
|
||||
|
||||
本强化指南适用于 RKE 集群，并对应以下 CIS Kubernetes Benchmark、Kubernetes 和 Rancher 版本：
|
||||
|
||||
| Rancher 版本 | CIS Benchmark 版本 | Kubernetes 版本 |
|
||||
| --------------- | --------------------- | ------------------ |
|
||||
| Rancher v2.6 | Benchmark v1.6 | Kubernetes v1.18 到 v1.23 |
|
||||
|
||||
[点击此处下载本文档的 PDF 版本](https://releases.rancher.com/documents/security/2.6/Rancher_v2-6_CIS_v1-6_Hardening_Guide.pdf)。
|
||||
|
||||
|
||||
### 概述
|
||||
|
||||
本文档介绍了强化 RKE 集群的说明，该集群使用 Kubernetes 1.18 至 1.23 版本安装 Rancher 2.6，或在 Rancher 2.6 中配置使用 Kubernetes 1.18 至 1.23 版本的 RKE 集群。此处概述了遵循 CIS 的 Kubernetes Benchmark 管控所需的配置。
|
||||
|
||||
有关根据官方 CIS Benchmark 评估强化集群的更多详细信息，请参阅 [CIS 1.6 Benchmark - 自我评估指南 - Rancher 2.6](./rke1-self-assessment-guide-with-cis-v1.6-benchmark.md)。
|
||||
|
||||
#### 已知问题
|
||||
|
||||
- 如果注册自定义节点时仅提供公共 IP，CIS 1.6 强化设置中用于 Pod 的 Rancher **exec shell** 和 **view logs** 将**不起作用**。此功能要求在注册自定义节点时提供私有 IP。
|
||||
- 如果把 `default_pod_security_policy_template_id:` 设置为 `restricted` 或 `restricted-noroot`，根据 Rancher 提供的 [Pod 安全策略 (PSP)](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md)，Rancher 会在默认 ServiceAccount 上创建 **RoleBindings** 和 **ClusterRoleBindings**。CIS 1.6 检查 5.1.5 时会要求默认 ServiceAccount 除了默认值之外没有绑定到其他角色或集群角色。此外，你还需要配置默认 ServiceAccount，使其不提供 ServiceAccount 令牌并且没有显式分配任何权限。
|
||||
|
||||
### 配置内核运行时参数
|
||||
|
||||
建议为集群中所有类型的节点使用以下 `sysctl` 配置。在 `/etc/sysctl.d/90-kubelet.conf` 中设置如下参数：
|
||||
|
||||
```ini
|
||||
vm.overcommit_memory=1
|
||||
vm.panic_on_oom=0
|
||||
kernel.panic=10
|
||||
kernel.panic_on_oops=1
|
||||
kernel.keys.root_maxbytes=25000000
|
||||
```
|
||||
|
||||
运行 `sysctl -p /etc/sysctl.d/90-kubelet.conf` 以启用设置。
|
||||
|
||||
### 配置 `etcd` 用户和组
|
||||
|
||||
在安装 RKE 之前，你需要设置 **etcd** 服务的用户账号和组。在安装期间，**etcd** 用户的 **uid** 和 **gid** 将用于在 RKE **config.yml** 中设置适当的文件和目录权限。
|
||||
|
||||
#### 创建 `etcd` 用户和组
|
||||
|
||||
要创建 **etcd** 用户和组，请运行以下控制台命令。下面的命令使用 `52034` 作为 **uid** 和 **gid**。该值只是一个示例。你可以使用有效且未被使用的 **uid** 或 **gid** 来代替 `52034`。
|
||||
|
||||
```bash
|
||||
groupadd --gid 52034 etcd
|
||||
useradd --comment "etcd service account" --uid 52034 --gid 52034 etcd --shell /usr/sbin/nologin
|
||||
```
|
||||
|
||||
使用 **etcd** 用户的 **uid** 和 **gid** 来更新 RKE **config.yml**：
|
||||
|
||||
```yaml
|
||||
services:
|
||||
etcd:
|
||||
gid: 52034
|
||||
uid: 52034
|
||||
```
|
||||
|
||||
### 配置 `default` ServiceAccount
|
||||
|
||||
#### 将 `default` ServiceAccount 的 `automountServiceAccountToken` 设置为 `false`
|
||||
|
||||
Kubernetes 为集群工作负载提供了一个 default ServiceAccount，但没有为 pod 分配特定 ServiceAccount。如果需要从 pod 访问 Kubernetes API，则需要为该 pod 创建一个特定的 ServiceAccount 并授予权限。你还需要配置 default ServiceAccount，使其不提供 ServiceAccount 令牌并且没有任何显式的权限分配。
|
||||
|
||||
对于标准 RKE 中的每个命名空间（包括 **default** 和 **kube-system**），**default** ServiceAccount 必须包含以下值：
|
||||
|
||||
```yaml
|
||||
automountServiceAccountToken: false
|
||||
```
|
||||
|
||||
将以下配置保存到名为 `account_update.yaml` 的文件中:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: default
|
||||
automountServiceAccountToken: false
|
||||
```
|
||||
|
||||
创建一个名为 `account_update.sh` 的 bash 脚本文件。确保为脚本设置了 `chmod +x account_update.sh`，使脚本具有执行权限：
|
||||
|
||||
```bash
|
||||
#!/bin/bash -e
|
||||
|
||||
for namespace in $(kubectl get namespaces -A -o=jsonpath="{.items[*]['metadata.name']}"); do
|
||||
kubectl patch serviceaccount default -n ${namespace} -p "$(cat account_update.yaml)"
|
||||
done
|
||||
```
|
||||
|
||||
### 配置网络策略
|
||||
|
||||
#### 确保所有命名空间都定义了网络策略
|
||||
|
||||
如果你在同一个 Kubernetes 集群上运行不同的应用程序，被感染的应用程序可能会攻击相邻的应用程序。要确保容器只进行所需的通信，网络分段非常重要。网络策略指的是如何允许 Pod 与其他 Pod 以及与其他网络端点进行通信。
|
||||
|
||||
网络策略是命名空间范围的。为某个命名空间配置网络策略后，该策略不允许的所有其他流量都会被拒绝。但是，如果命名空间没有配置网络策略，则所有流量都会允许进出该命名空间中的 Pod。要执行网络策略，你必须启用 CNI（容器网络接口）插件。本指南使用 [Canal](https://github.com/projectcalico/canal) 来执行策略。有关 CNI 网络插件的更多信息，请参阅[这里](https://www.suse.com/c/rancher_blog/comparing-kubernetes-cni-providers-flannel-calico-canal-and-weave/)。
|
||||
|
||||
在集群上启用了 CNI 网络插件后，你就可以应用默认网络策略了。以下提供了一个供参考的 **permissive** 示例。如果要允许所有流量发送到命名空间中的所有 pod（即使添加了导致某些 pod 被“隔离”的策略），你可以显式创建一个策略来允许该命名空间中的所有流量。将以下配置保存为 `default-allow-all.yaml`。如需查看网络策略相关的其他[文档](https://kubernetes.io/docs/concepts/services-networking/network-policies/)，请前往 Kubernetes 网站。
|
||||
|
||||
:::note
|
||||
|
||||
此 `NetworkPolicy` 只是一个示例，不建议用于生产环境。
|
||||
|
||||
:::
|
||||
|
||||
```yaml
|
||||
---
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: NetworkPolicy
|
||||
metadata:
|
||||
name: default-allow-all
|
||||
spec:
|
||||
podSelector: {}
|
||||
ingress:
|
||||
- {}
|
||||
egress:
|
||||
- {}
|
||||
policyTypes:
|
||||
- Ingress
|
||||
- Egress
|
||||
```
|
||||
|
||||
创建一个名为 `apply_networkPolicy_to_all_ns.sh` 的 bash 脚本文件。确保为脚本设置了 `chmod +x apply_networkPolicy_to_all_ns.sh`，使脚本具有执行权限：
|
||||
|
||||
```bash
|
||||
#!/bin/bash -e
|
||||
|
||||
for namespace in $(kubectl get namespaces -A -o=jsonpath="{.items[*]['metadata.name']}"); do
|
||||
kubectl apply -f default-allow-all.yaml -n ${namespace}
|
||||
done
|
||||
```
|
||||
|
||||
执行此脚本能将具有 **permissive** `NetworkPolicy` 的 `default-allow-all.yaml` 配置应用于所有命名空间。
|
||||
|
||||
### 强化 RKE `cluster.yml` 配置参考
|
||||
|
||||
RKE CLI 能使用 `cluster.yml` 配置参考，该文件提供了实现 Rancher Kubernetes Engine (RKE) 的强化安装所需的配置。RKE 的[安装文档](https://rancher.com/docs/rke/latest/en/installation/)介绍了有关配置项的其他详细信息。此 `cluster.yml` 参考不包括所需的 **nodes** 参数，该参数会因你的环境而异。如需查看 RKE 中节点配置的文档，请参阅[此处](https://rancher.com/docs/rke/latest/en/config-options/nodes/)。
|
||||
|
||||
:::note 重要提示：
|
||||
|
||||
对于 Kubernetes 1.18 集群，请从 `PodSecurityPolicy` 中删除 `spec.volumes: 'ephemeral'` 配置，因为此 Kubernetes 版本不支持它。
|
||||
|
||||
:::
|
||||
|
||||
```yaml
|
||||
# 如果你打算在离线环境中部署 Kubernetes，
|
||||
# 请查阅配置自定义 RKE 镜像的文档。
|
||||
# https://rancher.com/docs/rke/latest/en/installation/
|
||||
|
||||
# nodes 参数是必需的，并且会根据你的环境而有所不同。
|
||||
# 节点配置的文档可以在这里找到：
|
||||
# https://rancher.com/docs/rke/latest/en/config-options/nodes/
|
||||
nodes: []
|
||||
services:
|
||||
etcd:
|
||||
image: ""
|
||||
extra_args: {}
|
||||
extra_binds: []
|
||||
extra_env: []
|
||||
win_extra_args: {}
|
||||
win_extra_binds: []
|
||||
win_extra_env: []
|
||||
external_urls: []
|
||||
ca_cert: ""
|
||||
cert: ""
|
||||
key: ""
|
||||
path: ""
|
||||
uid: 52034
|
||||
gid: 52034
|
||||
snapshot: false
|
||||
retention: ""
|
||||
creation: ""
|
||||
backup_config: null
|
||||
kube-api:
|
||||
image: ""
|
||||
extra_args: {}
|
||||
extra_binds: []
|
||||
extra_env: []
|
||||
win_extra_args: {}
|
||||
win_extra_binds: []
|
||||
win_extra_env: []
|
||||
service_cluster_ip_range: ""
|
||||
service_node_port_range: ""
|
||||
pod_security_policy: true
|
||||
always_pull_images: false
|
||||
secrets_encryption_config:
|
||||
enabled: true
|
||||
custom_config: null
|
||||
audit_log:
|
||||
enabled: true
|
||||
configuration: null
|
||||
admission_configuration: null
|
||||
event_rate_limit:
|
||||
enabled: true
|
||||
configuration: null
|
||||
kube-controller:
|
||||
image: ""
|
||||
extra_args:
|
||||
feature-gates: RotateKubeletServerCertificate=true
|
||||
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
|
||||
bind-address: 127.0.0.1
|
||||
extra_binds: []
|
||||
extra_env: []
|
||||
win_extra_args: {}
|
||||
win_extra_binds: []
|
||||
win_extra_env: []
|
||||
cluster_cidr: ""
|
||||
service_cluster_ip_range: ""
|
||||
scheduler:
|
||||
image: ""
|
||||
extra_args:
|
||||
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
|
||||
bind-address: 127.0.0.1
|
||||
extra_binds: []
|
||||
extra_env: []
|
||||
win_extra_args: {}
|
||||
win_extra_binds: []
|
||||
win_extra_env: []
|
||||
kubelet:
|
||||
image: ""
|
||||
extra_args:
|
||||
feature-gates: RotateKubeletServerCertificate=true
|
||||
protect-kernel-defaults: true
|
||||
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
|
||||
extra_binds: []
|
||||
extra_env: []
|
||||
win_extra_args: {}
|
||||
win_extra_binds: []
|
||||
win_extra_env: []
|
||||
cluster_domain: cluster.local
|
||||
infra_container_image: ""
|
||||
cluster_dns_server: ""
|
||||
fail_swap_on: false
|
||||
generate_serving_certificate: true
|
||||
kubeproxy:
|
||||
image: ""
|
||||
extra_args: {}
|
||||
extra_binds: []
|
||||
extra_env: []
|
||||
win_extra_args: {}
|
||||
win_extra_binds: []
|
||||
win_extra_env: []
|
||||
network:
|
||||
plugin: ""
|
||||
options: {}
|
||||
mtu: 0
|
||||
node_selector: {}
|
||||
update_strategy: null
|
||||
authentication:
|
||||
strategy: ""
|
||||
sans: []
|
||||
webhook: null
|
||||
addons: |
|
||||
# Upstream Kubernetes restricted PSP policy
|
||||
# https://github.com/kubernetes/website/blob/564baf15c102412522e9c8fc6ef2b5ff5b6e766c/content/en/examples/policy/restricted-psp.yaml
|
||||
apiVersion: policy/v1beta1
|
||||
kind: PodSecurityPolicy
|
||||
metadata:
|
||||
name: restricted-noroot
|
||||
spec:
|
||||
privileged: false
|
||||
# Required to prevent escalations to root.
|
||||
allowPrivilegeEscalation: false
|
||||
requiredDropCapabilities:
|
||||
- ALL
|
||||
# Allow core volume types.
|
||||
volumes:
|
||||
- 'configMap'
|
||||
- 'emptyDir'
|
||||
- 'projected'
|
||||
- 'secret'
|
||||
- 'downwardAPI'
|
||||
# Assume that ephemeral CSI drivers & persistentVolumes set up by the cluster admin are safe to use.
|
||||
- 'csi'
|
||||
- 'persistentVolumeClaim'
|
||||
- 'ephemeral'
|
||||
hostNetwork: false
|
||||
hostIPC: false
|
||||
hostPID: false
|
||||
runAsUser:
|
||||
# Require the container to run without root privileges.
|
||||
rule: 'MustRunAsNonRoot'
|
||||
seLinux:
|
||||
# This policy assumes the nodes are using AppArmor rather than SELinux.
|
||||
rule: 'RunAsAny'
|
||||
supplementalGroups:
|
||||
rule: 'MustRunAs'
|
||||
ranges:
|
||||
# Forbid adding the root group.
|
||||
- min: 1
|
||||
max: 65535
|
||||
fsGroup:
|
||||
rule: 'MustRunAs'
|
||||
ranges:
|
||||
# Forbid adding the root group.
|
||||
- min: 1
|
||||
max: 65535
|
||||
readOnlyRootFilesystem: false
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: psp:restricted-noroot
|
||||
rules:
|
||||
- apiGroups:
|
||||
- extensions
|
||||
resourceNames:
|
||||
- restricted-noroot
|
||||
resources:
|
||||
- podsecuritypolicies
|
||||
verbs:
|
||||
- use
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRoleBinding
|
||||
metadata:
|
||||
name: psp:restricted-noroot
|
||||
roleRef:
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
kind: ClusterRole
|
||||
name: psp:restricted-noroot
|
||||
subjects:
|
||||
- apiGroup: rbac.authorization.k8s.io
|
||||
kind: Group
|
||||
name: system:serviceaccounts
|
||||
- apiGroup: rbac.authorization.k8s.io
|
||||
kind: Group
|
||||
name: system:authenticated
|
||||
---
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: NetworkPolicy
|
||||
metadata:
|
||||
name: default-allow-all
|
||||
spec:
|
||||
podSelector: {}
|
||||
ingress:
|
||||
- {}
|
||||
egress:
|
||||
- {}
|
||||
policyTypes:
|
||||
- Ingress
|
||||
- Egress
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: default
|
||||
automountServiceAccountToken: false
|
||||
addons_include: []
|
||||
system_images:
|
||||
etcd: ""
|
||||
alpine: ""
|
||||
nginx_proxy: ""
|
||||
cert_downloader: ""
|
||||
kubernetes_services_sidecar: ""
|
||||
kubedns: ""
|
||||
dnsmasq: ""
|
||||
kubedns_sidecar: ""
|
||||
kubedns_autoscaler: ""
|
||||
coredns: ""
|
||||
coredns_autoscaler: ""
|
||||
nodelocal: ""
|
||||
kubernetes: ""
|
||||
flannel: ""
|
||||
flannel_cni: ""
|
||||
calico_node: ""
|
||||
calico_cni: ""
|
||||
calico_controllers: ""
|
||||
calico_ctl: ""
|
||||
calico_flexvol: ""
|
||||
canal_node: ""
|
||||
canal_cni: ""
|
||||
canal_controllers: ""
|
||||
canal_flannel: ""
|
||||
canal_flexvol: ""
|
||||
weave_node: ""
|
||||
weave_cni: ""
|
||||
pod_infra_container: ""
|
||||
ingress: ""
|
||||
ingress_backend: ""
|
||||
metrics_server: ""
|
||||
windows_pod_infra_container: ""
|
||||
ssh_key_path: ""
|
||||
ssh_cert_path: ""
|
||||
ssh_agent_auth: false
|
||||
authorization:
|
||||
mode: ""
|
||||
options: {}
|
||||
ignore_docker_version: false
|
||||
kubernetes_version: ""
|
||||
private_registries: []
|
||||
ingress:
|
||||
provider: ""
|
||||
options: {}
|
||||
node_selector: {}
|
||||
extra_args: {}
|
||||
dns_policy: ""
|
||||
extra_envs: []
|
||||
extra_volumes: []
|
||||
extra_volume_mounts: []
|
||||
update_strategy: null
|
||||
http_port: 0
|
||||
https_port: 0
|
||||
network_mode: ""
|
||||
cluster_name:
|
||||
cloud_provider:
|
||||
name: ""
|
||||
prefix_path: ""
|
||||
win_prefix_path: ""
|
||||
addon_job_timeout: 0
|
||||
bastion_host:
|
||||
address: ""
|
||||
port: ""
|
||||
user: ""
|
||||
ssh_key: ""
|
||||
ssh_key_path: ""
|
||||
ssh_cert: ""
|
||||
ssh_cert_path: ""
|
||||
monitoring:
|
||||
provider: ""
|
||||
options: {}
|
||||
node_selector: {}
|
||||
update_strategy: null
|
||||
replicas: null
|
||||
restore:
|
||||
restore: false
|
||||
snapshot_name: ""
|
||||
dns: null
|
||||
upgrade_strategy:
|
||||
max_unavailable_worker: ""
|
||||
max_unavailable_controlplane: ""
|
||||
drain: null
|
||||
node_drain_input: null
|
||||
```
|
||||
|
||||
### 强化 RKE 模板配置参考
|
||||
|
||||
RKE 模板参考提供了实现 Kubernetes 强化安装所需的配置。RKE 模板用于配置 Kubernetes 和定义 Rancher 设置。如需了解安装以及 RKE 模板的详细信息，请参阅 Rancher [文档](../../../pages-for-subheaders/installation-and-upgrade.md)。
|
||||
|
||||
```yaml
|
||||
#
|
||||
# Cluster Config
|
||||
#
|
||||
default_pod_security_policy_template_id: restricted-noroot
|
||||
docker_root_dir: /var/lib/docker
|
||||
enable_cluster_alerting: false
|
||||
enable_cluster_monitoring: false
|
||||
enable_network_policy: true
|
||||
local_cluster_auth_endpoint:
|
||||
enabled: true
|
||||
name: ''
|
||||
#
|
||||
# Rancher Config
|
||||
#
|
||||
rancher_kubernetes_engine_config:
|
||||
addon_job_timeout: 45
|
||||
authentication:
|
||||
strategy: x509
|
||||
dns:
|
||||
nodelocal:
|
||||
ip_address: ''
|
||||
node_selector: null
|
||||
update_strategy: {}
|
||||
enable_cri_dockerd: false
|
||||
ignore_docker_version: true
|
||||
#
|
||||
# # 目前仅支持 Nginx ingress provider
|
||||
# # 要禁用 Ingress controller，设置 `provider: none`
|
||||
# # 要在指定节点上禁用 Ingress，使用 node_selector，例如：
|
||||
# provider: nginx
|
||||
# node_selector:
|
||||
# app: ingress
|
||||
#
|
||||
ingress:
|
||||
default_backend: false
|
||||
default_ingress_class: true
|
||||
http_port: 0
|
||||
https_port: 0
|
||||
provider: nginx
|
||||
kubernetes_version: v1.21.8-rancher1-1
|
||||
monitoring:
|
||||
provider: metrics-server
|
||||
replicas: 1
|
||||
#
|
||||
# 如果你在 AWS 使用 Calico
|
||||
#
|
||||
# network:
|
||||
# plugin: calico
|
||||
# calico_network_provider:
|
||||
# cloud_provider: aws
|
||||
#
|
||||
# # 要指定 Flannel 接口
|
||||
#
|
||||
# network:
|
||||
# plugin: flannel
|
||||
# flannel_network_provider:
|
||||
# iface: eth1
|
||||
#
|
||||
# # 要为 Canal 插件指定 Flannel 接口
|
||||
#
|
||||
# network:
|
||||
# plugin: canal
|
||||
# canal_network_provider:
|
||||
# iface: eth1
|
||||
#
|
||||
network:
|
||||
mtu: 0
|
||||
options:
|
||||
flannel_backend_type: vxlan
|
||||
plugin: canal
|
||||
rotate_encryption_key: false
|
||||
#
|
||||
# services:
|
||||
# kube-api:
|
||||
# service_cluster_ip_range: 10.43.0.0/16
|
||||
# kube-controller:
|
||||
# cluster_cidr: 10.42.0.0/16
|
||||
# service_cluster_ip_range: 10.43.0.0/16
|
||||
# kubelet:
|
||||
# cluster_domain: cluster.local
|
||||
# cluster_dns_server: 10.43.0.10
|
||||
#
|
||||
services:
|
||||
scheduler:
|
||||
extra_args:
|
||||
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
|
||||
bind-address: 127.0.0.1
|
||||
etcd:
|
||||
backup_config:
|
||||
enabled: true
|
||||
interval_hours: 12
|
||||
retention: 6
|
||||
safe_timestamp: false
|
||||
timeout: 300
|
||||
creation: 12h
|
||||
extra_args:
|
||||
election-timeout: 5000
|
||||
heartbeat-interval: 500
|
||||
retention: 72h
|
||||
snapshot: false
|
||||
uid: 52034
|
||||
gid: 52034
|
||||
kube_api:
|
||||
always_pull_images: false
|
||||
audit_log:
|
||||
enabled: true
|
||||
event_rate_limit:
|
||||
enabled: true
|
||||
pod_security_policy: true
|
||||
secrets_encryption_config:
|
||||
enabled: true
|
||||
service_node_port_range: 30000-32767
|
||||
kube-controller:
|
||||
extra_args:
|
||||
feature-gates: RotateKubeletServerCertificate=true
|
||||
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
|
||||
bind-address: 127.0.0.1
|
||||
kubelet:
|
||||
extra_args:
|
||||
feature-gates: RotateKubeletServerCertificate=true
|
||||
protect-kernel-defaults: true
|
||||
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
|
||||
fail_swap_on: false
|
||||
generate_serving_certificate: true
|
||||
ssh_agent_auth: false
|
||||
upgrade_strategy:
|
||||
max_unavailable_controlplane: '1'
|
||||
max_unavailable_worker: 10%
|
||||
windows_prefered_cluster: false
|
||||
```
|
||||
|
||||
### 强化 `cloud-config` 配置参考
|
||||
|
||||
**cloud-config** 配置文件通常用于云基础设施环境中，能让你管理计算实例的配置。此参考 config 配置了安装 Kubernetes 之前所需的 SUSE Linux Enterprise Server (SLES)、openSUSE Leap、Red Hat Enterprise Linux (RHEL) 和 Ubuntu 操作系统级别的设置。
|
||||
|
||||
#### 针对 SUSE Linux Enterprise Server 15 (SLES 15) 和 openSUSE Leap 15 的强化 **cloud-config** 参考
|
||||
|
||||
```yaml
|
||||
#cloud-config
|
||||
system_info:
|
||||
default_user:
|
||||
groups:
|
||||
- docker
|
||||
write_files:
|
||||
- path: "/etc/sysctl.d/90-kubelet.conf"
|
||||
owner: root:root
|
||||
permissions: '0644'
|
||||
content: |
|
||||
vm.overcommit_memory=1
|
||||
vm.panic_on_oom=0
|
||||
kernel.panic=10
|
||||
kernel.panic_on_oops=1
|
||||
kernel.keys.root_maxbytes=25000000
|
||||
package_update: true
|
||||
ssh_pwauth: false
|
||||
runcmd:
|
||||
# Docker 应该已在 SLES 15 SP3 中安装
|
||||
- zypper install docker containerd
|
||||
- systemctl daemon-reload
|
||||
- systemctl enable docker.service
|
||||
- systemctl start --no-block docker.service
|
||||
- sysctl -p /etc/sysctl.d/90-kubelet.conf
|
||||
- groupadd --gid 52034 etcd
|
||||
- useradd --comment "etcd service account" --uid 52034 --gid 52034 etcd --shell /usr/sbin/nologin
|
||||
```
|
||||
|
||||
#### 针对 Red Hat Enterprise Linux 8 (RHEL 8) 和 Ubuntu 20.04 LTS 的强化 **cloud-config** 参考
|
||||
|
||||
```yaml
|
||||
#cloud-config
|
||||
system_info:
|
||||
default_user:
|
||||
groups:
|
||||
- docker
|
||||
write_files:
|
||||
- path: "/etc/sysctl.d/90-kubelet.conf"
|
||||
owner: root:root
|
||||
permissions: '0644'
|
||||
content: |
|
||||
vm.overcommit_memory=1
|
||||
vm.panic_on_oom=0
|
||||
kernel.panic=10
|
||||
kernel.panic_on_oops=1
|
||||
kernel.keys.root_maxbytes=25000000
|
||||
package_update: true
|
||||
ssh_pwauth: false
|
||||
runcmd:
|
||||
# 使用 Rancher 的 Docker 安装脚本来安装 Docker - github.com/rancher/install-docker
|
||||
- curl https://releases.rancher.com/install-docker/20.10.sh | sh
|
||||
- sysctl -p /etc/sysctl.d/90-kubelet.conf
|
||||
- groupadd --gid 52034 etcd
|
||||
- useradd --comment "etcd service account" --uid 52034 --gid 52034 etcd --shell /usr/sbin/nologin
|
||||
```
|
||||
-2953
File diff suppressed because it is too large
Load Diff
-409
@@ -1,409 +0,0 @@
|
||||
---
|
||||
title: 使用 CIS 1.6 Benchmark 的 RKE2 强化指南
|
||||
---
|
||||
|
||||
本文档提供了用于强化 RKE2 集群（使用 Rancher 2.6.5 进行配置）生产安装的说明。此处概述了遵循 CIS 的 Kubernetes Benchmark 管控所需的配置和控制。
|
||||
|
||||
:::note
|
||||
|
||||
本强化指南介绍了如何保护集群中的节点。建议你在安装 Kubernetes 之前参考本指南。
|
||||
|
||||
:::
|
||||
|
||||
本强化指南适用于 RKE2 集群，并对应以下 CIS Kubernetes Benchmark、Kubernetes 和 Rancher 版本：
|
||||
|
||||
| Rancher 版本 | CIS Benchmark 版本 | Kubernetes 版本 |
|
||||
| --------------- | --------------------- | ------------------ |
|
||||
| Rancher v2.6.5+ | Benchmark v1.6 | Kubernetes v1.21 到 v1.23 |
|
||||
|
||||
[点击此处下载本文档的 PDF 版本](https://releases.rancher.com/documents/security/2.6/Rancher_RKE2_v2-6_CIS_v1-6_Hardening_Guide.pdf)。
|
||||
|
||||
|
||||
### 概述
|
||||
|
||||
本文档提供了强化使用了 Rancher 2.6.5+ 和 Kubernetes 1.21 到 1.23 版本的 RKE2 集群的说明。此处概述了遵循 CIS 的 Kubernetes Benchmark 管控所需的配置。
|
||||
|
||||
有关根据官方 CIS Benchmark 评估强化 RKE2 集群的更多详细信息，请参阅 [RKE2 - CIS 1.6 Benchmark - 自我评估指南 - Rancher 2.6](rke2-self-assessment-guide-with-cis-v1.6-benchmark.md)。
|
||||
|
||||
RKE2 是“默认强化”的，因此无需进行修改即可通过大部分 Kubernetes CIS 管控。但是也有一些例外情况是需要人工干预才能完全通过 CIS Benchmark：
|
||||
|
||||
1. RKE2 不会修改主机操作系统。因此，操作人员必须进行一些主机级别的修改。
|
||||
2. `PodSecurityPolicies` 和 `NetworkPolicies` 的某些 CIS 策略会限制集群功能。你必须让 RKE2 开箱即用地配置它们。
|
||||
|
||||
要满足上述要求，你可以在 `profile` 标志设置为 `cis-1.6` 的情况下启动 RKE2。该标志通常执行以下两个操作：
|
||||
|
||||
1. 检查是否满足主机级别的要求。如果没有，RKE2 将退出并显示未满足要求的致命错误描述。
|
||||
2. 配置能让集群通过相关管控的运行时 pod 安全策略和网络策略。
|
||||
|
||||
:::note
|
||||
|
||||
配置文件标志的有效值是 `cis-1.5` 或 `cis-1.6`。它接受一个字符串值以允许以后使用其他配置文件。
|
||||
|
||||
:::
|
||||
|
||||
以下概述了当 `profile` 标志设置为 `cis-1.6` 时采取的具体操作。
|
||||
|
||||
### 主机级别要求
|
||||
|
||||
主机级别的要求有两个方面，分别是内核参数和 etcd 进程/目录配置。本节会概述这些内容。
|
||||
|
||||
#### 确保设置了 `protect-kernel-defaults`
|
||||
|
||||
这是一个 kubelet 标志，如果所需的内核参数未设置或设置为与 kubelet 默认值不同的值，它会导致 kubelet 退出。
|
||||
|
||||
如果设置了 `profile` 标志，RKE2 会将标志设置为 `true`。
|
||||
|
||||
:::caution
|
||||
|
||||
`protect-kernel-defaults` 作为 RKE2 的配置标志公开。如果你已将 `profile` 设置为 `cis-1.x` 并将 `protect-kernel-defaults` 设置为 `false`，则 RKE2 将退出并提示错误。
|
||||
|
||||
:::
|
||||
|
||||
RKE2 还将检查与 kubelet 相同的内核参数，并按照 kubelet 相同的规则退出并提示错误。这样，操作人员可以更快、更轻松地识别出与 kubelet 默认值不一致的内核参数。
|
||||
|
||||
`protect-kernel-defaults` 和 `profile` 标志都可以在 RKE2 模板配置文件中设置。
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
rkeConfig:
|
||||
machineSelectorConfig:
|
||||
- config:
|
||||
profile: cis-1.6
|
||||
protect-kernel-defaults: true
|
||||
```
|
||||
|
||||
#### 确保 etcd 配置正确
|
||||
|
||||
CIS Benchmark 要求 etcd 数据目录由 `etcd` 用户和组拥有。换言之，它要求 etcd 进程由主机级别的 `etcd` 用户运行。为了实现这一点，RKE2 在使用有效的 `cis-1.x` 配置文件启动时采取了几个步骤：
|
||||
|
||||
1. 检查主机上是否存在 `etcd` 用户和组。如果没有，则退出并提示错误。
|
||||
2. 以 `etcd` 作为用户和组所有者来创建 etcd 的数据目录。
|
||||
3. 正确设置 etcd 静态 pod 的 `SecurityContext`，从而确保 etcd 进程以 `etcd` 用户和组的身份运行。
|
||||
|
||||
### 设置主机
|
||||
|
||||
本节提供了满足上述要求所需的主机配置命令。
|
||||
|
||||
#### 设置内核参数
|
||||
|
||||
建议为集群中所有类型的节点使用以下 `sysctl` 配置。在 `/etc/sysctl.d/90-kubelet.conf` 中设置如下参数：
|
||||
|
||||
```ini
|
||||
vm.panic_on_oom=0
|
||||
vm.overcommit_memory=1
|
||||
kernel.panic=10
|
||||
kernel.panic_on_oops=1
|
||||
```
|
||||
|
||||
运行 `sudo sysctl -p /etc/sysctl.d/90-kubelet.conf` 以启用设置。
|
||||
|
||||
在通过 Rancher 实际部署 RKE2 之前，请仅在全新安装上执行此步骤。
|
||||
|
||||
#### 创建 etcd 用户
|
||||
|
||||
在某些 Linux 发行版上，`useradd` 命令不会创建组。以下命令使用了 `-U` 标志来解决这一问题。这个标志能让 `useradd` 创建一个与用户同名的组。
|
||||
|
||||
```bash
|
||||
sudo useradd -r -c "etcd user" -s /sbin/nologin -M etcd -U
|
||||
```
|
||||
|
||||
### Kubernetes 运行时要求
|
||||
|
||||
如果运行时要通过 CIS Benchmark，则需要重视 pod 安全和网络策略。本节会概述这些内容。
|
||||
|
||||
#### `PodSecurityPolicies`
|
||||
|
||||
RKE2 总是在 `PodSecurityPolicy` 准入控制器打开的情况下运行。但是，当它**不是**使用有效的 `cis-1.x` 配置文件启动时，RKE2 将设置一个不受限制的策略，该策略允许 Kubernetes 像 `PodSecurityPolicy` 准入控制器未启用一样运行。
|
||||
|
||||
使用有效的 `cis-1.x` 配置文件运行时，RKE2 将设置一组更具限制性的策略。这些策略符合 CIS Benchmark 5.2 节中的要求。
|
||||
|
||||
> Kubernetes controlplane 组件和关键附加组件（例如 CNI、DNS 和 Ingress）在 `kube-system` 命名空间中作为 pod 运行。因此，此命名空间的策略限制会更低，以便这些组件可以正常运行。
|
||||
|
||||
#### `NetworkPolicies`
|
||||
|
||||
使用有效的 `cis-1.x` 配置文件运行时，RKE2 将设置 `NetworkPolicies` 以通过 Kubernetes 内置命名空间的 CIS Benchmark。这些命名空间是分别是 `kube-system`、`kube-public`、`kube-node-lease` 和 `default`。
|
||||
|
||||
使用的 `NetworkPolicy` 只允许同一命名空间内的 Pod 相互通信。一个例外情况是它允许解析 DNS 请求。
|
||||
|
||||
:::note
|
||||
|
||||
操作人员需要照常管理其他命名空间的网络策略。
|
||||
|
||||
:::
|
||||
#### 配置 `default` ServiceAccount
|
||||
|
||||
**将 `default` ServiceAccount 的 `automountServiceAccountToken` 设置为 `false`**
|
||||
|
||||
Kubernetes 为集群工作负载提供了一个 `default` ServiceAccount，但没有为 pod 分配特定 ServiceAccount 。如果需要从 pod 访问 Kubernetes API，则需要为该 pod 创建一个特定的 ServiceAccount 并授予权限。你还需要配置 `default` ServiceAccount，使其不提供 ServiceAccount 令牌并且没有任何显式的权限分配。
|
||||
|
||||
对于标准 RKE2 中的每个命名空间（包括 `default` 和 `kube-system`），`default` ServiceAccount 必须包含以下值：
|
||||
|
||||
```yaml
|
||||
automountServiceAccountToken: false
|
||||
```
|
||||
|
||||
对于集群操作人员创建的命名空间，你可以使用以下脚本和配置文件来配置 `default` ServiceAccount。
|
||||
|
||||
请将下面的配置保存到名为 `account_update.yaml` 的文件中：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: default
|
||||
automountServiceAccountToken: false
|
||||
```
|
||||
|
||||
创建一个名为 `account_update.sh` 的 bash 脚本文件。确保为脚本设置了 `sudo chmod +x account_update.sh`，使脚本具有执行权限：
|
||||
|
||||
```bash
|
||||
#!/bin/bash -e
|
||||
|
||||
for namespace in $(kubectl get namespaces -A -o=jsonpath="{.items[*]['metadata.name']}"); do
|
||||
echo -n "Patching namespace $namespace - "
|
||||
kubectl patch serviceaccount default -n ${namespace} -p "$(cat account_update.yaml)"
|
||||
done
|
||||
```
|
||||
|
||||
执行此脚本，将 `account_update.yaml` 配置应用到所有命名空间中的 `default` ServiceAccount。
|
||||
|
||||
### API Server 审计配置
|
||||
|
||||
CIS 1.2.22 到 1.2.25 要求为 API Server 配置审计日志。如果 RKE2 在 `profile` 标志设置为 `cis-1.6` 的情况下启动，它会自动在 API Server 中配置强化的 `--audit-log-` 参数来通过这些 CIS 检查。
|
||||
|
||||
RKE2 的默认审计策略不会在 API Server 中记录请求。这样，集群操作人员就能灵活地定制符合其审计要求和需求的审计策略，从而满足不同用户的不同环境和策略需求。
|
||||
|
||||
如果启动时 `profile` 标志设置为 `cis-1.6`，RKE2 会创建默认审计策略。该策略在 `/etc/rancher/rke2/audit-policy.yaml` 中定义。
|
||||
|
||||
```yaml
|
||||
apiVersion: audit.k8s.io/v1
|
||||
kind: Policy
|
||||
metadata:
|
||||
creationTimestamp: null
|
||||
rules:
|
||||
- level: None
|
||||
```
|
||||
|
||||
要开始记录对 API Server 的请求，你至少必须修改 `level` 参数，例如将其修改为 `Metadata`。有关 API Server 策略配置的详细信息，请参阅 [Kubernetes 文档](https://kubernetes.io/docs/tasks/debug-application-cluster/audit/)。
|
||||
|
||||
调整审计策略后，RKE2 必须重新启动才能加载新配置。
|
||||
|
||||
```shell
|
||||
sudo systemctl restart rke2-server.service
|
||||
```
|
||||
|
||||
API Server 审计日志将写入 `/var/lib/rancher/rke2/server/logs/audit.log`。
|
||||
|
||||
### 已知问题
|
||||
|
||||
以下是 RKE2 目前没有通过的管控。此处将解释各个差距，以及这些差距是否可以通过手动干预或在未来的版本中解决。
|
||||
|
||||
#### 管控 1.1.12
|
||||
确保 etcd 数据目录所有权设置为 `etcd:etcd`
|
||||
|
||||
**原因**
|
||||
etcd 是 Kubernetes deployment 使用的高可用键值存储，用于持久存储其所有 REST API 对象。你需要保护此数据目录，避免任何未经授权的读取或写入。它的所有者应该是 `etcd:etcd`。
|
||||
|
||||
**修正措施**
|
||||
创建如上所述的 `etcd` 用户和组。
|
||||
|
||||
#### 管控 5.1.5
|
||||
确保未主动使用默认 ServiceAccount
|
||||
|
||||
**原因**：Kubernetes 为集群工作负载提供了一个 `default` ServiceAccount，但没有为 pod 分配特定 ServiceAccount 。
|
||||
|
||||
如果需要从 pod 访问 Kubernetes API，则需要为该 pod 创建一个特定的 ServiceAccount 并授予权限。
|
||||
|
||||
你还需要配置 `default` ServiceAccount，使其不提供 ServiceAccount 令牌并且没有任何显式的权限分配。
|
||||
|
||||
可以通过将每个命名空间中 `default` ServiceAccount 的 `automountServiceAccountToken` 字段更新为 `false` 来解决此问题。
|
||||
|
||||
**修正措施**
|
||||
手动更新集群中服务账户上的此字段。
|
||||
|
||||
#### 管控 5.3.2
|
||||
确保所有命名空间都定义了网络策略
|
||||
|
||||
**原因**
|
||||
如果你在同一个 Kubernetes 集群上运行不同的应用程序，被感染的应用程序可能会攻击相邻的应用程序。要确保容器只进行所需的通信，网络分段非常重要。网络策略指的是如何允许 Pod 与其他 Pod 以及与其他网络端点进行通信。
|
||||
|
||||
网络策略是命名空间范围的。为某个命名空间配置网络策略后，该策略不允许的所有其他流量都会被拒绝。但是，如果命名空间没有配置网络策略，则所有流量都会允许进出该命名空间中的 Pod。
|
||||
|
||||
**修正措施**
|
||||
在 RKE2 模板配置文件中设置 `profile: "cis-1.6"`。你可以在下方找到示例。
|
||||
|
||||
### 强化 RKE2 模板配置参考
|
||||
|
||||
模板配置参考可用于在 Rancher 中创建强化的 RKE2 自定义集群。此参考不包括其他必需的**集群配置**参数，该参数会因你的环境而异。
|
||||
|
||||
```yaml
|
||||
apiVersion: provisioning.cattle.io/v1
|
||||
kind: Cluster
|
||||
metadata:
|
||||
name: <replace_with_cluster_name>
|
||||
annotations:
|
||||
{}
|
||||
# key: string
|
||||
labels:
|
||||
{}
|
||||
# key: string
|
||||
namespace: fleet-default
|
||||
spec:
|
||||
defaultPodSecurityPolicyTemplateName: ''
|
||||
kubernetesVersion: <replace_with_kubernetes_version>
|
||||
localClusterAuthEndpoint:
|
||||
caCerts: ''
|
||||
enabled: false
|
||||
fqdn: ''
|
||||
rkeConfig:
|
||||
chartValues:
|
||||
rke2-canal:
|
||||
{}
|
||||
etcd:
|
||||
disableSnapshots: false
|
||||
s3:
|
||||
# bucket: string
|
||||
# cloudCredentialName: string
|
||||
# endpoint: string
|
||||
# endpointCA: string
|
||||
# folder: string
|
||||
# region: string
|
||||
# skipSSLVerify: boolean
|
||||
snapshotRetention: 5
|
||||
snapshotScheduleCron: 0 */5 * * *
|
||||
machineGlobalConfig:
|
||||
cni: canal
|
||||
machinePools:
|
||||
# - cloudCredentialSecretName: string
|
||||
# controlPlaneRole: boolean
|
||||
# displayName: string
|
||||
# drainBeforeDelete: boolean
|
||||
# etcdRole: boolean
|
||||
# labels:
|
||||
# key: string
|
||||
# machineConfigRef:
|
||||
# apiVersion: string
|
||||
# fieldPath: string
|
||||
# kind: string
|
||||
# name: string
|
||||
# namespace: string
|
||||
# resourceVersion: string
|
||||
# uid: string
|
||||
# machineDeploymentAnnotations:
|
||||
# key: string
|
||||
# machineDeploymentLabels:
|
||||
# key: string
|
||||
# machineOS: string
|
||||
# maxUnhealthy: string
|
||||
# name: string
|
||||
# nodeStartupTimeout: string
|
||||
# paused: boolean
|
||||
# quantity: int
|
||||
# rollingUpdate:
|
||||
# maxSurge: string
|
||||
# maxUnavailable: string
|
||||
# taints:
|
||||
# - effect: string
|
||||
# key: string
|
||||
# timeAdded: string
|
||||
# value: string
|
||||
# unhealthyNodeTimeout: string
|
||||
# unhealthyRange: string
|
||||
# workerRole: boolean
|
||||
machineSelectorConfig:
|
||||
- config:
|
||||
profile: cis-1.6
|
||||
protect-kernel-defaults: true
|
||||
# - config:
|
||||
#
|
||||
# machineLabelSelector:
|
||||
# matchExpressions:
|
||||
# - key: string
|
||||
# operator: string
|
||||
# values:
|
||||
# - string
|
||||
# matchLabels:
|
||||
# key: string
|
||||
registries:
|
||||
configs:
|
||||
{}
|
||||
#authConfigSecretName: string
|
||||
# caBundle: string
|
||||
# insecureSkipVerify: boolean
|
||||
# tlsSecretName: string
|
||||
mirrors:
|
||||
{}
|
||||
#endpoint:
|
||||
# - string
|
||||
# rewrite:
|
||||
# key: string
|
||||
upgradeStrategy:
|
||||
controlPlaneConcurrency: 10%
|
||||
controlPlaneDrainOptions:
|
||||
# deleteEmptyDirData: boolean
|
||||
# disableEviction: boolean
|
||||
# enabled: boolean
|
||||
# force: boolean
|
||||
# gracePeriod: int
|
||||
# ignoreDaemonSets: boolean
|
||||
# ignoreErrors: boolean
|
||||
# postDrainHooks:
|
||||
# - annotation: string
|
||||
# preDrainHooks:
|
||||
# - annotation: string
|
||||
# skipWaitForDeleteTimeoutSeconds: int
|
||||
# timeout: int
|
||||
workerConcurrency: 10%
|
||||
workerDrainOptions:
|
||||
# deleteEmptyDirData: boolean
|
||||
# disableEviction: boolean
|
||||
# enabled: boolean
|
||||
# force: boolean
|
||||
# gracePeriod: int
|
||||
# ignoreDaemonSets: boolean
|
||||
# ignoreErrors: boolean
|
||||
# postDrainHooks:
|
||||
# - annotation: string
|
||||
# preDrainHooks:
|
||||
# - annotation: string
|
||||
# skipWaitForDeleteTimeoutSeconds: int
|
||||
# timeout: int
|
||||
# additionalManifest: string
|
||||
# etcdSnapshotCreate:
|
||||
# generation: int
|
||||
# etcdSnapshotRestore:
|
||||
# generation: int
|
||||
# name: string
|
||||
# restoreRKEConfig: string
|
||||
# infrastructureRef:
|
||||
# apiVersion: string
|
||||
# fieldPath: string
|
||||
# kind: string
|
||||
# name: string
|
||||
# namespace: string
|
||||
# resourceVersion: string
|
||||
# uid: string
|
||||
# provisionGeneration: int
|
||||
# rotateCertificates:
|
||||
# generation: int
|
||||
# services:
|
||||
# - string
|
||||
# rotateEncryptionKeys:
|
||||
# generation: int
|
||||
machineSelectorConfig:
|
||||
- config: {}
|
||||
# agentEnvVars:
|
||||
# - name: string
|
||||
# value: string
|
||||
# cloudCredentialSecretName: string
|
||||
# clusterAPIConfig:
|
||||
# clusterName: string
|
||||
# defaultClusterRoleForProjectMembers: string
|
||||
# enableNetworkPolicy: boolean
|
||||
# redeploySystemAgentGeneration: int
|
||||
__clone: true
|
||||
```
|
||||
|
||||
### 结论
|
||||
|
||||
如果你遵循本指南，Rancher 配置的 RKE2 自定义集群将能通过 CIS Kubernetes Benchmark。如需了解我们验证 Benchmark 的方式，以及你如何在集群上执行相同的操作，请参阅 Rancher 的 [RKE2 CIS Benchmark 自我评估指南 1.6](rke2-self-assessment-guide-with-cis-v1.6-benchmark.md)。
|
||||
-3164
File diff suppressed because it is too large
Load Diff
-549
@@ -1,549 +0,0 @@
|
||||
---
|
||||
title: K3s Hardening Guide with CIS Benchmark
|
||||
---
|
||||
|
||||
This document provides prescriptive guidance for hardening a production installation of a K3s cluster to be provisioned with Rancher v2.7. It outlines the configurations and controls required to address Kubernetes benchmark controls from the Center for Information Security (CIS).
|
||||
|
||||
:::note
|
||||
|
||||
This hardening guide describes how to secure the nodes in your cluster, and it is recommended to follow this guide before installing Kubernetes.
|
||||
|
||||
:::
|
||||
|
||||
This hardening guide is intended to be used for K3s clusters and associated with specific versions of the CIS Kubernetes Benchmark, Kubernetes, and Rancher:
|
||||
|
||||
| Rancher Version | CIS Benchmark Version | Kubernetes Version |
|
||||
| --------------- | --------------------- | ------------------ |
|
||||
| Rancher v2.7 | Benchmark v1.20 | Kubernetes v1.21 |
|
||||
| Rancher v2.7 | Benchmark v1.23 | Kubernetes v1.22 up to v1.24 |
|
||||
|
||||
### Overview
|
||||
|
||||
For more details about evaluating a hardened K3s cluster against the official CIS benchmark, refer to K3s - CIS Benchmark - Self-Assessment Guide - Rancher v2.7 for [CIS v1.20](k3s-self-assessment-guide-with-cis-v1.20-benchmark.md) and [CIS v1.23](k3s-self-assessment-guide-with-cis-v1.23-benchmark.md).
|
||||
|
||||
K3s has a number of security mitigations applied and turned on by default and will pass a number of the Kubernetes CIS controls without modification. There are some notable exceptions to this that require manual intervention to fully comply with the CIS Benchmark:
|
||||
|
||||
1. K3s will not modify the host operating system. Any host-level modifications will need to be done manually.
|
||||
2. Certain CIS policy controls for `PodSecurityPolicies` and `NetworkPolicies` will restrict the functionality of the cluster. You must opt into having K3s configure these by adding the appropriate options (enabling of admission plugins) to your command-line flags or configuration file as well as manually applying appropriate policies. Further details are presented in the sections below.
|
||||
|
||||
The first section (1.1) of the CIS Benchmark concerns itself primarily with pod manifest permissions and ownership. K3s doesn't utilize these for the core components since everything is packaged into a single binary.
|
||||
|
||||
## Host-level Requirements
|
||||
|
||||
### Ensure `protect-kernel-defaults` is set (control 4.2.6)
|
||||
|
||||
This is a kubelet flag that will cause the kubelet to exit if the required kernel parameters are unset or are set to values that are different from the kubelet's defaults.
|
||||
|
||||
This can be remediated by adding the following argument line to K3s cluster configuration file:
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
rkeConfig:
|
||||
machineSelectorConfig:
|
||||
- config:
|
||||
protect-kernel-defaults: true # Control 4.2.6
|
||||
```
|
||||
|
||||
#### Set kernel parameters
|
||||
|
||||
Create a file called `/etc/sysctl.d/90-kubelet.conf` and add the snippet below. Then run `sysctl -p /etc/sysctl.d/90-kubelet.conf`.
|
||||
|
||||
```bash
|
||||
vm.panic_on_oom=0
|
||||
vm.overcommit_memory=1
|
||||
kernel.panic=10
|
||||
kernel.panic_on_oops=1
|
||||
```
|
||||
|
||||
This configuration needs to be done before setting the kubelet flag, otherwise K3s will fail to start.
|
||||
|
||||
## Kubernetes Runtime Requirements
|
||||
|
||||
The runtime requirements to comply with the CIS Benchmark are centered around pod security policies (PSPs) and its admission control plugin, network policies and API Server auditing logs. These are outlined in this section. K3s doesn't apply any default PSPs or network policies. However, K3s ships with a controller that is meant to apply a given set of network policies. By default, K3s runs with the `NodeRestriction` admission controller. To enable PSPs, add the following line to K3s cluster configuration file:
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
rkeConfig:
|
||||
machineGlobalConfig:
|
||||
kube-apiserver-arg:
|
||||
- enable-admission-plugins=NodeRestriction,PodSecurityPolicy # CIS 1.2.16 and CIS 5.2
|
||||
```
|
||||
|
||||
This will have the effect of maintaining the `NodeRestriction` plugin as well as enabling the `PodSecurityPolicy`.
|
||||
|
||||
### Pod Security Policies (control 5.2)
|
||||
|
||||
When PSPs are enabled, a policy can be applied to satisfy the necessary controls described in section 5.2 of the CIS Benchmark.
|
||||
|
||||
Here is an example of a compliant PSP.
|
||||
|
||||
```yaml
|
||||
apiVersion: policy/v1beta1
|
||||
kind: PodSecurityPolicy
|
||||
metadata:
|
||||
name: restricted-psp
|
||||
spec:
|
||||
privileged: false # CIS - 5.2.1
|
||||
allowPrivilegeEscalation: false # CIS - 5.2.5
|
||||
requiredDropCapabilities: # CIS - 5.2.7/8/9
|
||||
- ALL
|
||||
volumes:
|
||||
- 'configMap'
|
||||
- 'emptyDir'
|
||||
- 'projected'
|
||||
- 'secret'
|
||||
- 'downwardAPI'
|
||||
- 'csi'
|
||||
- 'persistentVolumeClaim'
|
||||
- 'ephemeral'
|
||||
hostNetwork: false # CIS - 5.2.4
|
||||
hostIPC: false # CIS - 5.2.3
|
||||
hostPID: false # CIS - 5.2.2
|
||||
runAsUser:
|
||||
rule: 'MustRunAsNonRoot' # CIS - 5.2.6
|
||||
seLinux:
|
||||
rule: 'RunAsAny'
|
||||
supplementalGroups:
|
||||
rule: 'MustRunAs'
|
||||
ranges:
|
||||
- min: 1
|
||||
max: 65535
|
||||
fsGroup:
|
||||
rule: 'MustRunAs'
|
||||
ranges:
|
||||
- min: 1
|
||||
max: 65535
|
||||
readOnlyRootFilesystem: false
|
||||
```
|
||||
|
||||
For the above PSP to be effective, we need to create a `ClusterRole` and a `ClusterRoleBinding`. We also need to include a "system unrestricted policy" which is needed for system-level pods that require additional privileges, as exemplified below.
|
||||
|
||||
```yaml
|
||||
apiVersion: policy/v1beta1
|
||||
kind: PodSecurityPolicy
|
||||
metadata:
|
||||
name: restricted-psp
|
||||
spec:
|
||||
privileged: false
|
||||
allowPrivilegeEscalation: false
|
||||
requiredDropCapabilities:
|
||||
- ALL
|
||||
volumes:
|
||||
- 'configMap'
|
||||
- 'emptyDir'
|
||||
- 'projected'
|
||||
- 'secret'
|
||||
- 'downwardAPI'
|
||||
- 'csi'
|
||||
- 'persistentVolumeClaim'
|
||||
- 'ephemeral'
|
||||
hostNetwork: false
|
||||
hostIPC: false
|
||||
hostPID: false
|
||||
runAsUser:
|
||||
rule: 'MustRunAsNonRoot'
|
||||
seLinux:
|
||||
rule: 'RunAsAny'
|
||||
supplementalGroups:
|
||||
rule: 'MustRunAs'
|
||||
ranges:
|
||||
- min: 1
|
||||
max: 65535
|
||||
fsGroup:
|
||||
rule: 'MustRunAs'
|
||||
ranges:
|
||||
- min: 1
|
||||
max: 65535
|
||||
readOnlyRootFilesystem: false
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: psp:restricted-psp
|
||||
labels:
|
||||
addonmanager.kubernetes.io/mode: EnsureExists
|
||||
rules:
|
||||
- apiGroups: ['extensions']
|
||||
resources: ['podsecuritypolicies']
|
||||
verbs: ['use']
|
||||
resourceNames:
|
||||
- restricted-psp
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRoleBinding
|
||||
metadata:
|
||||
name: default:restricted-psp
|
||||
labels:
|
||||
addonmanager.kubernetes.io/mode: EnsureExists
|
||||
roleRef:
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
kind: ClusterRole
|
||||
name: psp:restricted-psp
|
||||
subjects:
|
||||
- kind: Group
|
||||
name: system:authenticated
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
---
|
||||
apiVersion: policy/v1beta1
|
||||
kind: PodSecurityPolicy
|
||||
metadata:
|
||||
name: system-unrestricted-psp
|
||||
spec:
|
||||
allowPrivilegeEscalation: true
|
||||
allowedCapabilities:
|
||||
- '*'
|
||||
fsGroup:
|
||||
rule: RunAsAny
|
||||
hostIPC: true
|
||||
hostNetwork: true
|
||||
hostPID: true
|
||||
hostPorts:
|
||||
- max: 65535
|
||||
min: 0
|
||||
privileged: true
|
||||
runAsUser:
|
||||
rule: RunAsAny
|
||||
seLinux:
|
||||
rule: RunAsAny
|
||||
supplementalGroups:
|
||||
rule: RunAsAny
|
||||
volumes:
|
||||
- '*'
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRoleBinding
|
||||
metadata:
|
||||
name: system-unrestricted-node-psp-rolebinding
|
||||
roleRef:
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
kind: ClusterRole
|
||||
name: system-unrestricted-psp-role
|
||||
subjects:
|
||||
- apiGroup: rbac.authorization.k8s.io
|
||||
kind: Group
|
||||
name: system:nodes
|
||||
---
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: system-unrestricted-psp-role
|
||||
rules:
|
||||
- apiGroups:
|
||||
- policy
|
||||
resourceNames:
|
||||
- system-unrestricted-psp
|
||||
resources:
|
||||
- podsecuritypolicies
|
||||
verbs:
|
||||
- use
|
||||
```
|
||||
|
||||
The policy file `policy.yaml` can be placed in the `/var/lib/rancher/k3s/server/manifests` directory. Both the policy file and the its directory hierarchy, ideally, must be created before starting K3s. A restrictive access permission is recommended to avoid leaking potential sensitive information.
|
||||
|
||||
```bash
|
||||
sudo mkdir -p -m 700 /var/lib/rancher/k3s/server/manifests
|
||||
```
|
||||
|
||||
### Network Policies (control 5.3.2)
|
||||
|
||||
CIS requires that all namespaces have a network policy applied that reasonably limits traffic into namespaces and pods.
|
||||
|
||||
:::note
|
||||
|
||||
This is a manual check in the CIS Benchmark. The CIS scan will flag the result as `warning`, because manual inspection is necessary by the cluster operator.
|
||||
|
||||
:::
|
||||
|
||||
Here is an example of a compliant network policy.
|
||||
|
||||
```yaml
|
||||
kind: NetworkPolicy
|
||||
apiVersion: networking.k8s.io/v1
|
||||
metadata:
|
||||
name: intra-namespace
|
||||
namespace: kube-system
|
||||
spec:
|
||||
podSelector: {}
|
||||
ingress:
|
||||
- from:
|
||||
- namespaceSelector:
|
||||
matchLabels:
|
||||
name: kube-system
|
||||
```
|
||||
|
||||
:::note
|
||||
|
||||
Kubernetes' additions such as CNI, DNS, and Ingress are ran as pods in the `kube-system` namespace. Therefore, this namespace will have a policy that is less restrictive so that these components can run properly.
|
||||
|
||||
:::
|
||||
|
||||
With the applied restrictions, DNS will be blocked unless purposely allowed. Below is a network policy that will allow DNS related traffic.
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: NetworkPolicy
|
||||
metadata:
|
||||
name: default-network-dns-policy
|
||||
namespace: <NAMESPACE>
|
||||
spec:
|
||||
ingress:
|
||||
- ports:
|
||||
- port: 53
|
||||
protocol: TCP
|
||||
- port: 53
|
||||
protocol: UDP
|
||||
podSelector:
|
||||
matchLabels:
|
||||
k8s-app: kube-dns
|
||||
policyTypes:
|
||||
- Ingress
|
||||
```
|
||||
|
||||
The metrics-server and Traefik ingress controller will be blocked by default if network policies are not created to allow access.
|
||||
|
||||
```yaml
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: NetworkPolicy
|
||||
metadata:
|
||||
name: allow-all-metrics-server
|
||||
namespace: kube-system
|
||||
spec:
|
||||
podSelector:
|
||||
matchLabels:
|
||||
k8s-app: metrics-server
|
||||
ingress:
|
||||
- {}
|
||||
policyTypes:
|
||||
- Ingress
|
||||
---
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: NetworkPolicy
|
||||
metadata:
|
||||
name: allow-all-svclbtraefik-ingress
|
||||
namespace: kube-system
|
||||
spec:
|
||||
podSelector:
|
||||
matchLabels:
|
||||
svccontroller.k3s.cattle.io/svcname: traefik
|
||||
ingress:
|
||||
- {}
|
||||
policyTypes:
|
||||
- Ingress
|
||||
```
|
||||
|
||||
:::note
|
||||
|
||||
Operators must manage network policies as normal for additional namespaces that are created.
|
||||
|
||||
:::
|
||||
|
||||
The network policies can be added in the same policy file used for PSPs in `/var/lib/rancher/k3s/server/manifests/policy.yaml` or on its own file.
|
||||
|
||||
### API Server audit configuration
|
||||
|
||||
CIS requirements v1.20 - 1.2.22 to 1.2.25 and v1.23 - 1.2.19 to 1.2.22 are related to configuring audit logs for the API Server. K3s doesn't create by default the log directory and audit policy, as auditing requirements are specific to each user's policies and environment.
|
||||
|
||||
The log directory, ideally, must be created before starting K3s. A restrictive access permission is recommended to avoid leaking potential sensitive information.
|
||||
|
||||
```bash
|
||||
sudo mkdir -p -m 700 /var/lib/rancher/k3s/server/logs
|
||||
```
|
||||
|
||||
A starter audit policy to log request metadata is provided below. The policy should be written to a file named `audit.yaml` in `/var/lib/rancher/k3s/server` directory. Detailed information about policy configuration for the API server can be found in the Kubernetes [documentation](https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/).
|
||||
|
||||
```yaml
|
||||
apiVersion: audit.k8s.io/v1
|
||||
kind: Policy
|
||||
rules:
|
||||
- level: Metadata
|
||||
```
|
||||
|
||||
Further configurations, as described below, are also needed to pass CIS checks and are not configured by default in K3s, because they vary depending on the users' environment and needs:
|
||||
|
||||
- Ensure that the `--audit-log-path` argument is set.
|
||||
- Ensure that the `--audit-log-maxage` argument is set to 30 or as appropriate.
|
||||
- Ensure that the `--audit-log-maxbackup` argument is set to 10 or as appropriate.
|
||||
- Ensure that the `--audit-log-maxsize` argument is set to 100 or as appropriate.
|
||||
|
||||
To enable and configure audit logs, add the following line to K3s cluster configuration file:
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
rkeConfig:
|
||||
machineGlobalConfig:
|
||||
kube-apiserver-arg:
|
||||
- audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml # CIS v1.20/v1.23 3.2.1
|
||||
- audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log # CIS v1.20 1.2.21 and CIS v1.23 1.2.19
|
||||
- audit-log-maxage=30 # CIS v1.20 1.2.22 and CIS v1.23 1.2.20
|
||||
- audit-log-maxbackup=10 # CIS v1.20 1.2.23 and CIS v1.23 1.2.21
|
||||
- audit-log-maxsize=100 # CIS v1.20 1.2.24 and CIS v1.23 1.2.22
|
||||
```
|
||||
|
||||
## Known Issues
|
||||
|
||||
The following are controls that K3s currently does not pass by default. Each gap will be explained, along with a note clarifying whether it can be passed through manual operator intervention, or if it will be addressed in a future release of K3s.
|
||||
|
||||
### Control CIS v1.20 - 1.2.13 / CIS v1.23 - 1.2.14
|
||||
Ensure that the admission control plugin `ServiceAccount` is set
|
||||
<details>
|
||||
<summary>Rationale</summary>
|
||||
Follow the documentation and create `ServiceAccount` objects as per your environment. Then, edit the API server pod specification file $apiserverconf
|
||||
on the control plane node and ensure that the `--disable-admission-plugins` parameter is set to a value that does not include `ServiceAccount`.
|
||||
|
||||
This can be remediated by adding the following argument line to K3s cluster configuration file:
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
rkeConfig:
|
||||
machineGlobalConfig:
|
||||
kube-apiserver-arg:
|
||||
kube-apiserver-arg:
|
||||
- enable-admission-plugins=ServiceAccount # CIS v1.20 - 1.2.13 / CIS v1.23 - 1.2.14
|
||||
```
|
||||
</details>
|
||||
|
||||
### Control CIS v1.20 1.2.26 and CIS v1.23 1.2.23
|
||||
Ensure that the `--request-timeout` argument is set as appropriate.
|
||||
<details>
|
||||
<summary>Rationale</summary>
|
||||
Setting global request timeout allows extending the API server request timeout limit to a duration appropriate to the user's connection speed. By default, it is set to 60 seconds which might be problematic on slower connections making cluster resources inaccessible once the data volume for requests exceeds what can be transmitted in 60 seconds. But, setting this timeout limit to be too large can exhaust the API server resources making it prone to Denial-of-Service attack. Hence, it is recommended to set this limit as appropriate and change the default limit of 60 seconds only if needed.
|
||||
|
||||
This can be remediated by adding the following argument line to K3s cluster configuration file:
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
rkeConfig:
|
||||
machineGlobalConfig:
|
||||
kube-apiserver-arg:
|
||||
- request-timeout=300s # Control CIS v1.20 1.2.26 and CIS v1.23 1.2.23
|
||||
```
|
||||
</details>
|
||||
|
||||
### Control CIS v1.23 1.2.24
|
||||
Ensure that the `--service-account-lookup` argument is set to true.
|
||||
<details>
|
||||
<summary>Rationale</summary>
|
||||
If `--service-account-lookup` is not enabled, the apiserver only verifies that the authentication token is valid, and does not validate that the service account token mentioned in the request is actually present in etcd. This allows using a service account token even after the corresponding service account is deleted. This is an example of time of check to time of use security issue.
|
||||
|
||||
This can be remediated by adding the following argument line to K3s cluster configuration file:
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
rkeConfig:
|
||||
machineGlobalConfig:
|
||||
kube-apiserver-arg:
|
||||
- service-account-lookup=true # Control CIS v1.23 1.2.24
|
||||
```
|
||||
</details>
|
||||
|
||||
### CIS v1.20 1.2.32 and CIS v1.23 1.2.30
|
||||
Ensure that the `--encryption-provider-config` argument is set as appropriate.
|
||||
<details>
|
||||
<summary>Rationale</summary>
|
||||
`etcd` is a highly available key-value store used by Kubernetes deployments for persistent storage of all of its REST API objects. These objects are sensitive in nature and should be encrypted at rest to avoid any disclosures.
|
||||
|
||||
Detailed steps on how to configure secrets encryption in K3s are available in [K3s Secrets Encryption Config](https://docs.k3s.io/security/secrets-encryption).
|
||||
</details>
|
||||
|
||||
### Control CIS v1.20 1.2.33 and CIS v1.23 1.2.31
|
||||
Ensure that encryption providers are appropriately configured.
|
||||
<details>
|
||||
<summary>Rationale</summary>
|
||||
Where `etcd` encryption is used, it is important to ensure that the appropriate set of encryption providers is used. Currently, the `aescbc`, `kms` and `secretbox` are likely to be appropriate options.
|
||||
|
||||
This can be remediated by passing a valid configuration to `k3s` as outlined above. Detailed steps on how to configure secrets encryption in K3s are available in [K3s Secrets Encryption Config](https://docs.k3s.io/security/secrets-encryption).
|
||||
</details>
|
||||
|
||||
### Control 4.2.7
|
||||
Ensure that the `--make-iptables-util-chains` argument is set to true.
|
||||
<details>
|
||||
<summary>Rationale</summary>
|
||||
Kubelets can automatically manage the required changes to iptables based on how you choose your networking options for the pods. It is recommended to let kubelets manage the changes to iptables. This ensures that the iptables configuration remains in sync with pods networking configuration. Manually configuring iptables with dynamic pod network configuration changes might hamper the communication between pods/containers and to the outside world. You might have iptables rules too restrictive or too open.
|
||||
|
||||
This can be remediated by adding the following argument line to K3s cluster configuration file:
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
rkeConfig:
|
||||
machineSelectorConfig:
|
||||
- config:
|
||||
kubelet-arg:
|
||||
- make-iptables-util-chains=true # Control 4.2.7
|
||||
```
|
||||
</details>
|
||||
|
||||
### Control 5.1.5
|
||||
Ensure that default service accounts are not actively used
|
||||
<details>
|
||||
<summary>Rationale</summary>
|
||||
Kubernetes provides a `default` service account which is used by cluster workloads where no specific service account is assigned to the pod.
|
||||
|
||||
Where access to the Kubernetes API from a pod is required, a specific service account should be created for that pod, and rights granted to that service account.
|
||||
|
||||
The default service account should be configured such that it does not provide a service account token and does not have any explicit rights assignments.
|
||||
|
||||
This can be remediated by updating the `automountServiceAccountToken` field to `false` for the `default` service account in each namespace.
|
||||
|
||||
For `default` service accounts in the built-in namespaces (`kube-system`, `kube-public`, `kube-node-lease`, and `default`), K3s does not automatically do this. You can manually update this field on these service accounts to pass the control or use the script below to automate this task.
|
||||
|
||||
Save the follow configuration to a file called `account_update.yaml`.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: default
|
||||
automountServiceAccountToken: false
|
||||
```
|
||||
|
||||
Create a bash script file called `account_update.sh`. Be sure to `sudo chmod +x account_update.sh` so the script has execute permissions.
|
||||
|
||||
```bash
|
||||
#!/bin/bash -e
|
||||
|
||||
for namespace in $(kubectl get namespaces -A -o=jsonpath="{.items[*]['metadata.name']}"); do
|
||||
echo -n "Patching namespace $namespace - "
|
||||
kubectl patch serviceaccount default -n ${namespace} -p "$(cat account_update.yaml)"
|
||||
done
|
||||
```
|
||||
|
||||
Execute the script to update the default service account in each namespace.
|
||||
</details>
|
||||
|
||||
|
||||
### Reference Hardened K3s Template Configuration
|
||||
|
||||
The reference template configuration below is used in Rancher to create a hardened K3s custom cluster based on each CIS control presented in this guide. This reference does not include other required **cluster configuration** directives which will vary depending on your environment.
|
||||
|
||||
```yaml
|
||||
apiVersion: provisioning.cattle.io/v1
|
||||
kind: Cluster
|
||||
metadata:
|
||||
name: # Define cluster name
|
||||
annotations:
|
||||
spec:
|
||||
defaultPodSecurityPolicyTemplateName: '' # Define the PSP policy to use
|
||||
enableNetworkPolicy: true
|
||||
kubernetesVersion: # Define K3s version
|
||||
rkeConfig:
|
||||
machineGlobalConfig:
|
||||
kube-apiserver-arg:
|
||||
- enable-admission-plugins=NodeRestriction,PodSecurityPolicy,ServiceAccount # CIS 1.2.16, CIS 5.2 and CIS v1.20 - 1.2.13 / CIS v1.23 - 1.2.14
|
||||
- audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml # CIS v1.20/v1.23 3.2.1
|
||||
- audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log # CIS v1.20 1.2.21 and CIS v1.23 1.2.19
|
||||
- audit-log-maxage=30 # CIS v1.20 1.2.22 and CIS v1.23 1.2.20
|
||||
- audit-log-maxbackup=10 # CIS v1.20 1.2.23 and CIS v1.23 1.2.21
|
||||
- audit-log-maxsize=100 # CIS v1.20 1.2.24 and CIS v1.23 1.2.22
|
||||
- request-timeout=300s # Control CIS v1.20 1.2.26 and CIS v1.23 1.2.23
|
||||
- service-account-lookup=true # Control CIS v1.23 1.2.24
|
||||
secrets-encryption: true
|
||||
machineSelectorConfig:
|
||||
- config:
|
||||
kubelet-arg:
|
||||
- make-iptables-util-chains=true # Control 4.2.7
|
||||
protect-kernel-defaults: true # Control 4.2.6
|
||||
```
|
||||
|
||||
### Conclusion
|
||||
|
||||
If you have followed this guide, your K3s custom cluster provisioned by Rancher will be configured to pass the CIS Kubernetes Benchmark. You can review our K3s CIS Benchmark Self-Assessment Guide for [CIS v1.20](k3s-self-assessment-guide-with-cis-v1.20-benchmark.md) and [CIS v1.23](k3s-self-assessment-guide-with-cis-v1.23-benchmark.md) to understand how we verified each of the benchmarks and how you can do the same on your cluster.
|
||||
-3133
File diff suppressed because it is too large
Load Diff
-3143
File diff suppressed because it is too large
Load Diff
+1
@@ -6,6 +6,7 @@ Rancher 致力于向社区披露我们产品的安全问题。我们会针对已
|
||||
|
||||
| ID | 描述 | 日期 | 解决 |
|
||||
|----|-------------|------|------------|
|
||||
| [CVE-2023-22651](https://github.com/rancher/rancher/security/advisories/GHSA-6m9f-pj6w-w87g) | 由于 webhook 的更新逻辑失败，Rancher 准入 webhook 可能会配置错误。准入 webhook 在资源允许进入 Kubernetes 集群之前会强制执行验证规则和安全检查。webhook 在降级状态下运行时将不再验证任何资源，这可能导致严重的权限提升和数据损坏。 | 2023 年 4 月 24 日 | Rancher [v2.7.3](https://github.com/rancher/rancher/releases/tag/v2.7.3) |
|
||||
| [CVE-2022-43758](https://github.com/rancher/rancher/security/advisories/GHSA-34p5-jp77-fcrc) | 在 Rancher 2.5.0 至 2.5.16、2.6.0 至 2.6.9 和 2.7.0 版本中发现了一个问题，Rancher Git 包中存在命令注入漏洞。这个包使用 Rancher 容器镜像中可用的底层 Git 二进制文件来执行 Git 操作。特制的命令如果没有消除歧义，可能会在通过 Git 执行时造成混淆，导致在底层 Rancher 主机中进行命令注入。 | 2023 年 1 月 24 日 | Rancher [v2.7.1](https://github.com/rancher/rancher/releases/tag/v2.7.1)、[v2.6.10](https://github.com/rancher/rancher/releases/tag/v2.6.10) 和 [v2.5.17](https://github.com/rancher/rancher/releases/tag/v2.5.17) |
|
||||
| [CVE-2022-43757](https://github.com/rancher/rancher/security/advisories/GHSA-cq4p-vp5q-4522) | 此问题影响 Rancher 2.5.0 到 2.5.16，2.6.0 至 2.6.9 和 2.7.0。我们发现 Rancher 之前发布的安全公告 [CVE-2021-36782](https://github.com/advisories/GHSA-g7j7-h4q8-8w2f) 没有解决某些敏感字段、Secret Token、加密密钥和 SSH 密钥，这些字段仍然以明文形式直接存储在 Kubernetes 上 `Clusters` 之类的对象。在 Rancher 中，集群中已认证的 `Cluster Owners`、`Cluster Members`、`Project Owners` 和 `Project Members` 可以看到公开的凭证。 | 2023 年 1 月 24 日 | Rancher [v2.7.1](https://github.com/rancher/rancher/releases/tag/v2.7.1)、[v2.6.10](https://github.com/rancher/rancher/releases/tag/v2.6.10) 和 [v2.5.17](https://github.com/rancher/rancher/releases/tag/v2.5.17) |
|
||||
| [CVE-2022-43755](https://github.com/rancher/rancher/security/advisories/GHSA-8c69-r38j-rpfj) | 在 Rancher 2.6.9 和 2.7.0 之前的版本中发现了一个问题，即 `cattle-cluster-agent` 使用的 `cattle-token` Secret 是可预测的。重新生成 Token 之后，Token 的值依然相同。如果 Token 被泄露并且出于安全目的需要重新创建，这可能会造成严重的问题。Rancher 的 `cattle-cluster-agent` 使用 `cattle-token` 来连接到 Rancher 配置的下游集群 Kubernetes API。 | 2023 年 1 月 24 日 | Rancher [v2.7.1](https://github.com/rancher/rancher/releases/tag/v2.7.1) 和 [v2.6.10](https://github.com/rancher/rancher/releases/tag/v2.6.10) |
|
||||
|
||||
+50
-5
@@ -2,16 +2,61 @@
|
||||
title: 用户偏好
|
||||
---
|
||||
|
||||
每个用户都可以设置自己的偏好，从而按照自己的喜好调整 Rancher UI 界面。要更改偏好设置，请打开**用户设置**菜单，然后选择**偏好设置**。
|
||||
你可以通过偏好设置来个性化你的 Rancher 体验。要更改偏好设置：
|
||||
|
||||
1. 单击右上角的用户头像。
|
||||
1. 单击**偏好设置**。
|
||||
|
||||
## 语言
|
||||
|
||||
选择 Rancher UI 显示的语言。选项包括：
|
||||
|
||||
- English
|
||||
- 简体中文
|
||||
|
||||
## 主题
|
||||
|
||||
选择 Rancher UI 的背景颜色。如果选择**自动**，背景颜色会在下午 6 点从浅色变为深色，然后在早上 6 点变回浅色。
|
||||
|
||||
## 我的账号
|
||||
## 登录页面
|
||||
|
||||
此部分显示用于会话的**名称**（你的显示名称）和**用户名**（你的登录名）。要更改你当前的密码，请单击**更改密码**按钮。
|
||||
选择登录后显示的页面。选项包括：
|
||||
|
||||
## 每页表格行
|
||||
- 主页。
|
||||
- 上次访问的页面。
|
||||
- 你选择的特定集群。
|
||||
|
||||
在使用表格来显示系统对象（如集群或 deployment）的页面中，你可以设置每页显示的最大对象数量。默认设置为 `50`。
|
||||
## 显示设置
|
||||
|
||||
选择信息的显示方式：
|
||||
|
||||
- 日期格式
|
||||
- 时间格式
|
||||
- 每页行数
|
||||
- 在侧边栏显示的集群数量
|
||||
|
||||
## 确认设置
|
||||
|
||||
_从 v2.7.2 起可用_
|
||||
|
||||
选择缩减节点池时是否要求确认。
|
||||
|
||||
## 高级功能
|
||||
|
||||
- 启用“在 API 中查看”。
|
||||
- 显示由 Rancher 管理的 system 命名空间（不要编辑或删除）。
|
||||
- 使用快捷键（shift+T）来切换深色/浅色主题。
|
||||
- 隐藏所有类型描述。
|
||||
- 启用扩展开发者功能。
|
||||
|
||||
|
||||
|
||||
## YAML 编辑器
|
||||
|
||||
- 默认
|
||||
- Emacs
|
||||
- Vim
|
||||
|
||||
## Helm Chart
|
||||
|
||||
选择仅显示已发布的 Helm Chart 还是同时包含预发布版本。如果版本符合 [Semantic Versioning 2.0.0](https://semver.org/) 定义的[规范](https://semver.org/#spec-item-9)，则那么该版本为预发布版本。例如，要显示版本为 `0.1.3-dev.12ab4f` 的 Helm chart，你需要先选择`包括预发布版本`。
|
||||
|
||||
Reference in New Issue
Block a user