CIS 1.23 自我评估指南

CIS Kubernetes Benchmark v1.23 - RKE2

概述

本文件是 RKE2 安全强化指南的补充文件。安全强化指南为 RKE2 生产环境的安装提供了安全强化的建议性指导，而本基准指南旨在帮助您根据 CIS Kubernetes 基准中的每项控制，评估已强化集群的安全级别。该指南供 RKE2 操作员、安全团队、审计员和决策者使用。

本指南特定于 RKE2 的 v1.25 版本线和 CIS Kubernetes 基准的 v1.23 版本。

有关每项控制的更多详细信息，包括失败测试的详细描述和补救措施，您可以参考 CIS Kubernetes 基准 v1.23 的相应部分。您可以在登录 CISecurity.org 后下载基准。

测试控制方法

CIS Kubernetes 基准中的每项控制都是针对根据附带的安全强化指南配置的 RKE2 集群进行评估的。

当控制审计与原始 CIS 基准不同时，提供了特定于 RKE2 的审计命令以供测试。

每项控制的可能结果如下：

通过 - 被测试的 RKE2 集群通过了基准中概述的审计。
不适用 - 由于 RKE2 的设计方式，该控制不适用于 RKE2。补救部分将解释原因。
手动 - 依赖操作员 - 该控制在 CIS 基准中是手动的，取决于集群的使用案例或必须由集群操作员确定的其他因素。这些控制已被评估，以确保 RKE2 不会阻止其实施，但未对被测试的集群进行进一步的配置或审计。

控件

1 主节点安全配置

1.1 主节点配置文件

1.1.1

确保 API 服务器 pod 规范文件的权限设置为 644 或更严格（自动化）。

说明

API 服务器 pod 规范文件控制着设置 API 服务器行为的各种参数。您应限制其文件权限以维护文件的完整性。该文件应仅由系统上的管理员可写。

*结果：*通过

Audit:

stat -c %a /var/lib/rancher/rke2/agent/pod-manifests/kube-apiserver.yaml
644

修正： 默认情况下，RKE2 创建这些文件时权限为 644。无需手动修复。

1.1.2

确保 API 服务器 pod 规范文件的所有权设置为 root:root（自动化）。

说明

API 服务器 pod 规范文件控制着设置 API 服务器行为的各种参数。您应该设置其文件所有权以维护文件的完整性。该文件应由 root:root 拥有。

*结果：*通过

Audit:

stat -c %U:%G /var/lib/rancher/rke2/agent/pod-manifests/kube-apiserver.yaml
root:root

修正： 默认情况下，RKE2 创建这些文件时所有权为 root:root。无需手动修复。

1.1.3

确保控制器管理器 pod 规范文件的权限设置为 644 或更严格（自动化）。

说明

控制器管理器 pod 规范文件控制着设置主节点上控制器管理器行为的各种参数。您应限制其文件权限以维护文件的完整性。该文件应仅由系统上的管理员可写。

*结果：*通过

Audit:

stat -c %a /var/lib/rancher/rke2/agent/pod-manifests/kube-controller-manager.yaml
644

修正： 默认情况下，RKE2 创建这些文件时权限为 644。无需手动修复。

1.1.4

确保控制器管理器 pod 规范文件的所有权设置为 root:root（自动化）。

说明

控制器管理器 pod 规范文件控制着设置主节点上各种组件行为的各种参数。您应该设置其文件所有权以维护文件的完整性。该文件应由 root:root 拥有。

*结果：*通过

Audit:

stat -c %U:%G /var/lib/rancher/rke2/agent/pod-manifests/kube-controller-manager.yaml
root:root

修正： 默认情况下，RKE2 创建这些文件时所有权为 root:root。无需手动修复。

1.1.5

确保调度程序 pod 规范文件的权限设置为 644 或更严格（自动化）。

说明

调度程序 pod 规范文件控制着设置主节点上调度程序服务行为的各种参数。您应限制其文件权限以维护文件的完整性。该文件应仅由系统上的管理员可写。

*结果：*通过

Audit:

stat -c %a /var/lib/rancher/rke2/agent/pod-manifests/kube-scheduler.yaml
644

修正： 默认情况下，RKE2 创建这些文件时权限为 644。无需手动修复。

1.1.6

确保调度程序 pod 规范文件的所有权设置为 root:root（自动化）。

说明

调度程序 pod 规范文件控制着设置主节点上 kube-scheduler 服务行为的各种参数。您应该设置其文件所有权以维护文件的完整性。该文件应由 root:root 拥有。

*结果：*通过

Audit:

stat -c %U:%G /var/lib/rancher/rke2/agent/pod-manifests/kube-scheduler.yaml
root:root

修正： 默认情况下，RKE2 创建这些文件时所有权为 root:root。无需手动修复。

1.1.7

确保 etcd pod 规范文件的权限设置为 644 或更严格（自动化）。

说明

etcd pod 规范文件 /var/lib/rancher/rke2/agent/pod-manifests/etcd.yaml 控制着设置主节点上 etcd 服务行为的各种参数。etcd 是一个高可用的键值存储，Kubernetes 用于持久存储其所有 REST API 对象。您应限制其文件权限以维护文件的完整性。该文件应仅由系统上的管理员可写。

*结果：*通过

Audit:

stat -c %a /var/lib/rancher/rke2/agent/pod-manifests/etcd.yaml
644

修正： 默认情况下，RKE2 创建这些文件时权限为 644。无需手动修复。

1.1.8

确保 etcd pod 规范文件的所有权设置为 root:root（自动化）。

说明

etcd pod 规范文件 /var/lib/rancher/rke2/agent/pod-manifests/etcd.yaml 控制着设置主节点上 etcd 服务行为的各种参数。etcd 是一个高可用的键值存储，Kubernetes 用于持久存储其所有 REST API 对象。您应该设置其文件所有权以维护文件的完整性。该文件应由 root:root 拥有。

*结果：*通过

Audit:

stat -c %U:%G /var/lib/rancher/rke2/agent/pod-manifests/etcd.yaml
root:root

修正： 默认情况下，RKE2 创建这些文件时所有权为 root:root。无需手动修复。

1.1.9

确保容器网络接口文件的权限设置为 644 或更严格（手动）。

说明

容器网络接口为覆盖网络提供各种网络选项。您应该查阅他们的文档，并限制各自文件的权限，以维护这些文件的完整性。这些文件应只允许系统上的管理员写入。

*结果：*通过

Audit:

stat -c %a /var/lib/rancher/rke2/server/manifests/rke2-canal.yaml
644

修正： RKE2 使用 Helm 图表部署默认的 CNI，Canal。该图表在具有 644 权限的文件中定义为自定义资源。无需手动修复。

1.1.10

确保容器网络接口文件的所有权设置为 root:root（手动）。

说明

容器网络接口为覆盖网络提供各种网络选项。您应该查阅他们的文档，并限制各自文件的权限，以维护这些文件的完整性。这些文件应由 root:root 拥有。

*结果：*通过

Audit:

stat -c %U:%G /var/lib/rancher/rke2/server/manifests/rke2-canal.yaml
root:root

修正： RKE2 使用 Helm 图表部署默认的 CNI，Canal。该图表在具有 root:root 所有权的文件中定义为自定义资源。无需手动修复。

1.1.11

确保 etcd 数据目录的权限设置为 700 或更严格（自动化）。

说明

etcd 是一个高可用的键值存储，用于 Kubernetes 部署的所有 REST API 对象的持久存储。此数据目录应防止任何未经授权的读取或写入。任何组成员或公众都不应可读或可写。

*结果：*通过

Audit:

stat -c %a /var/lib/rancher/rke2/server/db/etcd
700

修正： RKE2 管理 etcd 数据目录并将其权限设置为 700。无需手动修复。

1.1.12

确保 etcd 数据目录的所有权设置为 etcd:etcd（自动化）。

说明

etcd 是一个高可用的键值存储，用于 Kubernetes 部署的所有 REST API 对象的持久存储。此数据目录应防止任何未经授权的读取或写入。它应由 etcd:etcd 拥有。

*结果：*通过

Audit:

stat -c %U:%G /var/lib/rancher/rke2/server/db/etcd
etcd:etcd

修正： 当使用 profile 标志设置为 cis-1.23 运行 RKE2 时，如果主机上不存在 etcd 用户和组，RKE2 将拒绝启动。如果存在，RKE2 将自动将 etcd 数据目录的所有权设置为 etcd:etcd，并确保 etcd 静态 Pod 以该用户和组启动。

1.1.13

确保 admin.conf 文件的权限设置为 644 或更严格（自动化）。

说明

admin.conf 是管理员 kubeconfig 文件，定义了集群管理的各种设置。您应限制其文件权限以维护文件的完整性。该文件应只允许系统上的管理员写入。

在 RKE2 中，此文件位于 /var/lib/rancher/rke2/server/cred/admin.kubeconfig。

*结果：*通过

Audit:

stat -c %a /var/lib/rancher/rke2/server/cred/admin.kubeconfig
644

修正： 默认情况下，RKE2 在 /var/lib/rancher/rke2/server/cred/admin.kubeconfig 创建此文件，并自动将其权限设置为 644。无需手动修复。

1.1.14

确保 admin.conf 文件的所有权设置为 root:root（自动化）。

说明

admin.conf 文件包含集群的管理员凭据。您应该设置其文件所有权以维护文件的完整性。该文件应由 root:root 拥有。

在 RKE2 中，此文件位于 /var/lib/rancher/rke2/server/cred/admin.kubeconfig。

*结果：*通过

Audit:

stat -c %U:%G /var/lib/rancher/rke2/server/cred/admin.kubeconfig
root:root

修正： 默认情况下，RKE2 在 stat -c %U:%G /var/lib/rancher/rke2/server/cred/admin.kubeconfig 创建此文件，并自动将其所有权设置为 root:root。

1.1.15

确保 scheduler.conf 文件的权限设置为 644 或更严格（自动化）。

说明

scheduler.conf 文件是调度器的 kubeconfig 文件。您应限制其文件权限以维护文件的完整性。该文件应仅由系统上的管理员可写。

在 RKE2 中，此文件位于 /var/lib/rancher/rke2/server/cred/scheduler.kubeconfig。

*结果：*通过

Audit:

stat -c %a /var/lib/rancher/rke2/server/cred/scheduler.kubeconfig
644

修正： 默认情况下，RKE2 在 /var/lib/rancher/rke2/server/cred/scheduler.kubeconfig 创建此文件，并自动将其权限设置为 644。无需手动修复。

1.1.16

确保 scheduler.conf 文件的所有权设置为 root:root（自动化）。

说明

scheduler.conf 文件是调度器的 kubeconfig 文件。您应该设置其文件所有权以维护文件的完整性。该文件应由 root:root 拥有。

在 RKE2 中，此文件位于 /var/lib/rancher/rke2/server/cred/scheduler.kubeconfig。

*结果：*通过

Audit:

stat -c %U:%G /var/lib/rancher/rke2/server/cred/scheduler.kubeconfig
root:root

修正： 默认情况下，RKE2 在 /var/lib/rancher/rke2/server/cred/scheduler.kubeconfig 创建此文件，并自动将其所有权设置为 root:root。

1.1.17

确保 controller.kubeconfig 文件的权限设置为 644 或更严格（自动化）。

说明

controller.kubeconfig 文件是调度器的 kubeconfig 文件。您应限制其文件权限以维护文件的完整性。该文件应仅由系统上的管理员可写。

在 RKE2 中，此文件位于 /var/lib/rancher/rke2/server/cred/controller.kubeconfig。

*结果：*通过

Audit:

stat -c %a /var/lib/rancher/rke2/server/cred/controller.kubeconfig
644

修正： 默认情况下，RKE2 在 /var/lib/rancher/rke2/server/cred/controller.kubeconfig 创建此文件，并自动将其权限设置为 644。无需手动修复。

1.1.18

确保 controller.kubeconfig 文件的所有权设置为 root:root（自动化）。

说明

controller.kubeconfig 文件是调度器的 kubeconfig 文件。您应该设置其文件所有权以维护文件的完整性。该文件应由 root:root 拥有。

在 RKE2 中，此文件位于 /var/lib/rancher/rke2/server/cred/controller.kubeconfig。

*结果：*通过

Audit:

stat -c %U:%G /var/lib/rancher/rke2/server/cred/controller.kubeconfig
root:root

修正： 默认情况下，RKE2 在 /var/lib/rancher/rke2/server/cred/controller.kubeconfig 创建此文件，并自动将其所有权设置为 root:root。

1.1.19

确保 Kubernetes PKI 目录和文件的所有权设置为 root:root（自动化）。

说明

Kubernetes 在其操作中使用多个证书。您应该将包含 PKI 信息的目录及该目录中所有文件的所有权设置为以维护其完整性。该目录和文件应由 root:root 拥有。

*结果：*通过

Audit:

stat -c %U:%G /var/lib/rancher/rke2/server/tls
root:root

修正： 默认情况下，RKE2 创建目录和文件时，预期的所有权为 root:root。不需要手动修复。

1.1.20

确保 Kubernetes PKI 证书文件的权限设置为 644 或更严格（自动化）。

说明

Kubernetes 在其组件的操作中使用多个证书文件。这些文件的权限应设置为 644 或更严格，以保护其完整性。

*结果：*通过

Audit: 在主节点上运行以下命令。

stat -c %n\ %a /var/lib/rancher/rke2/server/tls/*.crt

验证权限是否为 644 或更严格。

修正： 默认情况下，RKE2 创建文件时，预期的权限为 644。不需要手动修复。

1.1.21

确保 Kubernetes PKI 密钥文件的权限设置为 600（自动化）。

说明

Kubernetes 在其组件的操作中使用多个关键文件。这些文件的权限应设置为 600，以保护其完整性和机密性。

*结果：*通过

Audit: 在主节点上运行以下命令。

stat -c %n\ %a /var/lib/rancher/rke2/server/tls/*.key

验证权限是否为 600 或更严格。

修正： 默认情况下，RKE2 创建文件时，预期的权限为 600。不需要手动修复。

1.2 API 服务器

本节包含与 API 服务器配置标志相关的建议。

1.2.1

确保 --anonymous-auth 参数设置为 false（手动）。

说明

启用时，未被其他配置的身份验证方法拒绝的请求将被视为匿名请求。这些请求将由 API 服务器处理。您应依赖身份验证来授权访问，并禁止匿名请求。

如果您使用 RBAC 授权，通常认为允许匿名访问 API 服务器以进行健康检查和发现是合理的，因此此建议为手动。然而，您应考虑匿名发现是否对您的目的来说是可接受的风险。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-apiserver | grep -v grep

验证 --anonymous-auth=false 是否存在。

修正： 默认情况下，RKE2 kube-apiserver 配置为使用此标志和值运行。不需要手动修复。

1.2.2

确保 --token-auth-file 参数未设置（自动化）。

说明

基于令牌的身份验证使用静态令牌来验证对 apiserver 的请求。令牌以明文形式存储在 apiserver 的文件中，无法在不重启 apiserver 的情况下撤销或轮换。因此，请勿使用静态基于令牌的身份验证。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-apiserver | grep -v grep

验证 --token-auth-file 参数不存在。

修正： 默认情况下，RKE2 不启用令牌身份验证。不需要手动修复。

1.2.3

确保 --DenyServiceExternalIPs 未设置（自动化）。

说明

此准入控制器拒绝所有对 Service 字段 externalIPs 的新使用。此功能非常强大（允许网络流量拦截），且策略控制不严。启用后，集群的用户可能无法创建使用 externalIPs 的新服务，也无法在现有服务对象上添加 externalIPs 的新值。现有的 externalIPs 使用不受影响，用户可以从现有服务对象的 externalIPs 中去除值。

大多数用户根本不需要此功能，集群管理员应考虑禁用它。需要使用此功能的集群应考虑使用一些自定义策略来管理其使用。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-apiserver | grep -v grep

验证 --enable-admission-plugins 参数中没有 DenyServiceExternalIPs。

修正： 默认情况下，RKE2 不会将 DenyServiceExternalIPs 设置为准入插件标志。不需要手动修复。

1.2.4

确保 --kubelet-https 参数设置为 true（自动）。

说明

从 apiserver 到 kubelet 的连接可能会携带敏感数据，例如机密和密钥。因此，在 apiserver 和 kubelet 之间的任何通信中使用传输加密非常重要。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-apiserver | grep -v grep

验证 --kubelet-https 参数不存在。

修正： 默认情况下，RKE2 kube-apiserver 不会使用 --kubelet-https 参数运行，因为它使用 TLS 运行。不需要手动修复。

1.2.5

确保 --kubelet-client-certificate 和 --kubelet-client-key 参数设置正确（自动）。

说明

默认情况下，apiserver 不会向 kubelet 的 HTTPS 端点进行身份验证。来自 apiserver 的请求被视为匿名。您应设置基于证书的 kubelet 身份验证，以确保 apiserver 在提交请求时向 kubelet 进行身份验证。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-apiserver | grep -v grep

验证 --kubelet-client-certificate 和 --kubelet-client-key 参数是否存在，并且设置正确。

修正： 默认情况下，RKE2 kube-apiserver 使用这些参数与 kubelet 进行安全通信。不需要手动修复。

1.2.6

确保 --kubelet-certificate-authority 参数设置正确（自动）。

说明

从 apiserver 到 kubelet 的连接用于获取 pod 的日志、通过 kubectl 附加到正在运行的 pod，以及使用 kubelet 的端口转发功能。这些连接在 kubelet 的 HTTPS 端点终止。默认情况下，apiserver 不会验证 kubelet 的服务证书，这使得连接容易受到中间人攻击，并且在不受信任和/或公共网络上运行不安全。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-apiserver | grep -v grep

验证 --kubelet-certificate-authority 参数是否存在并设置为适当值。

修正： 默认情况下，RKE2 kube-apiserver 使用此参数与 kubelet 进行安全通信。不需要手动修复。

1.2.7

确保 --authorization-mode 参数未设置为 AlwaysAllow（自动化）。

说明

API 服务器可以配置为允许所有请求。此模式不应在任何生产集群中使用。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-apiserver | grep -v grep

验证参数值不包含 AlwaysAllow。

修正： 默认情况下，RKE2 将 Node,RBAC 设置为 --authorization-mode 参数的值。不需要手动修复。

1.2.8

确保 --authorization-mode 参数包含 Node（自动化）。

说明

节点授权模式仅允许 kubelet 读取与其节点相关的 Secret、ConfigMap、PersistentVolume 和 PersistentVolumeClaim 对象。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-apiserver | grep -v grep

验证 Node 是否作为参数存在于该参数中。

修正： 默认情况下，RKE2 将 Node,RBAC 设置为 --authorization-mode 参数的值。不需要手动修复。

1.2.9

确保 --authorization-mode 参数包含 RBAC（自动化）。

说明

基于角色的访问控制（RBAC）允许对不同实体在集群中对不同对象执行的操作进行细粒度控制。建议使用 RBAC 授权模式。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-apiserver | grep -v grep

验证 RBAC 是否作为参数存在于该参数中。

修正： 默认情况下，RKE2 将 Node,RBAC 设置为 --authorization-mode 参数的值。无需手动修复。

1.2.10

确保 admission control 插件 EventRateLimit 已设置（手动）。

说明

使用 EventRateLimit 准入控制强制限制 API 服务器在给定时间片内接受的事件数量。行为不当的工作负载可能会使 API 服务器不堪重负并导致拒绝服务。这尤其适用于多租户集群，其中可能有少量行为不当的租户，这可能会对集群整体性能产生重大影响。因此，建议限制 API 服务器将接受的事件速率。

这是 Kubernetes 1.15 版本中的 Alpha 功能。

结果：*手动 - 操作员依赖*

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-apiserver | grep -v grep

验证 --enable-admission-plugins 参数是否设置为包含 EventRateLimit 的值。

修正： 默认情况下，RKE2 仅将 NodeRestriction,PodSecurityPolicy 设置为 --enable-admission-plugins 参数的值。要配置此项，请遵循 Kubernetes 文档，并在配置文件中设置所需的限制。然后参考 RKE2 的文档，了解如何通过 kube-apiserver-arg 参数提供额外的 API 服务器配置。

1.2.11

确保 admission control 插件 AlwaysAdmit 未设置（自动化）。

说明

设置 admission control 插件 AlwaysAdmit 允许所有请求，并且不过滤任何请求。

AlwaysAdmit 准入控制器在 Kubernetes v1.13 中被弃用。其行为相当于关闭所有准入控制器。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-apiserver | grep -v grep

验证如果设置了 --enable-admission-plugins 参数，其值不包含 AlwaysAdmit。

修正： 默认情况下，RKE2 仅将 NodeRestriction,PodSecurityPolicy 设置为 --enable-admission-plugins 参数的值。无需手动修复。

1.2.12

确保 admission control 插件 AlwaysPullImages 已设置（手动）。

说明

将准入控制策略设置为 AlwaysPullImages 强制每个新 Pod 每次都拉取所需的镜像。在多租户集群中，用户可以确保他们的私有镜像只能被拥有拉取凭证的用户使用。如果没有此准入控制策略，一旦镜像被拉取到节点，任何用户的 Pod 只需知道镜像名称即可使用它，而无需对镜像所有权进行任何授权检查。当启用此插件时，镜像在启动容器之前始终被拉取，这意味着需要有效的凭证。

结果：*手动 - 操作员依赖*

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-apiserver | grep -v grep

验证 --enable-admission-plugins 参数是否设置为包含 AlwaysPullImages 的值。

1.2.13

如果未使用 PodSecurityPolicy，请确保设置 admission control 插件 SecurityContextDeny（手动）。

说明

SecurityContextDeny 可用于为未启用 PodSecurityPolicies 的集群提供一层安全性。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-apiserver | grep -v grep

验证如果未包含 PodSecurityPolicy，则 --enable-admission-plugins 参数的值是否包含 SecurityContextDeny。

修正： 默认情况下，RKE2 自动启用 PodSecurityPolicy 准入插件。因此，无需启用 SecurityContextDeny 插件。无需手动修复。

1.2.14

确保 admission control 插件 ServiceAccount 已设置（自动化）。

说明

当您创建一个 pod 时，如果不指定服务账户，它会自动分配同一命名空间中的 default 服务账户。您应该创建自己的服务账户，并让 API 服务器管理其安全令牌。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-apiserver | grep -v grep

验证 --disable-admission-plugins 参数是否设置为不包含 ServiceAccount 的值。

修正： 默认情况下，RKE2 不使用此参数。如果希望使用此参数，请遵循文档并根据您的环境创建 ServiceAccount 对象。然后参考 RKE2 的文档，了解如何通过 kube-apiserver-arg 参数提供额外的 API 服务器配置。

1.2.15

确保 admission control 插件 NamespaceLifecycle 已设置（自动化）。

说明

将 admission control 策略设置为 NamespaceLifecycle 可确保无法在不存在的命名空间中创建对象，并且正在终止的命名空间不会用于创建新对象。建议这样做以确保命名空间终止过程的完整性，并确保新对象的可用性。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-apiserver | grep -v grep

验证 --disable-admission-plugins 参数是否设置为不包含 NamespaceLifecycle 的值。

修正： 默认情况下，RKE2 不使用此参数。无需手动修复。

1.2.16

确保 admission control 插件 NodeRestriction 已设置（自动）。

说明

使用 NodeRestriction 插件可确保 kubelet 仅限于其可以修改的 Node 和 Pod 对象。这些 kubelet 只允许修改它们自己的 Node API 对象，并且只修改绑定到它们节点的 Pod API 对象。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-apiserver | grep -v grep

验证 --enable-admission-plugins 参数是否设置为包含 NodeRestriction 的值。

修正： 默认情况下，RKE2 仅将 NodeRestriction 设置为 --enable-admission-plugins 参数的值。不需要手动修复。

1.2.17

确保 --secure-port 参数未设置为 0（自动化）。

说明

安全端口用于提供带有身份验证和授权的 https 服务。如果您禁用它，则不会提供 https 流量，所有流量将以未加密的方式提供。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-apiserver | grep -v grep

验证 --secure-port 参数是否未设置或设置为 1 到 65535 之间的整数值。

修正： 默认情况下，RKE2 将 --secure-port 参数设置为 6443。不需要手动修复。

1.2.18

确保 --profiling 参数设置为 false（自动化）。

说明

性能分析可以识别特定的性能瓶颈。它生成大量程序数据，这些数据可能被利用以揭示系统和程序的细节。如果您没有遇到任何瓶颈，并且不需要分析器进行故障排除，建议关闭它以减少潜在的攻击面。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-apiserver | grep -v grep

验证 --profiling 参数是否设置为 false。

修正： 默认情况下，RKE2 将 --profiling 标志参数设置为 false。不需要手动修复。

1.2.19

确保 --audit-log-path 参数已设置（自动化）。

说明

审计 Kubernetes API 服务器提供了一组与安全相关的时间顺序记录，记录了影响系统的活动序列，这些活动由单个用户、管理员或系统的其他组件执行。尽管目前 Kubernetes 仅提供基本的审计功能，但仍应启用它。您可以通过设置适当的审计日志路径来启用它。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-apiserver | grep -v grep

验证 --audit-log-path 参数是否设置正确。

修正： 默认情况下，RKE2 设置 --audit-log-path 参数和参数。不需要手动修复。

1.2.20

确保 --audit-log-maxage 参数设置为 30 或适当的值（自动化）。

说明

保留日志至少 30 天可确保您可以回溯并调查或关联任何事件。将您的审计日志保留期限设置为 30 天或根据您的业务需求。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-apiserver | grep -v grep

验证 --audit-log-maxage 参数是否设置为 30 或适当的值。

修正： 默认情况下，RKE2 将 --audit-log-maxage 参数设置为 30。不需要手动修复。

1.2.21

确保 --audit-log-maxbackup 参数设置为 10 或适当的值（自动化）。

说明

Kubernetes 会自动轮转日志文件。保留旧的日志文件可确保您有足够的日志数据可用于进行任何调查或关联。例如，如果您将文件大小设置为 100 MB，并将要保留的旧日志文件数量设置为 10，则您大约会有 1 GB 的日志数据可用于分析。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-apiserver | grep -v grep

验证 --audit-log-maxbackup 参数是否设置为 10 或适当的值。

修正： 默认情况下，RKE2 将 --audit-log-maxbackup 参数设置为 10。不需要手动修复。

1.2.22

确保 --audit-log-maxsize 参数设置为 100 或适当的值（自动化）。

说明

Kubernetes 会自动轮转日志文件。保留旧的日志文件可确保您有足够的日志数据可用于进行任何调查或关联。如果您将文件大小设置为 100 MB，并将要保留的旧日志文件数量设置为 10，则您大约会有 1 GB 的日志数据可用于分析。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-apiserver | grep -v grep

验证 --audit-log-maxsize 参数是否设置为 100 或适当的值。

修正： 默认情况下，RKE2 将 --audit-log-maxsize 参数设置为 100。不需要手动修复。

1.2.23

确保 --request-timeout 参数设置正确（自动化）。

说明

设置全局请求超时允许将 API 服务器请求超时限制扩展到适合用户连接速度的持续时间。默认情况下，它设置为 60 秒，这在较慢的连接上可能会出现问题，一旦请求的数据量超过 60 秒内可以传输的量，集群资源将无法访问。但是，将此超时限制设置得过大可能会耗尽 API 服务器资源，使其容易受到拒绝服务攻击。因此，建议适当设置此限制，仅在必要时更改默认限制 60 秒。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-apiserver | grep -v grep

验证 --request-timeout 参数是否未设置或设置为适当值。

修正： 默认情况下，RKE2 不设置 --request-timeout 参数。不需要手动修复。

1.2.24

确保 --service-account-lookup 参数设置为 true（自动化）。

说明

如果未启用 --service-account-lookup，apiserver 仅验证身份验证令牌是否有效，而不验证请求中提到的服务账户令牌是否实际存在于 etcd 中。这允许在相应的服务账户被删除后仍然使用服务账户令牌。这是一个检查时间到使用时间的安全问题示例。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-apiserver | grep -v grep

验证如果 --service-account-lookup 参数存在，则其设置为 true。

修正： 默认情况下，RKE2 不设置此参数，以便采用默认效果。不需要手动修复。

1.2.25

确保 --service-account-key-file 参数设置正确（自动化）。

说明

默认情况下，如果未向 apiserver 指定 --service-account-key-file，则使用 TLS 服务证书中的私钥来验证服务账户令牌。为了确保服务账户令牌的密钥可以根据需要进行轮换，应使用单独的公钥/私钥对来签署服务账户令牌。因此，公钥应通过 --service-account-key-file 指定给 apiserver。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-apiserver | grep -v grep

验证 --service-account-key-file 参数是否存在并设置为适当值。

修正： 默认情况下，RKE2 明确设置 --service-account-key-file 参数。不需要手动修复。

1.2.26

确保`--etcd-certfile`和`--etcd-keyfile`参数设置为适当值（自动化）。

说明

etcd是一个高可用的键值存储，用于Kubernetes部署的所有REST API对象的持久存储。这些对象本质上是敏感的，应通过客户端身份验证进行保护。这要求API服务器使用客户端证书和密钥向etcd服务器进行身份识别。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-apiserver | grep -v grep

验证 --etcd-certfile 和 --etcd-keyfile 参数是否存在，并且它们设置为适当值。

修正： 默认情况下，RKE2明确设置`--etcd-certfile`和`--etcd-keyfile`参数。不需要手动修复。

1.2.27

确保`--tls-cert-file`和`--tls-private-key-file`参数设置为适当值（自动化）。

说明

API服务器通信包含敏感参数，这些参数在传输过程中应保持加密。配置 API 服务器仅提供 HTTPS 流量。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-apiserver | grep -v grep

验证 --tls-cert-file 和 --tls-private-key-file 参数是否存在，并且它们设置为适当值。

修正： 默认情况下，RKE2明确设置`--tls-cert-file`和`--tls-private-key-file`参数。不需要手动修复。

1.2.28

确保`--client-ca-file`参数设置为适当值（自动化）。

说明

API服务器通信包含敏感参数，这些参数在传输过程中应保持加密。配置 API 服务器仅提供 HTTPS 流量。如果设置了 --client-ca-file 参数，则任何请求呈现的客户端证书由 client-ca-file 中的一个机构签署，将使用与客户端证书的 CommonName 对应的身份进行身份验证。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-apiserver | grep -v grep

验证 --client-ca-file 参数是否存在，并且检查其设置是否合适。

修正： 默认情况下，RKE2 明确设置 --client-ca-file 参数。不需要手动修复。

1.2.29

确保`--etcd-cafile`参数设置为适当值（自动化）。

说明

etcd是一个高可用的键值存储，用于Kubernetes部署的所有REST API对象的持久存储。这些对象本质上是敏感的，应通过客户端身份验证进行保护。这要求 API 服务器使用 SSL 证书颁发机构文件向 etcd 服务器进行身份识别。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-apiserver | grep -v grep

验证`--etcd-cafile`参数是否存在，并且设置是否合适。

修正： 默认情况下，RKE2 明确设置 --etcd-cafile 参数。不需要手动修复。

1.2.30

确保 --encryption-provider-config 参数设置正确（自动化）。

说明

etcd 是一个高可用的键值存储，用于 Kubernetes 部署的所有 REST API 对象的持久存储。这些对象本质上是敏感的，应在静态时加密以避免任何泄露。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-apiserver | grep -v grep

验证 --encryption-provider-config 参数是否设置为 EncryptionConfigfile。此外，确保 EncryptionConfigfile 覆盖所有所需的资源，特别是任何机密。

修正： 默认情况下，RKE2 明确设置 --encryption-provider-config 参数。不需要手动修复。RKE2 的默认加密提供程序配置文件位于 /var/lib/rancher/rke2/server/cred/encryption-config.json，并配置为加密机密。

1.2.31

确保加密提供程序配置正确（自动）。

说明

在使用 etcd 加密的情况下，确保使用适当的加密提供程序集非常重要。目前，aescbc、kms 和 secretbox 可能是合适的选项。

*结果：*通过

修正： 遵循 Kubernetes 文档并配置 EncryptionConfig 文件。在此文件中，选择 aescbc、kms 或 secretbox 作为加密提供程序。

Audit: 在主节点上运行以下命令。

grep aescbc /var/lib/rancher/rke2/server/cred/encryption-config.json

在主节点上运行以下命令。

验证 aescbc 是否设置为所有所需资源的加密提供程序。

补救措施 默认情况下，RKE2 明确设置了 --encryption-provider-config 参数及其相关配置。配置文件的内容表明使用了 aescbc。不需要手动修复。

1.2.32

确保 API 服务器仅使用强加密密码（手动）。

说明

TLS 密码存在许多已知的漏洞和弱点，这可能会降低它们提供的保护。默认情况下，Kubernetes 支持多种 TLS 密码套件，包括一些存在安全隐患的套件，这削弱了提供的保护。

结果：*手动 - 操作员依赖*

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-apiserver | grep -v grep

验证 --tls-cipher-suites 参数是否按照下面的修复程序进行设置。

修正： 默认情况下，RKE2 明确不设置此标志。不需要手动修复。

1.3 控制器管理器

1.3.1

确保 --terminated-pod-gc-threshold 参数设置得当（手动）。

说明

垃圾回收对于确保足够的资源可用性以及避免性能和可用性下降非常重要。在最坏的情况下，系统可能会崩溃或长时间无法使用。当前的垃圾回收设置为 12,500 个已终止的 Pod，这可能对您的系统来说过高。根据您的系统资源和测试，选择一个合适的阈值来激活垃圾回收。

结果：*手动 - 操作员依赖*

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-controller-manager | grep -v grep

验证 --terminated-pod-gc-threshold 参数是否设置正确。

修正： 默认情况下，RKE2 将 --terminated-pod-gc-threshold 参数设置为 1000。不需要手动修复。

1.3.2

确保 --profiling 参数设置为 false（自动化）。

说明

性能分析有助于识别特定的性能瓶颈。它生成大量程序数据，这些数据可能被利用以揭示系统和程序的细节。如果您没有遇到性能瓶颈，并且不需要性能分析器进行故障排除，建议关闭它以减少潜在的攻击面。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-controller-manager | grep -v grep

验证 --profiling 参数是否设置为 false。

修正： 默认情况下，RKE2 将 --profiling 标志参数设置为 false。不需要手动修复。

1.3.3

确保 --use-service-account-credentials 参数设置为 true（自动化）。

说明

控制器管理器在 kube-system 名称空间中为每个控制器创建一个服务账户，为其生成凭证，并为每个控制器循环构建一个使用该服务账户凭证的专用 API 客户端。将 --use-service-account-credentials 设置为 true 会使控制器管理器中的每个控制循环使用单独的服务账户凭证。与 RBAC 结合使用时，这确保控制循环以执行其预期任务所需的最小权限运行。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-controller-manager | grep -v grep

验证 --use-service-account-credentials 参数是否设置为 true。

修正： 默认情况下，RKE2 将 --use-service-account-credentials 参数设置为 true。不需要手动修复。

1.3.4

确保 --service-account-private-key-file 参数设置正确（自动化）。

说明

为了确保服务账户令牌的密钥可以根据需要进行轮换，应使用单独的公钥/私钥对来签署服务账户令牌。私钥应通过 --service-account-private-key-file 参数根据需要指定给控制器管理器。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-controller-manager | grep -v grep

验证 --service-account-private-key-file 参数是否设置正确。

修正： 默认情况下，RKE2 将 --service-account-private-key-file 参数设置为服务账户密钥文件。不需要手动修复。

1.3.5

确保 --root-ca-file 参数设置正确（自动化）。

说明

在 Pod 中运行的进程需要联系 API 服务器，必须验证 API 服务器的服务证书。未能做到这一点可能会成为中间人攻击的目标。

将 API 服务器的服务证书的根证书与 --root-ca-file 参数提供给控制器管理器，允许控制器管理器将受信任的证书包注入到 Pod 中，以便它们可以验证与 API 服务器的 TLS 连接。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-controller-manager | grep -v grep

验证 --root-ca-file 参数是否存在，并设置为包含 API 服务器服务证书的根证书的证书包文件。

修正： 默认情况下，RKE2 将 --root-ca-file 参数设置为根 CA 文件。不需要手动修复。

1.3.6

确保 RotateKubeletServerCertificate 参数设置为 true（自动化）。

说明

RotateKubeletServerCertificate 导致 kubelet 在引导其客户端凭据后请求服务证书，并在现有凭据过期时轮换证书。这种自动定期轮换确保没有因证书过期而导致的停机时间，从而解决了 CIA 安全三角中的可用性问题。

此建议仅适用于您让 kubelet 从 API 服务器获取证书的情况。如果您的 kubelet 证书来自外部机构/工具（例如 Vault），则需要自行处理轮换。

*结果：*不适用

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-controller-manager | grep -v grep

验证 RotateKubeletServerCertificate 参数是否存在并设置为 true。

修正： 默认情况下，RKE2 实现其自己的证书生成和轮换逻辑。

1.3.7

确保 --bind-address 参数设置为 127.0.0.1（自动化）。

说明

默认情况下，运行在 10252/TCP 端口上的控制器管理器 API 服务用于健康和指标信息，并且无需身份验证或加密即可访问。因此，它应仅绑定到 localhost 接口，以最小化集群的攻击面。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-controller-manager | grep -v grep

验证 --bind-address 参数是否设置为 127.0.0.1。

修正： 默认情况下，RKE2 将 --bind-address 参数设置为 127.0.0.1。不需要手动修复。

1.4 调度程序

本节包含与调度器配置标志相关的建议。

1.4.1

确保 --profiling 参数设置为 false（自动化）。

说明

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-scheduler | grep -v grep

验证 --profiling 参数是否设置为 false。

修正： 默认情况下，RKE2 将 --profiling 标志参数设置为 false。不需要手动修复。

1.4.2

确保 --bind-address 参数设置为 127.0.0.1（自动化）。

说明

默认情况下，运行在 10251/TCP 端口上的调度器 API 服务用于健康和指标信息，并且无需身份验证或加密即可访问。因此，它应仅绑定到 localhost 接口，以最小化集群的攻击面。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-scheduler | grep -v grep

验证 --bind-address 参数是否设置为 127.0.0.1。

修正： 默认情况下，RKE2 将 --bind-address 参数设置为 127.0.0.1。不需要手动修复。

2 Etcd 节点配置

本节涵盖 etcd 配置的建议。

2.1

确保 cert-file 和 key-file 字段设置为适当值（自动化）。

说明

etcd 是一个高可用的键值存储，用于 Kubernetes 部署中所有 REST API 对象的持久存储。这些对象本质上是敏感的，应在传输中加密。

*结果：*不适用

Audit: 在主节点上运行以下命令。

grep -E 'cert-file|key-file' /var/lib/rancher/rke2/server/db/etcd/config

验证 cert-file 和 key-file 字段是否设置为适当值。

修正： 默认情况下，RKE2 使用一个配置文件来配置 etcd，该文件可以在 /var/lib/rancher/rke2/server/db/etcd/config 找到。服务器和对等证书及密钥文件已指定。不需要手动修复。

2.2

确保 client-cert-auth 字段设置为 true（自动化）。

说明

etcd是一个高可用的键值存储，用于Kubernetes部署的所有REST API对象的持久存储。这些对象本质上是敏感的，不应对未认证的客户端开放。您应该通过有效证书启用客户端身份验证，以确保对 etcd 服务的访问安全。

*结果：*不适用

Audit: 在主节点上运行以下命令。

grep 'client-cert-auth' /var/lib/rancher/rke2/server/db/etcd/config

验证 client-cert-auth 字段是否设置为 true。

修正： 默认情况下，RKE2 使用一个配置文件来配置 etcd，该文件可以在 /var/lib/rancher/rke2/server/db/etcd/config 找到。client-cert-auth 设置为 true。不需要手动修复。

2.3

确保 auto-tls 字段未设置为 true（自动化）。

说明

etcd 是一个高可用的键值存储，用于 Kubernetes 部署的所有 REST API 对象的持久存储。这些对象本质上是敏感的，不应对未认证的客户端开放。您应该通过有效证书启用客户端身份验证，以确保对 etcd 服务的访问安全。

*结果：*通过

Audit: 在主节点上运行以下命令。

grep 'auto-tls' /var/lib/rancher/rke2/server/db/etcd/config

验证 auto-tls 字段是否不存在。

修正： 默认情况下，RKE2 使用一个用于 etcd 的配置文件，可在 /var/lib/rancher/rke2/server/db/etcd/config 找到。在该文件中不包含 auto-tls 参数。不需要手动修复。

2.4

确保 peer-cert-file 和 peer-key-file 字段设置为适当值（自动化）。

说明

etcd 是一个高可用的键值存储，用于 Kubernetes 部署的所有 REST API 对象的持久存储。这些对象本质上是敏感的，应该在传输过程中以及在 etcd 集群中的对等节点之间进行加密。

*结果：*不适用

Audit: 在主节点上运行以下命令。

grep -E 'peer-server-client.crt|peer-server-client.key' /var/lib/rancher/rke2/server/db/etcd/config

验证 peer-server-client.crt 和 peer-server-client.key 字段是否适当设置。

修正： 默认情况下，RKE2 使用一个用于 etcd 的配置文件，可在 /var/lib/rancher/rke2/server/db/etcd/config 找到。在文件中，peer-server-client.crt 和 peer-server-client.key 字段已设置。不需要手动修复。

2.5

确保 peer-client-cert-auth 参数设置为 true（自动化）。

说明

etcd 是一个高可用的键值存储，用于 Kubernetes 部署的所有 REST API 对象的持久存储。这些对象本质上是敏感的，应该仅由 etcd 集群中的经过认证的 etcd 对等节点访问。

*结果：*不适用

Audit: 在主节点上运行以下命令。

grep 'peer-client-cert-auth' /var/lib/rancher/rke2/server/db/etcd/config

验证对等部分中的 peer-client-cert-auth 字段是否设置为 true。

修正： 默认情况下，RKE2 使用一个用于 etcd 的配置文件，可在 /var/lib/rancher/rke2/server/db/etcd/config 找到。在文件中，client-cert-auth 字段已设置。不需要手动修复。

2.6

确保 peer-auto-tls 字段未设置为 true（自动化）。

说明

etcd 是一个高可用的键值存储，用于 Kubernetes 部署的所有 REST API 对象的持久存储。这些对象本质上是敏感的，应该仅由 etcd 集群中的经过认证的 etcd 对等节点访问。因此，不要使用自签名证书进行身份验证。

*结果：*通过

Audit: 在主节点上运行以下命令。

grep 'peer-auto-tls' /var/lib/rancher/rke2/server/db/etcd/config

验证 peer-auto-tls 字段是否不存在。

修正： 默认情况下，RKE2 使用一个用于 etcd 的配置文件，可在 /var/lib/rancher/rke2/server/db/etcd/config 找到。在该文件中不包含 peer-auto-tls 字段。不需要手动修复。

2.7

确保为 etcd 使用唯一的证书颁发机构（手动）。

说明

etcd 是一个高可用的键值存储，用于 Kubernetes 部署的所有 REST API 对象的持久存储。其访问应仅限于特定的客户端和对等节点。

etcd的身份验证基于所提供的证书是否由受信任的证书颁发机构签发。不检查证书属性，如通用名称或主题备用名称。因此，如果任何攻击者能够获得受信任的证书颁发机构签发的任何证书，他们就能完全访问 etcd 数据库。

*结果：*通过

Audit: 在主节点上运行以下命令。

# To find the ca file used by etcd:
grep 'trusted-ca-file' /var/lib/rancher/rke2/server/db/etcd/config
# To find the kube-apiserver process:
/bin/ps -ef | grep kube-apiserver | grep -v grep

验证 apiserver 进程中 client-ca-file 标志所引用的文件与 etcd 配置文件中 trusted-ca-file 参数所引用的文件是否不同。

修正： 默认情况下，RKE2 使用一个用于 etcd 的配置文件，位于 /var/lib/rancher/rke2/server/db/etcd/config，其中 trusted-ca-file 参数被设置为特定于 etcd 的唯一值。不需要手动修复。

3 控制平面配置

3.1 身份验证和授权

3.1.1

不应对用户使用客户端证书身份验证（手动）。

说明

对于任何身份验证机制，能够在凭据泄露或不再需要时撤销凭据是一项关键控制。Kubernetes 客户端证书身份验证由于缺乏对证书撤销的支持而不允许这样做。

*结果：*手动 - 操作员依赖

Audit: 审查用户对集群的访问权限，确保用户不使用 Kubernetes 客户端证书身份验证。

修正： Kubernetes 提供的替代机制，如 OIDC 的使用，应该用来替换客户端证书身份验证。

3.2 日志记录

3.2.1

确保创建最小审计策略（自动化）。

说明

日志记录是所有系统的重要检测控制，用于检测潜在的未经授权的访问。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kube-apiserver | grep -v grep

验证 --audit-policy-file 是否已设置。审查指定文件的内容，确保其包含有效的审计策略。

修正： 为您的集群创建审计策略文件。

3.2.2

确保审计策略涵盖关键安全问题（手动）。

说明

安全审计日志应涵盖对集群中关键资源的访问和修改，以使其能够有效地成为安全环境的一部分。

*结果：*手动 - 操作员依赖

修正：

4 工作节点安全配置

4.1 工作节点配置文件

4.1.1

确保 kubelet 服务文件权限设置为 644 或更严格（自动化）。

说明

kubelet 服务文件控制着在工作节点中设置 kubelet 服务行为的各种参数。您应该限制其文件权限以维护文件的完整性。该文件应仅由系统上的管理员可写。

*结果：*不适用

修正： RKE2 不将 kubelet 作为服务启动。它由 RKE2 监督进程启动和管理。所有配置在运行时作为命令行参数传递给它。

4.1.2

确保 kubelet 服务文件的所有权设置为 root:root（自动化）。

说明

kubelet 服务文件控制着在工作节点中设置 kubelet 服务行为的各种参数。您应该设置其文件所有权以维护文件的完整性。该文件应由 root:root 拥有。

*结果：*不适用

修正： RKE2 不将 kubelet 作为服务启动。它由 RKE2 监督进程启动和管理。所有配置在运行时作为命令行参数传递给它。

4.1.3

确保代理 kubeconfig 文件权限设置为 644 或更严格（手动）。

说明

kube-proxy kubeconfig 文件控制着在工作节点中 kube-proxy 服务的各种参数。您应该限制其文件权限以维护文件的完整性。该文件应仅由系统上的管理员可写。

可以使用配置为 Kubernetes ConfigMap 的 kubeconfig 参数来运行 kube-proxy，而非使用文件。在这种情况下，没有代理 kubeconfig 文件。

*结果：*通过

Audit: 在工作节点上运行以下命令。

stat -c %a /var/lib/rancher/rke2/server/manifests/rke2-kube-proxy.yaml
644

验证如果指定了文件并且它存在，则权限为 644 或更严格。

修正： 默认情况下，RKE2 创建 rke2-kube-proxy.yaml，权限为 644。无需手动修复。

4.1.4

确保代理 kubeconfig 文件的所有权设置为 root:root（手动）。

说明

kube-proxy 的 kubeconfig 文件控制着在工作节点中 kube-proxy 服务的各种参数。您应该设置其文件所有权以维护文件的完整性。该文件应由 root:root 拥有。

*结果：*通过

Audit: 在主节点上运行以下命令。

stat -c %U:%G /var/lib/rancher/rke2/server/manifests/rke2-kube-proxy.yaml
root:root

验证如果指定了文件并且它存在，则权限为 644 或更严格。

修正： 默认情况下，RKE2 创建 rke2-kube-proxy.yaml，并具有 root:root 的所有权。无需手动修复。

4.1.5

确保 kubelet.conf 文件权限设置为 644 或更严格（自动化）。

说明

kubelet.conf 文件是节点的 kubeconfig 文件，控制设置工作节点行为和身份的各种参数。您应该限制其文件权限以维护文件的完整性。该文件应仅由系统上的管理员可写。

*结果：*不适用

Audit: 在工作节点上运行以下命令。

stat -c %a /var/lib/rancher/rke2/agent/kubelet.kubeconfig
644

修正： 默认情况下，RKE2 创建 kubelet.kubeconfig，权限为 644。无需手动修复。

4.1.6

确保 kubelet.conf 文件的所有权设置为 root:root（手动）。

说明

kubelet.conf 文件是节点的 kubeconfig 文件，控制设置工作节点行为和身份的各种参数。您应该设置其文件所有权以维护文件的完整性。该文件应由 root:root 拥有。

*结果：*不适用

Audit: 在主节点上运行以下命令。

stat -c %U:%G /var/lib/rancher/rke2/agent/kubelet.kubeconfig
root:root

修正： 默认情况下，RKE2 创建 kubelet.kubeconfig，并具有 root:root 的所有权。无需手动修复。

4.1.7

确保证书颁发机构文件权限设置为 644 或更严格（手动）。

说明

证书颁发机构文件控制用于验证 API 请求的权限。您应该限制其文件权限以维护文件的完整性。该文件应仅由系统上的管理员可写。

*结果：*手动 - 操作员依赖

Audit: 在主节点上运行以下命令。

stat -c %a /var/lib/rancher/rke2/server/tls/server-ca.crt
644

验证权限是否为 644。

修正： 默认情况下，RKE2 创建 /var/lib/rancher/rke2/server/tls/server-ca.crt，并具有 644 的权限。

4.1.8

确保客户端证书颁发机构文件的所有权设置为 root:root（自动化）。

说明

证书颁发机构文件控制用于验证 API 请求的权限。您应该设置其文件所有权以维护文件的完整性。该文件应由 root:root 拥有。

*结果：*通过

Audit: 在主节点上运行以下命令。

stat -c %U:%G /var/lib/rancher/rke2/server/tls/client-ca.crt
root:root

修正： 默认情况下，RKE2 创建 /var/lib/rancher/rke2/server/tls/client-ca.crt，并具有 root:root 的所有权。

4.1.9

确保 kubelet 配置文件的权限设置为 600 或更严格（自动化）。

说明

kubelet 从由 --config 参数指定的配置文件中读取各种参数，包括安全设置。如果指定了此文件，您应限制其文件权限以维护文件的完整性。该文件应仅由系统上的管理员可写。

*结果：*不适用

修正： RKE2 不需要也不维护 kubelet 进程的配置文件。所有配置在运行时作为命令行参数传递给它。

4.1.10

确保 kubelet 配置文件的所有权设置为 root:root（自动化）。

说明

kubelet 从由 --config 参数指定的配置文件中读取各种参数，包括安全设置。如果指定了此文件，您应限制其文件权限以维护文件的完整性。该文件应由`root:root`拥有。

*结果：*不适用

修正： RKE2 不需要也不维护 kubelet 进程的配置文件。所有配置在运行时作为命令行参数传递给它。

4.2 Kubelet

本节包含 kubelet 配置的建议。

4.2.1

确保 --anonymous-auth 参数设置为 false（自动化）。

说明

启用后，未被其他配置的身份验证方法拒绝的请求将被视为匿名请求。这些请求随后由 Kubelet 服务器处理。您应依赖身份验证来授权访问并禁止匿名请求。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kubelet | grep -v grep

验证 --anonymous-auth 的值是否为 false。

修正： 默认情况下，RKE2 启动 kubelet 时将 --anonymous-auth 设置为 false。无需手动修复。

4.2.2

确保 --authorization-mode 参数未设置为 AlwaysAllow（自动化）。

说明

默认情况下，Kubelet 允许所有经过身份验证的请求（即使是匿名请求），而无需 apiserver 的明确授权检查。您应限制此行为，仅允许明确授权的请求。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kubelet | grep -v grep

验证 AlwaysAllow 是否不存在。

修正： RKE2 启动 kubelet 时将 Webhook 作为 --authorization-mode 参数的值。无需手动修复。

4.2.3

确保 --client-ca-file 参数设置正确（自动化）。

说明

apiserver 与 kubelet 之间的连接用于获取 pod 的日志、通过 kubectl 附加到运行中的 pod，以及使用 kubelet 的端口转发功能。这些连接在 kubelet 的 HTTPS 端点终止。默认情况下，apiserver 不验证 kubelet 的服务证书，这使得连接容易受到中间人攻击，并且在不受信任和/或公共网络上运行不安全。启用 Kubelet 证书身份验证可确保 apiserver 在提交任何请求之前能够验证 Kubelet。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kubelet | grep -v grep

验证 --client-ca-file 参数是否关联了 ca 文件。

修正： 默认情况下，RKE2 启动 kubelet 进程时使用 --client-ca-file。无需手动修复。

4.2.4

确保 --read-only-port 参数设置为 0（自动化）。

说明

Kubelet 进程提供了一个只读 API，除了主要的 Kubelet API。此只读 API 提供未经身份验证的访问，可能会检索有关集群的潜在敏感信息。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kubelet | grep -v grep

验证 --read-only-port 参数是否设置为 0。

修正： 默认情况下，RKE2 启动 kubelet 进程时将 --read-only-port 参数设置为 0。

4.2.5

确保 --streaming-connection-idle-timeout 参数未设置为 0（自动化）。

说明

设置空闲超时可以确保您免受拒绝服务攻击、非活动连接和耗尽临时端口的影响。

默认情况下，--streaming-connection-idle-timeout 设置为 4 小时，这可能对您的环境来说过高。适当地设置此项还可以确保在满足合法用例后，这些流式连接会超时。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kubelet | grep -v grep

验证没有返回任何内容。

修正： 默认情况下，RKE2 在启动 kubelet 时不设置 --streaming-connection-idle-timeout。

4.2.6

确保 --protect-kernel-defaults 参数设置为 true（自动化）。

说明

内核参数通常在将系统投入生产之前由系统管理员进行调整和加固。这些参数保护内核和系统。依赖这些参数的 kubelet 内核默认值应适当地设置，以匹配所需的安全系统状态。忽略这一点可能会导致运行的 pod 出现不希望的内核行为。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kubelet | grep -v grep

修正： 当使用 profile 标志设置为 cis-1.23 时，RKE2 启动 kubelet 进程时将 --protect-kernel-defaults 参数设置为 true。

4.2.7

确保 --make-iptables-util-chains 参数设置为 true（自动化）。

说明

Kubelets 可以根据您为 pod 选择的网络选项自动管理对 iptables 的必要更改。建议让 kubelet 管理对 iptables 的更改。这确保了 iptables 配置与 pod 网络配置保持同步。手动配置 iptables 与动态 pod 网络配置更改可能会妨碍 pod/容器之间以及与外部世界的通信。您的 iptables 规则可能过于严格或过于宽松。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kubelet | grep -v grep

验证没有返回结果。

修正： 默认情况下，RKE2 不设置 --make-iptables-util-chains 参数。无需手动修复。

4.2.8

确保 --hostname-override 参数未设置（手动）。

说明

覆盖主机名可能会破坏 kubelet 和 apiserver 之间的 TLS 设置。此外，使用覆盖的主机名，越来越难以将日志与特定节点关联并进行安全分析。因此，您应该为 kubelet 节点设置可解析的 FQDN，并避免用 IP 覆盖主机名。

*结果：*不适用

修正： RKE2 为每个主机设置此参数，但 RKE2 还管理集群中的所有证书。它确保 hostname-override 被包含为 kubelet 证书中的主题备用名称 (SAN)。

4.2.9

确保 --event-qps 参数设置为 0 或确保适当事件捕获的级别（手动）。

说明

捕获所有事件而不限制事件创建是很重要的。事件是安全信息和分析的重要来源，确保您的环境始终使用事件数据进行监控。

*结果：*手动 - 操作员依赖

修正： 有关配置此项的更多详细信息，请参见 CIS 基准指南。

4.2.10

确保 --tls-cert-file 和 --tls-private-key-file 参数设置为适当值（自动化）。

说明

Kubelet 通信包含敏感参数，这些参数在传输过程中应保持加密。配置 Kubelet 仅提供 HTTPS 流量。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kubelet | grep -v grep

验证 --tls-cert-file 和 --tls-private-key-file 参数是否存在并设置正确。

修正： 默认情况下，RKE2 在执行 kubelet 进程时设置 --tls-cert-file 和 --tls-private-key-file 参数。

4.2.11

确保 --rotate-certificates 参数未设置为 false（手动）。

说明

--rotate-certificates 设置导致 kubelet 通过创建新的 CSR 来轮换其客户端证书，因为其现有凭据过期。这种自动定期轮换确保由于证书过期而不会出现停机，从而解决了 CIA 安全三角中的可用性问题。

此建议仅适用于您让 kubelet 从 API 服务器获取证书的情况。如果您的 kubelet 证书来自外部机构/工具（例如 Vault），则需要自行处理轮换。

此功能还需要启用 RotateKubeletClientCertificate 功能开关（自 Kubernetes v1.7 起为默认设置）。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kubelet | grep -v grep

修正： 默认情况下，RKE2 实现了自己的证书生成和轮换逻辑。

4.2.12

确保 RotateKubeletServerCertificate 参数设置为 true（手动）。

说明

RotateKubeletServerCertificate 使 kubelet 在引导其客户端凭据后请求服务证书，并在现有凭据过期时轮换证书。这种自动化的定期轮换确保不会因证书过期而导致停机，从而解决了 CIA 安全三角中的可用性问题。

此建议仅适用于您让 kubelet 从 API 服务器获取证书的情况。如果您的 kubelet 证书来自外部机构/工具（例如 Vault），则需要自行处理轮换。

*结果：*通过

Audit: 在主节点上运行以下命令。

/bin/ps -ef | grep kubelet | grep -v grep

修正： 默认情况下，RKE2 实现了自己的证书生成和轮换逻辑。

4.2.13

确保 Kubelet 仅使用强加密密码（手动）。

说明

TLS 密码套件存在许多已知的漏洞和弱点，这可能会降低其提供的保护。默认情况下，Kubernetes 支持多种 TLS 密码套件，包括一些存在安全隐患的密码套件，削弱了提供的保护。

*结果：*手动 - 操作员依赖

修正： 参数的配置取决于您的使用案例。请参阅 CIS Kubernetes 基准以获取有关为您的使用案例配置的建议。

5 Kubernetes 策略

5.1 RBAC 和服务账户

5.1.1

确保 cluster-admin 角色仅在需要时使用（手动）。

说明

Kubernetes 提供了一组默认角色，其中使用了 RBAC。其中一些角色，如 cluster-admin，提供广泛的权限，仅应在绝对必要时应用。像 cluster-admin 这样的角色允许超级用户访问以对任何资源执行任何操作。在 ClusterRoleBinding 中使用时，它对集群中的每个资源和所有名称空间具有完全控制权。在 RoleBinding 中使用时，它对角色绑定的名称空间中的每个资源，包括名称空间本身，具有完全控制权。

*结果：*通过

修正： RKE2 不会不当使用 cluster-admin 角色。操作员必须审计其工作负载的额外使用情况。有关更多详细信息，请参阅 CIS 基准指南。

5.1.2

最小化对机密的访问（手动）。

说明

不当访问存储在 Kubernetes 集群中的机密可能允许攻击者获得对 Kubernetes 集群或存储为机密的外部资源的额外访问权限。

*结果：*手动 - 操作员依赖

修正： RKE2 适当地限制了系统组件对机密的使用，但操作员必须审计其工作负载对机密的使用。有关更多详细信息，请参阅 CIS 基准指南。

5.1.3

最小化角色和集群角色中的通配符使用（手动）。

说明

最小权限原则建议用户仅获得其角色所需的访问权限，而不多于此。使用通配符权限授予可能会向 Kubernetes API 提供过多的权限。

*结果：*手动 - 操作员依赖

Audit: 在主节点上运行以下命令。

# Retrieve the roles defined across each namespaces in the cluster and review for wildcards
/var/lib/rancher/rke2/bin/kubectl get roles --all-namespaces -o yaml

# Retrieve the cluster roles defined in the    cluster    and    review for wildcards
/var/lib/rancher/rke2/bin/kubectl get clusterroles -o yaml

验证是否没有使用通配符。

修正： 操作员应审查其工作负载以确保正确使用角色。有关更多详细信息，请参阅 CIS 基准指南。

5.1.4

最小化对创建 Pod 的访问（手动）。

说明

在集群中创建 Pod 的能力为权限提升打开了可能性，应在可能的情况下加以限制。

*结果：*手动 - 操作员依赖

修正： 操作员应审查谁有权在其集群中创建 Pod。有关更多详细信息，请参阅 CIS 基准指南。

5.1.5

确保默认服务账户未被积极使用。（自动化）。

说明

Kubernetes 提供了一个默认服务账户，用于没有特定服务账户分配给 Pod 的集群工作负载。

当 Pod 需要访问 Kubernetes API 时，应为该 Pod 创建一个特定的服务账户，并授予该服务账户权限。

默认服务账户应配置为不提供服务账户令牌，并且没有任何明确的权限分配。

*结果：*通过。

Audit: 对于集群中的每个命名空间，审查分配给默认服务账户的权限，并确保除了默认权限外没有绑定任何角色或集群角色。此外，确保每个默认服务账户都设置了 automountServiceAccountToken: false。

修正： 在 Kubernetes 工作负载需要特定访问 Kubernetes API 服务器的地方创建显式服务账户。修改每个默认服务账户的配置以包含此值。

automountServiceAccountToken: false

5.1.6

确保服务账户令牌仅在必要时挂载（手动）。

说明

在 Pod 内挂载服务账户令牌可能为权限提升攻击提供途径，攻击者能够破坏集群中的单个 Pod。

避免挂载这些令牌可以消除这一攻击途径。

*结果：*手动 - 操作员依赖

修正： 由 RKE2 启动的 Pod 是控制平面的一部分，通常需要访问以与 API 服务器进行通信，因此此控制不适用于它们。操作员应审查其工作负载，并采取措施修改不需要挂载服务账户令牌的 Pod 和服务账户的定义，以禁用该功能。

5.1.7

避免使用 system:masters 组（手动）。

说明

system:masters 组对 Kubernetes API 具有不受限制的访问权限，这一权限被硬编码在 API 服务器源代码中。作为该组成员的经过身份验证的用户，其访问权限无法降低，即使提到该组的所有绑定和集群角色绑定被删除。

当与客户端证书身份验证结合使用时，使用该组可以使集群存在不可撤销的集群管理员级别凭据。

*结果：*手动 - 依赖操作员

修正： 从集群中的所有用户中去除 system:masters 组。

5.1.7

限制在 Kubernetes 集群中使用 Bind、Impersonate 和 Escalate 权限（手动）。

说明

冒充特权允许主体冒充其他用户，从而获得他们在集群中的权限。绑定特权允许主体向集群角色或角色添加绑定，从而提升他们在集群中的有效权限。提升特权允许主体修改他们绑定的集群角色，从而增加他们的权限级别。

*结果：*手动 - 依赖操作员

修正： 在可能的情况下，从主体中去除 impersonate、bind 和 escalate 权利。

5.2 Pod 安全标准

5.2.1

确保集群中至少有一个活动的策略控制机制（手动）。

说明

没有活动的策略控制机制，无法通过特权容器或使用 hostPath 卷挂载来限制对底层集群节点的容器访问。

*结果：*手动 - 依赖操作员

修正： PSA 从 v1.23 开始在 RKE2 中默认启用，无需补救。

5.2.2

最小化特权容器的准入（手动）。

说明

在主机的 PID 命名空间中运行的容器可以检查容器外部运行的进程。如果容器还具有访问 ptrace 能力，则可以利用此能力在容器外提升权限。

应定义至少一个不允许容器共享主机 PID 命名空间的 PodSecurityPolicy (PSP)。

如果需要运行需要 hostPID 的容器，应在单独的 PSP 中定义，并仔细检查 RBAC 控制，以确保只有有限的服务账户和用户被授予访问该 PSP 的权限。

*结果：*通过

Audit: 在主节点上运行以下命令，以确保配置文件中启用了限制级别。

config_file=$(ps aux | grep kube-apiserver |  grep -- --admission-control-config-file | sed 's%.*admission-control-config-file[= ]\([^ ]*\).*%\1%')

grep "enforce:" ${config_file}

验证返回的值为 enforce: restricted

修正： 为集群中每个包含用户工作负载的名称空间添加策略，以限制特权容器的准入。

5.2.3

最小化希望共享主机进程 ID 命名空间的容器的准入（自动化）。

说明

在主机的 PID 命名空间中运行的容器可以检查容器外部运行的进程。如果容器还具有访问 ptrace 能力，则可以利用此能力在容器外提升权限。

应定义至少一个不允许容器共享主机 PID 命名空间的准入控制策略。

如果需要运行需要 hostPID 的容器，应在单独的策略中定义，并仔细检查以确保只有有限的服务帐户和用户被授权使用该策略。

*结果：*通过

Audit: 在主节点上运行以下命令。

config_file=$(ps aux | grep kube-apiserver |  grep -- --admission-control-config-file | sed 's%.*admission-control-config-file[= ]\([^ ]*\).*%\1%')

grep "enforce:" ${config_file}

验证返回的值为 enforce: restricted

修正： 为集群中每个包含用户工作负载的名称空间添加策略，以限制特权容器的准入。

5.2.4

最小化希望共享主机 IPC 命名空间的容器的准入（自动化）。

说明

在主机的 IPC 命名空间中运行的容器可以使用 IPC 与容器外部的进程进行交互。

应定义至少一个不允许容器共享主机 IPC 命名空间的准入控制策略。

如果需要运行需要 hostIPC 的容器，应在单独的策略中定义，并仔细检查以确保只有有限的服务帐户和用户被授权使用该策略。

*结果：*通过

Audit: 在主节点上运行以下命令。

config_file=$(ps aux | grep kube-apiserver |  grep -- --admission-control-config-file | sed 's%.*admission-control-config-file[= ]\([^ ]*\).*%\1%')

grep "enforce:" ${config_file}

验证返回的值为 enforce: restricted

修正： 为集群中每个包含用户工作负载的名称空间添加策略，以限制特权容器的准入。

5.2.5

最小化希望共享主机网络命名空间的容器的准入（自动化）。

说明

在主机的网络命名空间中运行的容器可以访问本地环回设备，并可以访问与其他 Pod 之间的网络流量。

应定义至少一个不允许容器共享主机网络命名空间的准入控制策略。

如果需要运行需要访问主机网络命名空间的容器，应在单独的策略中定义，并仔细检查以确保只有有限的服务帐户和用户被授权使用该策略。

*结果：*通过

Audit: 在主节点上运行以下命令。

config_file=$(ps aux | grep kube-apiserver |  grep -- --admission-control-config-file | sed 's%.*admission-control-config-file[= ]\([^ ]*\).*%\1%')

grep "enforce:" ${config_file}

验证返回的值为 enforce: restricted

修正： 为集群中每个包含用户工作负载的名称空间添加策略，以限制 hostNetwork 容器的准入。

5.2.6

最小化具有 allowPrivilegeEscalation 的容器的准入（自动化）。

说明

运行时将 allowPrivilegeEscalation 标志设置为 true 的容器可能会包含能够获得比其父进程更多权限的进程。

应定义至少一个不允许容器进行特权提升的准入控制策略。存在允许运行 setuid 二进制文件的选项（默认为 true）。

如果需要运行使用 setuid 二进制文件或需要特权提升的容器，应在单独的策略中定义，并仔细检查以确保只有有限的服务帐户和用户被授权使用该策略。

*结果：*通过

Audit: 在主节点上运行以下命令。

config_file=$(ps aux | grep kube-apiserver |  grep -- --admission-control-config-file | sed 's%.*admission-control-config-file[= ]\([^ ]*\).*%\1%')

grep "enforce:" ${config_file}

验证返回的值为 enforce: restricted。

修正： 为集群中每个包含用户工作负载的名称空间添加策略，以限制 .spec.allowPrivilegeEscalationset 被设置为 true 的容器的准入。

5.2.7

最小化 root 容器的准入（自动化）。

说明

容器可以作为任何 Linux 用户运行。作为 root 用户运行的容器，尽管受到容器运行时安全特性的限制，但仍然有更高的容器突破风险。

理想情况下，所有容器应作为定义的非 UID 0 用户运行。

应定义至少一个不允许 root 容器的准入控制策略。

如果需要运行 root 容器，应在单独的策略中定义，并仔细检查以确保只有有限的服务账户和用户被授权使用该策略。

*结果：*通过

Audit: 在主节点上运行以下命令。

config_file=$(ps aux | grep kube-apiserver |  grep -- --admission-control-config-file | sed 's%.*admission-control-config-file[= ]\([^ ]*\).*%\1%')

grep "enforce:" ${config_file}

验证返回的值为 enforce: restricted

修正： 为集群中的每个名称空间创建一个策略，确保`MustRunAsNonRoot`或`MustRunAs`的 UID 范围不包括 0。

5.2.8

最小化具有 NET_RAW 能力的容器的准入（自动化）。

说明

容器以容器运行时分配的默认能力集运行。默认情况下，这可能包括潜在危险的能力。使用 Docker 作为容器运行时，启用了 NET_RAW 能力，这可能被恶意容器滥用。

理想情况下，所有容器应放弃此能力。

应定义至少一个不允许具有 NET_RAW 能力的容器的准入控制策略。

如果需要运行具有此能力的容器，应在单独的策略中定义，并仔细检查以确保只有有限的服务账户和用户被授权使用该策略。

*结果：*通过

Audit: 在主节点上运行以下命令。

config_file=$(ps aux | grep kube-apiserver |  grep -- --admission-control-config-file | sed 's%.*admission-control-config-file[= ]\([^ ]*\).*%\1%')

grep "enforce:" ${config_file}

验证返回的值为 enforce: restricted。

修正： 为集群中每个包含用户工作负载的名称空间添加策略，以限制具有`NET_RAW`能力的容器的准入。

5.2.9

最小化具有附加能力的容器的准入（自动化）。

说明

容器以容器运行时分配的默认能力集运行。可以将此集合之外的能力添加到容器中，这可能使其面临容器突破攻击的风险。

应定义至少一个策略，防止具有超出默认集合的能力的容器启动。

如果您需要运行具有额外能力的容器，则应在单独的策略中定义，并应仔细检查以确保只有有限的服务帐户和用户被授权使用该策略。

*结果：*手动

修正： 确保在集群的策略中不包含`allowedCapabilities`，除非将其设置为空数组。

5.2.10

最小化对已分配能力的容器的准入（手动）。

说明

容器以容器运行时分配的默认能力集运行。能力是通常授予 Linux 系统中 root 用户的权限的一部分。

在许多情况下，运行在容器中的应用程序不需要任何能力来运行，因此从最小权限原则的角度来看，应该尽量减少能力的使用。

*结果：*手动

修正： 审查在您的集群上运行的应用程序中能力的使用。如果一个名称空间中包含不需要任何 Linux 能力来运行的应用程序，请考虑添加一个 PSP，禁止未丢弃所有能力的容器的准入。

5.2.11

最小化 Windows HostProcess 容器的准入（手动）。

说明

容器以容器运行时分配的默认能力集运行。能力是通常授予 Linux 系统中 root 用户的权限的一部分。

在许多情况下，运行在容器中的应用程序不需要任何能力来运行，因此从最小权限原则的角度来看，应该尽量减少能力的使用。

*结果：*手动

修正： 为集群中每个包含用户工作负载的名称空间添加策略，以限制`.securityContext.windowsOptions.hostProcess`设置为`true`的容器的准入。

5.2.12

最小化 HostPath 卷的准入（手动）。

说明

作为其规范的一部分，挂载 hostPath 卷的容器将能够访问底层集群节点的文件系统。使用 hostPath 卷可能允许容器访问节点文件系统的特权区域。

应定义至少一个不允许容器挂载 hostPath 卷的准入控制策略。

如果您需要运行需要 hostPath 卷的容器，则应在单独的策略中定义，并应仔细检查以确保只有有限的服务帐户和用户被授权使用该策略。

*结果：*手动

修正： 为集群中每个包含用户工作负载的名称空间添加策略，以限制具有`hostPath`卷的容器的准入。

5.2.13

最小化使用 HostPorts 的容器的准入（手动）。

说明

主机端口将容器直接连接到主机的网络。这可能会绕过网络策略等控制。

应定义至少一个不允许需要使用 HostPorts 的容器的准入控制策略。

如果您需要运行需要 HostPorts 的容器，则应在单独的策略中定义，并应仔细检查以确保只有有限的服务帐户和用户被授权使用该策略。

*结果：*手动

修正： 为集群中具有用户工作负载的每个名称空间添加策略，以限制使用 hostPort 部分的容器的准入。

5.3 网络策略和 CNI

5.3.1

确保所使用的 CNI 支持网络策略（自动化）。

说明

Kubernetes 网络策略由所使用的 CNI 插件强制执行。因此，确保 CNI 插件支持入站和出站网络策略非常重要。

*结果：*通过

Audit: 查看集群中所使用的 CNI 插件的文档，并确认其支持入站和出站网络策略。

修正： 默认情况下，RKE2 使用 Canal（Calico 和 Flannel），并完全支持网络策略。

5.3.2

确保所有名称空间都定义了网络策略（自动化）。

说明

在同一个 Kubernetes 集群上运行不同的应用程序会增加一个被攻陷的应用程序攻击邻近应用程序的风险。网络分段对于确保容器只能与预期通信对象进行通信非常重要。网络策略规范了如何允许选定的 Pod 之间及与其他网络端点之间通信。

网络策略是以名称空间为范围的。当网络策略被引入到特定名称空间时，所有未被策略允许的流量将被拒绝。然而，如果在某个名称空间中没有网络策略，则所有流量都将被允许进出该名称空间中的 Pod。

*结果：*通过

Audit: 在主节点上运行以下命令。

for i in kube-system kube-public default; do
    /var/lib/rancher/rke2/bin/kubectl get networkpolicies -n $i;
done

验证每个名称空间中是否应用了网络策略。

修正： 当使用 --profile=cis-1.23 参数执行 RKE2 时，会应用一个安全的网络策略，该策略仅允许名称空间内的流量和对 kube-system 的 DNS 访问。无需手动修复。

5.4 秘密管理

5.4.1

优先使用文件形式的秘密而不是环境变量形式的秘密（手动）。

说明

应用程序代码记录其环境（特别是在发生错误时）是相当常见的。这将包括作为环境变量传入的任何秘密值，因此秘密可能会轻易暴露给任何有权访问日志的用户或实体。

*结果：*手动

Audit: 运行以下命令以查找使用从秘密中定义的环境变量的对象的引用。

/var/lib/rancher/rke2/bin/kubectl get all -o jsonpath='{range .items[?(@..secretKeyRef)]} {.kind} {.metadata.name} {"\n"}{end}' -A

修正： 如果可能，重写应用程序代码以从挂载的秘密文件中读取秘密，而不是从环境变量中读取。

5.4.2

考虑使用外部秘密存储（手动）。

说明

Kubernetes 将秘密视为一等公民对象，但需要小心确保对秘密的访问受到严格限制。使用外部秘密提供者可以简化对秘密的访问管理，特别是在秘密在 Kubernetes 和非 Kubernetes 环境中都被使用的情况下。

*结果：*手动

Audit: 审查您的秘密管理实施。

修正： 请参考您的云服务提供商或第三方秘密管理解决方案所提供的秘密管理选项。

5.5 可扩展的准入控制

5.5.1

使用 ImagePolicyWebhook 准入控制器配置图像溯源（手动）。

说明

Kubernetes 支持插入溯源规则以接受或拒绝您部署中的镜像。您可以配置这些规则，以确保仅批准的镜像在集群中部署。

*结果：*手动

Audit: 审查您集群中的 Pod 定义，并验证图像溯源是否已适当配置。

修正： 遵循Kubernetes文档并设置镜像溯源。

5.6 已忽略

v1.23 指南跳过 5.6，直接从 5.5 跳到 5.7。我们在这里包含它仅仅是为了说明。

5.7 一般策略

这些策略与集群管理的一般主题相关，例如名称空间最佳实践以及针对集群中 Pod 对象的策略。

5.7.1

使用名称空间在资源之间创建管理边界（手动）。

说明

限制用户权限的范围可以减少错误或恶意活动的影响。Kubernetes 名称空间允许您将创建的资源分区为逻辑命名的组。在一个名称空间中创建的资源可以对其他名称空间不可见。默认情况下，Kubernetes 集群中用户创建的每个资源都在一个名为 default 的默认名称空间中运行。您可以创建额外的名称空间，并将资源和用户附加到它们。您可以使用 Kubernetes 授权插件创建策略，以在不同用户之间隔离对名称空间资源的访问。

*结果：*手动

Audit: 运行以下命令并审查集群中创建的名称空间。

/var/lib/rancher/rke2/bin/kubectl get namespaces

确保这些名称空间是您所需的，并根据您的要求进行适当管理。

修正： 遵循文档并根据需要为您的部署中的对象创建名称空间。

5.7.2

确保在您的 Pod 定义中将 seccomp 控制文件设置为 docker/default（手动）。

说明

Seccomp（安全计算模式）用于限制应用程序可以进行的系统调用集，从而使集群管理员对在集群中运行的工作负载的安全性有更大的控制权。出于历史原因，Kubernetes 默认禁用 seccomp 控制文件。您应该启用它，以确保工作负载在容器内具有受限的可用操作。

*结果：*手动

Audit: 审查您集群中的 Pod 定义。它应该创建如下所示的行：

annotations:
  seccomp.security.alpha.kubernetes.io/pod: docker/default

修正： 查看 Kubernetes 文档，如有需要，应用相关的 PodSecurityPolicy。

5.7.3

将安全上下文应用于您的 Pods 和容器（手动）。

说明

安全上下文定义了应用于容器的操作系统安全设置（uid、gid、能力、SELinux 角色等）。在设计您的容器和 Pods 时，请确保为您的 Pods、容器和卷配置安全上下文。安全上下文是在部署 yaml 中定义的属性。它控制将分配给 Pod/容器/卷的安全参数。安全上下文有两个级别：Pod 级别安全上下文和容器级别安全上下文。

*结果：*手动

Audit: 审查您集群中的 Pod 定义，并验证您是否已适当地定义安全上下文。

修正： 遵循 Kubernetes 文档并将安全上下文应用于您的 Pods。有关建议的安全上下文列表，您可以参考 CIS 安全基准。

5.7.4

不应使用默认名称空间（手动）。

说明

Kubernetes 集群中的资源应按名称空间进行隔离，以便在该级别应用安全控制，并使资源管理更容易。

*结果：*手动

Audit: 在主节点上运行以下命令。

/var/lib/rancher/rke2/bin/kubectl get all -n default

验证是否没有资源应用于默认名称空间。

修正： 默认情况下，RKE2 不使用默认名称空间。