CIS 基准

本文档介绍 CIS Kubernetes 基准、如何审核基准合规性,以及您在无法自行实施建议时 Anthos clusters on Bare Metal 配置的内容。

使用 CIS 基准

Center for Internet Security(CIS,互联网安全中心)公布了最佳做法安全建议的基准。CIS Kubernetes 基准提供了一系列用于配置 Kubernetes 以支持可靠的安全状况的建议。基准与特定的 Kubernetes 版本相关联。CIS Kubernetes 基准是针对开源 Kubernetes 发行版编写的,旨在尽可能广泛应用于各个发行版。

版本

请注意,不同基准的版本号可能不同。

本文档涉及以下版本:

Anthos 版本 Kubernetes 版本 CIS Kubernetes 基准版本
1.7.0 1.19.7 1.6

CIS Kubernetes 基准

访问基准

您可以通过 CIS 网站获取 CIS Kubernetes 基准。

建议级别

在 CIS Kubernetes 基准中,

级别 说明
第 1 级

建议应该:

  • 实用且谨慎;
  • 可明确提升安全性;以及
  • 不会阻止以可接受方式以外的方式发挥技术效用。
  • 第 2 级

    扩展第 1 级配置文件。

    建议具有以下一个或多个特性:

  • 适用于高度重视安全性的环境或使用场景;
  • 充当深度防御措施;或者
  • 可能会对技术的效用或性能造成负面影响。
  • 评估状态

    每项建议都会包含评估状态。评估状态表明给定建议可以自动执行,还是需要手动步骤来实施。两种状态同样重要,并根据以下说明确定和提供支持:

    记分 说明
    自动 表示可以完全自动进行技术控制评估并将其验证为通过/失败状态的建议。建议将包含实现自动化所需的信息。
    手动 表示无法完全自动进行技术控制评估的建议,并且需要所有或一些手动步骤来验证已配置状态是否按预期设置。预期状态因环境而异。

    Anthos clusters on Bare Metal 上的评估

    我们使用以下值指定 Anthos clusters on Bare Metal 中 Kubernetes 建议的状态:

    状态 说明
    通过 符合基准建议。
    失败 不符合基准建议。
    等效控制措施 不符合基准建议中的确切条款,但 Anthos clusters on Bare Metal 中的其他机制可提供等效的安全控制措施。
    取决于环境 Anthos clusters on Bare Metal 不会配置与此建议相关的项。用户的配置决定其环境是否符合基准建议。

    Anthos clusters on Bare Metal 架构

    Anthos clusters on Bare Metal 支持多种集群配置和集群类型。每个受支持的集群类型(管理员、用户、混合和独立集群)都会根据 CIS 基准进行评估。以下评估和理由适用于所有受支持的集群类型。如需详细了解 Anthos clusters on Bare Metal 支持的集群配置,请参阅选择部署模型

    Anthos clusters on Bare Metal 上的状态

    使用指定版本创建新的集群时,它将根据 CIS Kubernetes 基准执行如下。

    Anthos clusters on Bare Metal 集群的状态:

    # 建议 级别 状态
    1 1.6
    1.1 主节点配置文件
    1.1.1 确保将 API 服务器 pod 规范文件权限设置为 644 或更严格(自动) L1 通过
    1.1.2 确保将 API 服务器 pod 规范文件所有权设置为 root:root(自动) L1 通过
    1.1.3 确保控制器管理器 pod 规范文件权限设置为 644 或更严格(自动) L1 通过
    1.1.4 确保控制器管理器 pod 规范文件所有权设置为 root:root(自动) L1 通过
    1.1.5 确保将调度器 pod 规范文件权限设置为 644 或更严格(自动) L1 通过
    1.1.6 确保将调度器 pod 规范文件所有权设置为 root:root(自动) L1 通过
    1.1.7 确保将 etcd pod 规范文件权限设置为 644 或更严格(自动) L1 通过
    1.1.8 确保将 etcd pod 规范文件所有权设置为 root:root(自动) L1 通过
    1.1.9 确保将容器网络接口文件权限设置为 644 或更严格(手动) L1 等效控制措施
    1.1.10 确保将容器网络接口文件所有权设置为 root:root(手动) L1 等效控制措施
    1.1.11 确保将 etcd 数据目录权限设置为 700 或更严格(自动) L1 等效控制措施
    1.1.12 确保将 etcd 数据目录所有权设置为 etcd:etcd(自动) L1 等效控制措施
    1.1.13 确保将 admin.conf 文件权限设置为 644 或更严格(自动) L1 通过
    1.1.14 确保将 admin.conf 文件所有权设置为 root:root(自动) L1 通过
    1.1.15 确保将 scheduler.conf 文件权限设置为 644 或更严格(自动) L1 通过
    1.1.16 确保将 scheduler.conf 文件所有权设置为 root:root(自动) L1 通过
    1.1.17 确保将 controller-manager.conf 文件权限设置为 644 或更严格(自动) L1 通过
    1.1.18 确保将 controller-manager.conf 文件所有权设置为 root:root(自动) L1 通过
    1.1.19 确保将 Kubernetes PKI 目录和文件所有权设置为 root:root(自动) L1 通过
    1.1.20 确保将 Kubernetes PKI 证书文件权限设置为 644 或更严格(手动) L1 通过
    1.1.21 确保将 Kubernetes PKI 密钥文件权限设置为 600(手动) L1 通过
    1.2 API 服务器
    1.2.1 确保将 --anonymous-auth 参数设置为 false(手动) L1 失败
    1.2.2 确保未设置 --basic-auth-file 参数(自动) L1 通过
    1.2.3 确保未设置 --token-auth-file 参数(自动) L1 通过
    1.2.4 确保将 --kubelet-https 参数设置为 true(自动) L1 通过
    1.2.5 确保对 --kubelet-client-certificate--kubelet-client-key 参数进行适当设置(自动) L1 通过
    1.2.6 确保对 --kubelet-certificate-authority 参数进行适当设置(自动) L1 通过
    1.2.7 确保 --authorization-mode 参数未设置为 AlwaysAllow(自动) L1 通过
    1.2.8 确保 --authorization-mode 参数包含 Node(自动) L1 通过
    1.2.9 确保 --authorization-mode 参数包含 RBAC(自动) L1 通过
    1.2.10 确保已设置准许控制插件 EventRateLimit(手动) L1 失败
    1.2.11 确保未设置准许控制插件 AlwaysAdmit(自动) L1 通过
    1.2.12 确保已设置准许控制插件 AlwaysPullImages(手动) L1 失败
    1.2.13 确保在未使用 PodSecurityPolicy 的情况下已设置准许控制插件 SecurityContextDeny(手动) L1 等效控制措施
    1.2.14 确保已设置准许控制插件 ServiceAccount(自动) L1 通过
    1.2.15 确保已设置准许控制插件 NamespaceLifecycle(自动) L1 通过
    1.2.16 确保已设置准许控制插件 PodSecurityPolicy(自动) L1 等效控制措施
    1.2.17 确保已设置准许控制插件 NodeRestriction(自动) L1 通过
    1.2.18 确保未设置 --insecure-bind-address 参数(自动) L1 通过
    1.2.19 确保将 --insecure-port 参数设置为 0(自动) L1 通过
    1.2.20 确保 --secure-port 参数未设置为 0(自动) L1 通过
    1.2.21 确保将 --profiling 参数设置为 false(自动) L1 通过
    1.2.22 确保设置 --audit-log-path 参数(自动) L1 通过
    1.2.23 确保将 --audit-log-maxage 参数设置为 30 或进行适当设置(自动) L1 通过
    1.2.24 确保将 --audit-log-maxbackup 参数设置为 10 或进行适当设置(自动) L1 通过
    1.2.25 确保将 --audit-log-maxsize 参数设置为 100 或进行适当设置(自动) L1 通过
    1.2.26 确保对 --request-timeout 参数进行适当设置(自动) L1 通过
    1.2.27 确保将 --service-account-lookup 参数设置为 true(自动) L1 通过
    1.2.28 确保对 --service-account-key-file 参数进行适当设置(自动) L1 通过
    1.2.29 确保对 --etcd-certfile--etcd-keyfile 参数进行适当设置(自动) L1 通过
    1.2.30 确保对 --tls-cert-file--tls-private-key-file 参数进行适当设置(自动) L1 通过
    1.2.31 确保对 --client-ca-file 参数进行适当设置(自动) L1 通过
    1.2.32 确保对 --etcd-cafile 参数进行适当设置(自动) L1 通过
    1.2.33 确保对 --encryption-provider-config 参数进行适当设置(手动) L1 通过
    1.2.34 确保正确配置加密提供程序(手动) L1 通过
    1.2.35 确保 API 服务器仅使用强加密加密方式(手动) L1 通过
    1.3 控制器管理器
    1.3.1 确保对 --terminated-pod-gc-threshold 参数进行适当设置(手动) L1 通过
    1.3.2 确保将 --profiling 参数设置为 false(自动) L1 通过
    1.3.3 确保将 --use-service-account-credentials 参数设置为 true(自动) L1 通过
    1.3.4 确保对 --service-account-private-key-file 参数进行适当设置(自动) L1 通过
    1.3.5 确保对 --root-ca-file 参数进行适当设置(自动) L1 通过
    1.3.6 确保将 RotateKubeletServerCertificate 参数设置为 true(自动) L2 通过
    1.3.7 确保将 --bind-address 参数设置为 127.0.0.1(自动) L1 通过
    1.4 调度器
    1.4.1 确保将 --profiling 参数设置为 false(自动) L1 通过
    1.4.2 确保将 --bind-address 参数设置为 127.0.0.1(自动) L1 通过
    2 1.6
    2 etcd 节点配置文件
    2.1 确保对 --cert-file--key-file 参数进行适当设置(自动) L1 通过
    2.2 确保将 --client-cert-auth 参数设置为 true(自动) L1 通过
    2.3 确保 --auto-tls 参数未设置为 true(自动) L1 通过
    2.4 确保对 --peer-cert-file--peer-key-file 参数进行适当设置(自动) L1 通过
    2.5 确保将 --peer-client-cert-auth 参数设置为 true(自动) L1 通过
    2.6 确保 --peer-auto-tls 参数未设置为 true(自动) L1 通过
    2.7 确保已对 etcd 使用唯一的证书授权机构(手动) L2 通过
    3 1.6
    3.1 身份验证和授权
    3.1.1 不应对用户使用客户端证书身份验证(手动) L2 通过
    3.2 Logging
    3.2.1 确保创建最低审核政策(手动) L1 通过
    3.2.2 确保审核政策涵盖关键的安全问题(手动) L2 等效控制措施
    4 1.6
    4.1 工作器节点配置文件
    4.1.1 确保将 kubelet 服务文件权限设置为 644 或更严格(自动) L1 通过
    4.1.2 确保将 kubelet 服务文件的所有权设置为 root:root(自动) L1 通过
    4.1.3 如果存在代理 kubeconfig 文件,请确保将权限设置为 644 或更严格(手动) L1 通过
    4.1.4 确保将代理 kubeconfig 文件所有权设置为 root:root(手动) L1 通过
    4.1.5 确保将 --kubeconfig kubelet.conf 文件权限设置为 644 或更严格(自动) L1 通过
    4.1.6 确保将 --kubeconfig kubelet.conf 文件权限设置为 root:root 或更严格(手动) L1 通过
    4.1.7 确保将证书授权机构文件权限设置为 644 或更严格(手动) L1 通过
    4.1.8 确保将客户端证书授权机构文件所有权设置为 root:root(手动) L1 通过
    4.1.9 确保将 kubelet --config 配置文件的权限设置为 644 或更严格(自动) L1 通过
    4.1.10 确保将 kubelet --config 配置文件的所有权设置为 root:root(自动) L1 通过
    4.2 Kubelet
    4.2.1 确保将 anonymous-auth 参数设置为 false(自动) L1 通过
    4.2.2 确保 --authorization-mode 参数未设置为 AlwaysAllow(自动) L1 通过
    4.2.3 确保对 --client-ca-file 参数进行适当设置(自动) L1 通过
    4.2.4 确保将 --read-only-port 参数设置为 0(手动) L1 通过
    4.2.5 确保 --streaming-connection-idle-timeout 参数未设置为 0(手动) L1 通过
    4.2.6 确保将 --protect-kernel-defaults 参数设置为 true(自动) L1 失败
    4.2.7 确保将 --make-iptables-util-chains 参数设置为 true(自动) L1 通过
    4.2.8 确保未设置 --hostname-override 参数(手动) L1 通过
    4.2.9 确定将 --event-qps 参数设置为 0 或一个层级以确保适当的事件捕获操作(手动) L2 失败
    4.2.10 确保对 --tls-cert-file--tls-private-key-file 参数进行适当设置(手动) L1 等效控制措施
    4.2.11 确保 --rotate-certificates 参数未设置为 false(手动) L1 通过
    4.2.12 验证 RotateKubeletServerCertificate 参数是否设置为 true(手动) L1 通过
    4.2.13 确保 Kubelet 仅使用强加密加密方式(手动) L1 等效控制措施
    Anthos clusters on Bare Metal 管理员集群的“失败”和“等效控制措施”说明:
    # 建议 级别 状态 理由
    1.1.9 确保将容器网络接口文件权限设置为 644 或更严格(手动) L1 等效控制措施 755 Anthos clusters on Bare Metal 的“容器网络接口”路径为 /opt/cni/bin,其权限设置为 755 以便执行正常的集群操作。
    1.1.10 确保将容器网络接口文件所有权设置为 root:root(手动) L1 等效控制措施 Anthos clusters on Bare Metal 的“容器网络接口”路径为 /opt/cni/bin,其所有权设置为 root:root
    1.1.11 确保将 etcd 数据目录权限设置为 700 或更严格(自动) L1 等效控制措施 755 etcd 数据目录具有默认的 755 权限,但其子目录为 700
    1.1.12 确保将 etcd 数据目录所有权设置为 etcd:etcd(自动) L1 等效控制措施 root:root etcd 容器作为 root 运行,并且 etcd 数据目录归 root:root 所有。
    1.2.1 确保将 --anonymous-auth 参数设置为 false(手动) L1 失败 未设置 某些 Anthos clusters on Bare Metal 操作(如高可用性)要求启用匿名身份验证。
    1.2.10 确保已设置准许控制插件 EventRateLimit(手动) L1 失败 未设置 Anthos clusters on Bare Metal 不支持事件速率限制准许控制器,因为它是 Kubernetes Alpha 版功能。
    1.2.12 确保已设置准许控制插件 AlwaysPullImages(手动) L1 失败 未设置 AlwaysPullImage 准许控制器会为非合作多租户集群中的私有镜像仓库映像提供某些保护,但代价是使容器镜像仓库成为在整个集群中创建新 pod 的单点故障。Anthos clusters on Bare Metal 不启用 AlwaysPullImage 准许控制器,因此集群管理员负责实施准许政策来自行进行该项权衡。
    1.2.13 确保在未使用 PodSecurityPolicy 的情况下已设置准许控制插件 SecurityContextDeny(手动) L1 等效控制措施 未设置 关于 pod 中的安全设置的政策使用政策控制器和 Anthos Config Management 管理。
    1.2.16 确保已设置准许控制插件 PodSecurityPolicy(自动) L1 等效控制措施 未设置 关于 pod 中的安全设置的政策使用政策控制器和 Anthos Config Management 管理。
    3.2.2 确保审核政策涵盖关键的安全问题(手动) L2 等效控制措施 未设置 Anthos clusters on Bare Metal 捕获审核日志,但不会将这些标志用于审核,详情请参阅 https://cloud.google.com/anthos/clusters/docs/bare-metal/1.7/how-to/log-monitoring。
    4.2.6 确保将 --protect-kernel-defaults 参数设置为 true(自动) L1 失败 false Anthos clusters on Bare Metal 允许 kubelet 设置其必要的内核设置。
    4.2.9 确定将 --event-qps 参数设置为 0 或一个层级以确保适当的事件捕获操作(手动) L2 失败 未设置 事件是存储在 etcd 中的 Kubernetes 对象。为避免 etcd 过载,事件仅保留一个小时,它们不是合适的安全审核机制。允许此控制措施中建议的无限制的事件将使集群面临不必要的 DoS 风险,并且会与使用准许 EventRateLimits 的建议发生冲突。需要永久性存储的安全相关事件应发送到日志。
    4.2.10 确保对 --tls-cert-file--tls-private-key-file 参数进行适当设置(手动) L1 等效控制措施 未设置 Anthos clusters on Bare Metal 使用 --rotate-server-certificates 标志管理 kubelet 服务器 TLS。
    4.2.13 确保 Kubelet 仅使用强加密加密方式(手动) L1 等效控制措施 Anthos clusters on Bare Metal 使用一组默认的加密方式。

    如何审核基准

    如需详细了解如何审核每项建议,请参阅相关的 CIS 基准。不过,您可能需要自动执行其中某些检查,以简化您的环境中这些控制措施的验证过程。下面列出的工具可以为您提供帮助。

    CIS Kubernetes 基准的自动审核

    您可以使用开源工具 kube-bench 根据 CIS Kubernetes 基准测试集群配置。

    请务必指定适当的版本,例如:

    kube-bench node --benchmark cis-1.6