RSS
 

STIG 和 NSA/CISA 强化

Tanzu Kubernetes Grid (TKG) 版本根据美国国防信息系统局 （DEFENSE Information Systems Agency，DISA）Kubernetes 安全技术实施指南 (STIG) 和 NSA/CISA Kubernetes 强化指南不断验证。

本主题介绍如何进一步强化由独立管理集群部署的工作负载集群。方法取决于集群是基于类还是基于计划，如工作负载集群类型中所述。

强化基于类的工作负载集群

要创建符合 STIG 和 CIS 标准的基于类的工作负载集群，请按照以下部分中所述对其进行配置。

STIG 强化

要根据 STIG 标准强化基于类的工作负载集群，请在创建集群之前执行以下操作之一：

  • 在集群配置文件中包含以下变量设置
  • 设置本地环境中的变量，例如使用 export
ETCD_EXTRA_ARGS: "auto-tls=false;peer-auto-tls=false;cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384"
KUBE_CONTROLLER_MANAGER_EXTRA_ARGS: "tls-min-version=VersionTLS12;profiling=false;tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384"
WORKER_KUBELET_EXTRA_ARGS: "streaming-connection-idle-timeout=5m;tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384;protect-kernel-defaults=true"
APISERVER_EXTRA_ARGS: "tls-min-version=VersionTLS12;tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384"
KUBE_SCHEDULER_EXTRA_ARGS: "tls-min-version=VersionTLS12;tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384"
CONTROLPLANE_KUBELET_EXTRA_ARGS: "streaming-connection-idle-timeout=5m;tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384;protect-kernel-defaults=true"
ENABLE_AUDIT_LOGGING: true

强化结果

STIG 强化过程将更改 TKG v2.1.1 集群节点的安全扫描，如下所示：

之前：扫描结果，即时可用的 TKG v2.1 集群节点：

  • 控制平面

    OOTB 控制平面

  • 工作节点

    OOTB 工作节点

之后：扫描结果，强化 TKG v2.1 集群节点：

  • 控制平面

    强化控制平面

  • 工作节点

    强化工作节点

基于类的集群的 STIG 结果和异常

VID 查找标题 默认合规？ 修复 异常 / 说明
V-242376 Kubernetes 控制器管理器必须至少使用 TLS 1.2，以保护电子传播期间敏感数据的机密性。 否 是 可以通过设置 KUBE_CONTROLLER_MANAGER_EXTRA_ARGS 来解决该问题
V-242377 Kubernetes 调度程序必须至少使用 TLS 1.2，以保护电子传播过程中敏感数据的机密性。 否 是 可以通过设置 KUBE_SCHEDULER_EXTRA_ARGS
V-242378 Kubernetes API 服务器必须至少使用 TLS 1.2，才能在电子传播期间保护敏感数据的机密性。 否 是 可以通过设置 APISERVER_EXTRA_ARGS 解决此问题
V-242379 Kubernetes etcd 必须使用 TLS 来保护电子传播过程中敏感数据的机密性。 否 是 可以通过设置 ETCD_EXTRA_ARGS
V-242380 Kubernetes etcd 必须使用 TLS 来保护电子传播过程中敏感数据的机密性。 是
V-242381 Kubernetes 控制器管理器必须为每个工作负载创建唯一的服务帐户。 是
V-242382 Kubernetes API 服务器必须启用节点或 RBAC 作为授权模式。 是
V-242383 必须在专用命名空间中创建用户管理的资源。 是
V-242384 Kubernetes 调度程序必须具有安全绑定。 是
V-242385 Kubernetes 控制器管理器必须具有安全绑定。 是
V-242387 Kubernetes Kubelet 必须禁用只读端口标记。 是
V-242388 Kubernetes API 服务器必须未设置不安全的绑定地址。 是
V-242389 Kubernetes API 服务器必须设置安全端口。 是
V-242390 Kubernetes API 服务器必须禁用匿名身份验证。 否 否 在 API 服务器上启用了 RBAC 授权，在启用 RBAC 时，通常认为允许匿名访问 API 服务器以进行运行状况检查和发现是合理的
V-242391 Kubernetes Kubelet 必须禁用匿名身份验证。 是
V-242392 Kubernetes kubelet 必须启用显式授权。 是
V-242395 不得启用 Kubernetes 仪表板。 是
V-242396 Kubernetes Kubectl cp 命令必须提供预期的访问权限和结果。 是
V-242397 Kubernetes kubelet 静态 Pod 路径不能启用静态 Pod。 否 否 Kubernetes 使用静态 Pod 路径启动 apiserver、控制器管理器和调度程序
V-242398 不得启用 Kubernetes DynamicAuditing。 是
V-242400 Kubernetes API 服务器必须禁用 Alpha API。 是
V-242401 Kubernetes API 服务器必须设置审核策略。 否 是 可以通过设置 ENABLE_AUDIT_LOGGING=true 来解决此问题。
V-242402 Kubernetes API 服务器必须设置审核日志路径。 否 是 可以通过设置 ENABLE_AUDIT_LOGGING=true 来解决此问题。
V-242403 Kubernetes API 服务器必须生成审核记录，以确定发生的事件类型，标识事件源，包含事件结果，标识所有用户，并确定与事件关联的任何容器。 否 否 生成的默认审核规则会筛选掉充斥着日志的内部组件之间的大量通信。
V-242404 Kubernetes Kubelet 必须拒绝主机名覆盖。 否 否 这是云提供商（如 AWS/Azure）上的 Kubernetes 必需的。
V-242405 Kubernetes 清单必须由 root 用户拥有。 是
V-242406 Kubernetes kubelet 配置文件必须由 root 拥有。 是
V-242407 Kubernetes kubelet 配置文件的文件权限必须设置为 644 或更严格。 是
V-242408 Kubernetes 清单必须具有最少的特权。 是
V-242409 Kubernetes 控制器管理器必须禁用分析。 否 是 可以通过设置 KUBE_CONTROLLER_MANAGER_EXTRA_ARGS 来解决该问题
V-242410 Kubernetes API 服务器必须强制实施符合端口、协议和服务管理类别保证列表 (PPSM CAL) 的端口、协议和服务 (PPS)。 否 需要手动查看
V-242411 Kubernetes 调度程序必须强制实施符合端口、协议和服务管理类别保证列表 (PPSM CAL) 的端口、协议和服务 (PPS)。 否 需要手动查看
V-242412 Kubernetes 控制器必须强制实施符合端口、协议和服务管理类别保证列表 (PPSM CAL) 的端口、协议和服务 (PPS)。 否 需要手动查看
V-242413 Kubernetes etcd 必须强制实施符合端口、协议和服务管理类别保证列表 (PPSM CAL) 的端口、协议和服务 (PPS)。 否 需要手动查看
V-242414 Kubernetes 集群必须为用户 Pod 使用非特权主机端口。 是
V-242415 Kubernetes 中的密钥不得存储为环境变量。 否 否 “调用“Get Pod”API 调用时，SecretKeyRef 将显示密钥名称，而不是密钥的内容。”
V-245541 Kubernetes Kubelet 不得禁用超时。 否 是 可以通过设置工作节点和控制平面 KUBELET_EXTRA_ARGS 解决此问题
V-242417 Kubernetes 必须分离用户功能。 否 需要手动查看
V-242418 Kubernetes API 服务器必须使用批准的密码套件。 否 是 可以通过设置 APISERVER_EXTRA_ARGS 解决此问题
V-242419 Kubernetes API 服务器必须设置 SSL 证书颁发机构。 是
V-242420 Kubernetes Kubelet 必须设置 SSL 证书颁发机构。 是
V-242421 Kubernetes 控制器管理器必须设置 SSL 证书颁发机构。 是
V-242422 Kubernetes API 服务器必须具有用于通信的证书。 是
V-242423 Kubernetes etcd 必须启用客户端身份验证才能保护服务。 是
V-242424 Kubernetes Kubelet 必须启用 tls-private-key-file 进行客户端身份验证，以确保服务的安全。 否 否 RotateServerCertificates 需要手动批准服务证书。用户可以手动启用此设置，批准证书，然后将此设置应用于 kubelets。
V-242425 Kubernetes Kubelet 必须启用 tls-cert-file 进行客户端身份验证，以确保服务的安全。 否 否 RotateServerCertificates 需要手动批准服务证书。用户可以手动启用此设置，批准证书，然后将此设置应用于 kubelets。
V-242426 Kubernetes etcd 必须启用客户端身份验证才能保护服务。 是
V-242427 Kubernetes etcd 必须具有用于安全通信的密钥文件。 是
V-242428 Kubernetes etcd 必须具有用于通信的证书。 是
V-242429 Kubernetes etcd 必须设置 SSL 证书颁发机构。 是
V-242430 Kubernetes etcd 必须具有用于通信的证书。 是
V-242431 Kubernetes etcd 必须具有用于安全通信的密钥文件。 是
V-242432 Kubernetes etcd 必须设置对等证书文件才能进行安全通信。 是
V-242433 Kubernetes etcd 必须设置对等秘钥文件才能进行安全通信。 是
V-242434 Kubernetes Kubelet 必须启用内核保护。 否 是 可以通过设置工作节点和控制平面 KUBELET_EXTRA_ARGS 解决此问题
V-242435 Kubernetes 必须阻止非特权用户执行特权功能，以包含禁用、规避或更改实施的安全安全措施/对策，或者安装修补程序和更新。 是
V-242436 Kubernetes API 服务器必须启用 ValidatingAdmissionWebhook。 是
V-254801 Kubernetes 必须设置 Pod 安全准入功能网关。 是
V-254800 Kubernetes 必须配置 Pod 安全准入控制文件。 否 否 OPA 门禁程序是一个可行的替代方案，可实现更精细的 Pod 安全性。
V-242438 Kubernetes API 服务器必须配置超时以限制攻击面。 是
V-245542 Kubernetes API 服务器必须禁用基本身份验证以保护传输中的信息。 是
V-245543 Kubernetes API 服务器必须禁用令牌身份验证以保护传输中的信息。 是
V-245544 Kubernetes 端点必须使用批准的组织证书和密钥对来保护传输中的信息。 是
V-242442 安装更新的版本后，Kubernetes 必须移除旧组件。 否 需要手动查看
V-242443 Kubernetes 必须包含 IAVM、CTO、DTM 和 STIG 授权的最新更新。 是
V-242444 Kubernetes 组件清单必须由 root 用户拥有。 是
V-242445 Kubernetes 组件 etcd 必须由 etcd 用户拥有。 否 否 要置备集群，Tanzu Kubernetes Grid 使用集群 API，而集群 API 又使用 kubeadm 工具置备 Kubernetes。kubeadm 使 etcd 作为静态 Pod 容器化运行，因此无需将目录设置为特定用户。
V-242446 Kubernetes 配置文件必须由 root 用户拥有。 是
V-242447 Kubernetes Kube 代理的文件权限必须设置为 644 或更多限制。 否 否 Kube 代理在 Pod 中运行，因此主机上不存在此文件。在 Pod 内，它链接到另一个具有正确权限的目录
V-242448 Kubernetes Kube 代理必须由 root 用户拥有。 是
V-242449 Kubernetes Kubelet 证书颁发机构文件的文件权限必须设置为 644 或更多限制。 是
V-242450 Kubernetes Kubelet 证书颁发机构必须由 root 用户拥有。 是
V-242451 Kubernetes 组件 PKI 必须由 root 用户拥有。 是
V-242452 Kubernetes kubelet 配置必须将文件权限必须设置为 644 或更多限制。 是
V-242453 Kubernetes kubelet 配置必须由 root 用户拥有。 是
V-242454 Kubernetes kubeadm.conf 必须由 root 用户拥有。 是
V-242455 Kubernetes kubeadm.conf 的文件权限必须设置为 644 或更多限制。 是
V-242456 Kubernetes kubelet 配置必须将文件权限必须设置为 644 或更多限制。 是
V-242457 Kubernetes kubelet 配置必须由 root 用户拥有。 是
V-242458 Kubernetes API 服务器的文件权限必须设置为 644 或更多限制。 是
V-242459 Kubernetes etcd 的文件权限必须设置为 644 或更多限制。 是
V-242460 Kubernetes admin.conf 的文件权限必须设置为 644 或更多限制。 是
V-242461 必须启用 Kubernetes API 服务器审核日志。 否 是 可以通过设置 ENABLE_AUDIT_LOGGING=true 来解决此问题。
V-242462 必须将 Kubernetes API 服务器设置为审核日志最大大小。 否 是 可以通过设置 ENABLE_AUDIT_LOGGING=true 来解决此问题。
V-242463 Kubernetes API 服务器必须设置为审核日志最大备份数。 否 是 可以通过设置 ENABLE_AUDIT_LOGGING=true 来解决此问题。
V-242464 必须设置 Kubernetes API 服务器审核日志保留。 否 是 可以通过设置 ENABLE_AUDIT_LOGGING=true 来解决此问题。
V-242465 必须设置 Kubernetes API 服务器审核日志路径。 否 是 可以通过设置 ENABLE_AUDIT_LOGGING=true 来解决此问题。
V-242466 Kubernetes PKI CRT 的文件权限必须设置为 644 或更多限制。 是
V-242467 Kubernetes PKI 密钥的文件权限必须设置为 600 或更多限制。 是
V-242468 Kubernetes API 服务器必须禁止使用 TLS 版本 1.0 和 1.1 以及 SSL 2.0 和 3.0 进行通信。 否 是 可以通过设置 APISERVER_EXTRA_ARGS 解决此问题

NSA/CISA 强化

要根据 CIS 标准强化基于类的工作负载集群，请在创建集群之前执行以下操作：

  1. 查看下面的事件速率限制配置。如果要更改任何设置，请将代码保存到 event-rate-config.yaml 并根据需要更改设置：

    apiVersion: eventratelimit.admission.k8s.io/v1alpha1
kind: Configuration
limits:
- type: Namespace
qps: 50
burst: 100
cacheSize: 2000
- type: User
qps: 10
burst: 50

  2. 如果使用自定义设置创建了 event-rate-config.yaml，则通过运行以下命令并记录输出字符串对文件进行 base64 编码：

    • Linux：base64 -w 0 event-rate-config.yaml
    • Mac：base64 -b 0 event-rate-config.yaml

  3. 在创建集群之前，请执行以下操作之一：

    • 在集群配置文件中包含以下变量设置
    • 设置本地环境中的变量，例如使用 export
    ETCD_EXTRA_ARGS: "auto-tls=false;peer-auto-tls=false;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"
KUBE_CONTROLLER_MANAGER_EXTRA_ARGS: "profiling=false;terminated-pod-gc-threshold=500;tls-min-version=VersionTLS12;profiling=false;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"
WORKER_KUBELET_EXTRA_ARGS: "read-only-port=0;authorization-mode=Webhook;client-ca-file=/etc/kubernetes/pki/ca.crt;event-qps=0;make-iptables-util-chains=true;streaming-connection-idle-timeout=5m;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;protect-kernel-defaults=true"
APISERVER_EXTRA_ARGS: "enable-admission-plugins=AlwaysPullImages,NodeRestriction;profiling=false;service-account-lookup=true;tls-min-version=VersionTLS12;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"
KUBE_SCHEDULER_EXTRA_ARGS: "profiling=false;tls-min-version=VersionTLS12;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"
CONTROLPLANE_KUBELET_EXTRA_ARGS: "read-only-port=0;authorization-mode=Webhook;client-ca-file=/etc/kubernetes/pki/ca.crt;event-qps=0;make-iptables-util-chains=true;streaming-connection-idle-timeout=5m;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;protect-kernel-defaults=true"
APISERVER_EVENT_RATE_LIMIT_CONF_BASE64: "<EVENT-RATE-CONFIG>"
ENABLE_AUDIT_LOGGING: true

    其中 <EVENT-RATE-CONFIG> 是上一步的 base64 编码值，如果未更改事件速率限制配置，则为以下值：

    • YXBpVmVyc2lvbjogZXZlbnRyYXRlbGltaXQuYWRtaXNzaW9uLms4cy5pby92MWFscGhhMQpraW5kOiBDb25maWd1cmF0aW9uCmxpbWl0czoKLSB0eXBlOiBOYW1lc3BhY2UKICBxcHM6IDUwCiAgYnVyc3Q6IDEwMAogIGNhY2hlU2l6ZTogMjAwMAotIHR5cGU6IFVzZXIKICBxcHM6IDEwCiAgYnVyc3Q6IDUwCg==

强化结果

NSA/CISA 强化过程更改 TKG v2.1.0 集群节点的安全扫描，如下所示：

之前：扫描结果，即时可用的 TKG v2.1 集群节点：

OOTB

之后：扫描结果，强化 TKG v2.1 集群节点：

强化

强化基于计划的工作负载集群

由独立管理集群部署的旧版非基于类的 TKG 工作负载集群可以使用 ytt 覆盖网络进一步强化。有关如何使用 ytt 自定义基于计划的 TKG 集群的信息，请参阅 具有 ytt 的旧版集群配置。

您可以在 CLI 配置中将 allow-legacy-cluster 设置为 true 以创建旧版集群，如 Tanzu CLI 参考中所述。

STIG 强化

为了进一步强化基于计划的 TKG 集群，VMware 提供了 STIG 强化 ytt 覆盖网络。

以下代码片段是 ytt 覆盖网络以设置 tls-min-version (STIG: 

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")
#@overlay/match missing_ok=True,by=overlay.subset({"kind":"KubeadmControlPlane"})
---
spec:
  kubeadmConfigSpec:
    clusterConfiguration:
      apiServer:
        extraArgs:
        #@overlay/match missing_ok=True
        tls-min-version: VersionTLS12

NSA/CISA 强化

为进一步强化 NSA/CISA 的基于计划的 TKG 集群，VMware 提供了以下 Antrea 对象规范：

  • NSA/CISA 强化：Antrea ClusterNetworkPolicies：

    网络策略控制规范的以下 Antrea ClusterNetworkPolicies 为所有 Pod 设置默认策略，以拒绝所有输入和输出流量，并确保隔离任何未选择的 Pod。

    apiVersion: security.antrea.tanzu.vmware.com/v1alpha1
kind: ClusterNetworkPolicy
metadata:
name: default-deny
spec:
priority: 150
tier: baseline
appliedTo:
  - namespaceSelector: {}
ingress:
  - action: Drop              # For all Pods in every namespace, drop and log all ingress traffic from anywhere
    name: drop-all-ingress
    enableLogging: true
egress:
  - action: Drop              # For all Pods in every namesapces, drop and log all egress traffic towards anywhere
    name: drop-all-egress
    enableLogging: true

  • NSA/CISA 强化：Antrea 网络策略：

    以下 Antrea 网络策略允许将 tanzu-capabilities-manager 输出到 kube-apiserver 端口443 和 6443。

    apiVersion: security.antrea.tanzu.vmware.com/v1alpha1
kind: NetworkPolicy
metadata:
name: tanzu-cm-apiserver
namespace: tkg-system
spec:
priority: 5
tier: securityops
appliedTo:
  - podSelector:
      matchLabels:
      app: tanzu-capabilities-manager
egress:
  - action: Allow
    to:
    - podSelector:
        matchLabels:
        component: kube-apiserver
      namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
    ports:
    - port: 443
      protocol: TCP
    - port: 6443
      protocol: TCP
    name: AllowToKubeAPI

  • NSA/CISA 强化：OPA 模板和限制：

    以下示例使用 OPA 门禁程序限制允许的映像存储库。

    • OPA 模板：

      apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
name: k8sallowedrepos
annotations:
  description: Requires container images to begin with a repo string from a specified
    list.
spec:
crd:
  spec:
    names:
      kind: K8sAllowedRepos
    validation:
      # Schema for the `parameters` field
      openAPIV3Schema:
        type: object
        properties:
          repos:
            type: array
            items:
              type: string
targets:
  - target: admission.k8s.gatekeeper.sh
    rego:|
      package k8sallowedrepos

      violation[{"msg": msg}] {
        container := input.review.object.spec.containers[_]
        satisfied := [good| repo = input.parameters.repos[_] ; good = startswith(container.image, repo)]
        not any(satisfied)
        msg := sprintf("container <%v> has an invalid image repo <%v>, allowed repos are %v", [container.name, container.image, input.parameters.repos])
      }

      violation[{"msg": msg}] {
        container := input.review.object.spec.initContainers[_]
        satisfied := [good| repo = input.parameters.repos[_] ; good = startswith(container.image, repo)]
        not any(satisfied)
        msg := sprintf("container <%v> has an invalid image repo <%v>, allowed repos are %v", [container.name, container.image, input.parameters.repos])
      }

    • OPA 限制：

      apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRepos
metadata:
name: repo-is-openpolicyagent
spec:
match:
  kinds:
    - apiGroups: [""]
      kinds: ["Pod"]
parameters:
  repos:
    - "<ALLOWED_IMAGE_REPO>"

  • NSA/CISA 强化：OPA 突变：

    以下示例使用 OPA 突变将 allowPrivilegeEscalation 设置为 false（如果其在 Pod 规范中缺失）。

    apiVersion: mutations.gatekeeper.sh/v1alpha1
kind: Assign
metadata:
name: allow-privilege-escalation
spec:
  match:
    scope: Namespaced
    kinds:
      - apiGroups: ["*"]
        kinds: ["Pod"]
    excludedNamespaces:
    - kube-system
  applyTo:
  - groups: [""]
    kinds: ["Pod"]
    versions: ["v1"]
  location: "spec.containers[name:*].securityContext.allowPrivilegeEscalation"
  parameters:
    pathTests:
    - subPath: "spec.containers[name:*].securityContext.allowPrivilegeEscalation"
      condition: MustNotExist
    assign:
      value: false

本指南使用 Antrea CNI 进行网络强化，因为它使用层对网络策略进行精细控制并且能够使用 ClusterNetworkPolicy 应用集群范围的安全策略。

使用开放策略代理 (OPA)，而不是 Pod 安全策略，因为后者在 Kubernetes 1.21 中已弃用。

ytt 覆盖网络、网络策略和 OPA 策略的创建方式使集群管理员能够轻松选择退出某些工作负载的强化控制。建议不要完全选择退出强化实践，而是隔离未应用这些强化控制的命名空间中的工作负载。选择退出强化控制还取决于 TKG 部署的风险偏好。

基于计划的集群控制平面的 STIG 结果和异常

VID 查找标题 默认合规？ 是否可以解决？ 解释 / 异常
V-242376 Kubernetes 控制器管理器必须至少使用 TLS 1.2，以保护电子传播期间敏感数据的机密性。 否 是 可以使用 ytt 覆盖网络解决此问题
V-242377 Kubernetes 调度程序必须至少使用 TLS 1.2，以保护电子传播过程中敏感数据的机密性。 否 是 可以使用 ytt 覆盖网络解决此问题
V-242378 Kubernetes API 服务器必须至少使用 TLS 1.2，才能在电子传播期间保护敏感数据的机密性。 否 是 可以使用 ytt 覆盖网络解决此问题
V-242379 Kubernetes etcd 必须使用 TLS 来保护电子传播过程中敏感数据的机密性。 否 是 可以使用 ytt 覆盖网络解决此问题
V-242380 Kubernetes etcd 必须使用 TLS 来保护电子传播过程中敏感数据的机密性。 是
V-242381 Kubernetes 控制器管理器必须为每个工作负载创建唯一的服务帐户。 是
V-242382 Kubernetes API 服务器必须启用节点 RBAC 作为授权模式。 是
V-242383 必须在专用命名空间中创建用户管理的资源。 是
V-242384 Kubernetes 调度程序必须具有安全绑定。 是
V-242385 Kubernetes 控制器管理器必须具有安全绑定。 是
V-242386 Kubernetes API 服务器必须禁用不安全端口标记。 否 否 已在 Kubernetes v1.24+ 中移除异常 --insecure-port 标记
V-242387 Kubernetes Kubelet 必须禁用只读端口标记。 是
V-242388 Kubernetes API 服务器必须未设置不安全的绑定地址。 是
V-242389 Kubernetes API 服务器必须设置安全端口。 是
V-242390 Kubernetes API 服务器必须禁用匿名身份验证。 否 否 在 API 服务器 (V-242382) 上启用了异常 RBAC 授权，在启用 RBAC 时，通常认为允许匿名访问 API 服务器以进行运行状况检查和发现是合理的
V-242391 Kubernetes Kubelet 必须禁用匿名身份验证。 是
V-242392 Kubernetes kubelet 必须启用显式授权。 是
V-242393 Kubernetes 工作节点不得运行 sshd 服务。 是
V-242394 Kubernetes 工作节点不得启用 sshd 服务。 否 否 异常 ssh 仅限于 Bastion 服务器，需要启用服务证书并安装监控工具。此外，这不是工作节点
V-242395 不得启用 Kubernetes 仪表板。 是
V-242396 Kubernetes Kubectl cp 命令必须提供预期的访问权限和结果。 是
V-242397 Kubernetes kubelet 静态 Pod 路径不能启用静态 Pod。 否 否 异常 TKG 利用 staticPodPath 以启动大量组件，因此无法将其禁用
V-242398 不得启用 Kubernetes DynamicAuditing。 是
V-242399 不得启用 Kubernetes DynamicKubeletConfig。 是
V-242400 Kubernetes API 服务器必须禁用 Alpha API。 是
V-242401 Kubernetes API 服务器必须设置审核策略。 是
V-242402 Kubernetes API 服务器必须设置审核日志路径。 是
V-242403 Kubernetes API 服务器必须生成审核记录，以确定发生的事件类型，标识事件源，包含事件结果，标识所有用户，并确定与事件关联的任何容器。 是
V-242403 Kubernetes API 服务器必须生成审核记录，以确定发生的事件类型，标识事件源，包含事件结果，标识所有用户，并确定与事件关联的任何容器。 是
V-242403 Kubernetes API 服务器必须生成审核记录，以确定发生的事件类型，标识事件源，包含事件结果，标识所有用户，并确定与事件关联的任何容器。 是
V-242403 Kubernetes API 服务器必须生成审核记录，以确定发生的事件类型，标识事件源，包含事件结果，标识所有用户，并确定与事件关联的任何容器。 是
V-242403 Kubernetes API 服务器必须生成审核记录，以确定发生的事件类型，标识事件源，包含事件结果，标识所有用户，并确定与事件关联的任何容器。 是
V-242403 Kubernetes API 服务器必须生成审核记录，以确定发生的事件类型，标识事件源，包含事件结果，标识所有用户，并确定与事件关联的任何容器。 是
V-242404 Kubernetes Kubelet 必须拒绝主机名覆盖。 否 否 异常公有云 Kubernetes 集群需要此服务。
V-242405 Kubernetes 清单必须由 root 用户拥有。 是
V-242406 Kubernetes kubelet 配置文件必须由 root 拥有。 是
V-242407 Kubernetes kubelet 配置文件必须由 root 拥有。 是
V-242408 Kubernetes 清单必须具有最少的特权。 是
V-242409 Kubernetes 控制器管理器必须禁用分析。 否 是 可以使用 ytt 覆盖网络解决此问题
V-242410 Kubernetes API 服务器必须强制实施符合端口、协议和服务管理类别保证列表 (PPSM CAL) 的端口、协议和服务 (PPS)。 否 否 异常手动检查 - 由 PPSM 监控解决方案处理
V-242411 Kubernetes 调度程序必须强制实施符合端口、协议和服务管理类别保证列表 (PPSM CAL) 的端口、协议和服务 (PPS)。 否 否 异常手动检查 - 由 PPSM 监控解决方案处理
V-242412 Kubernetes 控制器必须强制实施符合端口、协议和服务管理类别保证列表 (PPSM CAL) 的端口、协议和服务 (PPS)。 否 否 异常手动检查 - 由 PPSM 监控解决方案处理
V-242413 Kubernetes etcd 必须强制实施符合端口、协议和服务管理类别保证列表 (PPSM CAL) 的端口、协议和服务 (PPS)。 否 否 异常手动检查 - 由 PPSM 监控解决方案处理
V-242414 Kubernetes 集群必须为用户 Pod 使用非特权主机端口。 否 否 异常手动检查 - 由 PPSM 监控解决方案处理
V-242415 Kubernetes 中的密钥不得存储为环境变量。 是
V-242416 Kubernetes Kubelet 不得禁用超时。 否 是 可以使用 ytt 覆盖网络解决此问题
V-242417 Kubernetes 必须分离用户功能。 否 否 异常手动检查
V-242418 Kubernetes API 服务器必须使用批准的密码套件。 是
V-242419 Kubernetes API 服务器必须设置 SSL 证书颁发机构。 是
V-242420 Kubernetes Kubelet 必须设置 SSL 证书颁发机构。 是
V-242421 Kubernetes 控制器管理器必须设置 SSL 证书颁发机构。 是
V-242422 Kubernetes API 服务器必须具有用于通信的证书。 是
V-242423 Kubernetes etcd 必须启用客户端身份验证才能保护服务。 是
V-242424 Kubernetes Kubelet 必须启用 tls-private-key-file 以进行客户端身份验证，从而确保服务的安全。 否 是 这可以在控制器管理器和 kubelet 的功能门 RotateServerCertificates 与 kubelet 中定义的 client-ca-file 和 api 服务器中定义的 kubelet-certificate-authority 一起添加到覆盖层后手动启用。一旦集群在上述启用的情况下启动，则可以手动批准证书，因为 kubelet 服务的证书不会自动批准，然后可以修改 kubelet 配置以包括 tls-private-key-file 和 tls-cert-file，这两者都指向新创建的 kubelet-server-current.pem file。然后，只需重新启动 kubelet
V-242425 Kubernetes Kubelet 必须启用 tls-cert-file 以进行客户端身份验证，从而确保服务的安全。 否 是 这可以在控制器管理器和 kubelet 的功能门 RotateServerCertificates 与 kubelet 中定义的 client-ca-file 和 api 服务器中定义的 kubelet-certificate-authority 一起添加到覆盖层后手动启用。一旦集群在上述启用的情况下启动，则可以手动批准证书，因为 kubelet 服务的证书不会自动批准，然后可以修改 kubelet 配置以包括 tls-private-key-file 和 tls-cert-file，这两者都指向新创建的 kubelet-server-current.pem file。然后，只需重新启动 kubelet
V-242426 Kubernetes etcd 必须启用客户端身份验证才能保护服务。 是
V-242427 Kubernetes etcd 必须具有用于安全通信的密钥文件。 是
V-242428 Kubernetes etcd 必须具有用于通信的证书。 是
V-242429 Kubernetes etcd 必须设置 SSL 证书颁发机构。 是
V-242430 Kubernetes etcd 必须具有用于通信的证书。 是
V-242431 Kubernetes etcd 必须具有用于安全通信的密钥文件。 是
V-242432 Kubernetes etcd 必须设置对等证书文件才能进行安全通信。 是
V-242433 Kubernetes etcd 必须设置对等秘钥文件才能进行安全通信。 是
V-242434 Kubernetes Kubelet 必须启用内核保护。 否 是 在创建自定义 AMI 或提前正确设置主机，然后通过 ytt 覆盖网络启用该主机后，即可以解决此问题
V-242435 Kubernetes 必须阻止非特权用户执行特权功能，以包含禁用、规避或更改实施的安全安全措施/对策，或者安装修补程序和更新。 是
V-242435 Kubernetes 必须阻止非特权用户执行特权功能，以包含禁用、规避或更改实施的安全安全措施/对策，或者安装修补程序和更新。 是
V-242435 Kubernetes 必须阻止非特权用户执行特权功能，以包含禁用、规避或更改实施的安全安全措施/对策，或者安装修补程序和更新。 是
V-242436 Kubernetes API 服务器必须启用 ValidatingAdmissionWebhook。 是
V-242437 Kubernetes 必须具有 Pod 安全策略集。 否 否 异常 弃用 Pod 安全策略后，OPA 门禁程序是建议的 Pod 安全解决方案
V-242438 Kubernetes API 服务器必须配置超时以限制攻击面。 是
V-242439 Kubernetes API 服务器必须禁用基本身份验证以保护传输中的信息。 是
V-242440 Kubernetes API 服务器必须禁用令牌身份验证以保护传输中的信息。 是
V-242441 Kubernetes 端点必须使用批准的组织证书和密钥对来保护传输中的信息。 是
V-242442 安装更新的版本后，Kubernetes 必须移除旧组件。 否 否 异常手动检查
V-242443 Kubernetes 必须包含 IAVM、CTO、DTM 和 STIG 授权的最新更新。 是
V-242444 Kubernetes 组件清单必须由 root 用户拥有。 是
V-242445 Kubernetes 组件 etcd 必须由 etcd 用户拥有。 否 否 异常 数据目录（/var/lib/etcd）归 root:root 所有。要置备集群，Tanzu Kubernetes Grid 使用集群 API，而集群 API 又使用 kubeadm 工具置备 Kubernetes。kubeadm 使 etcd 作为静态 Pod 容器化运行，因此无需将目录设置为特定用户。kubeadm 将目录配置为非 root 用户不可读取。
V-242446 Kubernetes 配置文件必须由 root 用户拥有。 是
V-242447 Kubernetes Kube 代理的文件权限必须设置为 644 或更多限制。 否 否 异常 kube-proxy 的 Kubeconfig 是一个符号链接。基础文件为 0644 或更少许可。手动检查
V-242448 Kubernetes Kube 代理必须由 root 用户拥有。 是
V-242449 Kubernetes Kubelet 证书颁发机构文件的文件权限必须设置为 644 或更多限制。 是
V-242450 Kubernetes Kubelet 证书颁发机构必须由 root 用户拥有。 是
V-242451 Kubernetes 组件 PKI 必须由 root 用户拥有。 是
V-242452 Kubernetes kubelet 配置必须将文件权限必须设置为 644 或更多限制。 是
V-242453 Kubernetes kubelet 配置必须由 root 用户拥有。 是
V-242454 Kubernetes kubeadm 必须由 root 用户拥有。 是
V-242455 Kubernetes kubelet 服务的文件权限必须设置为 644 或更严格。 是
V-242456 Kubernetes kubelet 配置必须将文件权限必须设置为 644 或更多限制。 是
V-242457 Kubernetes kubelet 配置必须由 root 用户拥有。 是
V-242458 Kubernetes API 服务器的文件权限必须设置为 644 或更多限制。 是
V-242459 Kubernetes etcd 的文件权限必须设置为 644 或更多限制。 是
V-242460 Kubernetes admin.conf 的文件权限必须设置为 644 或更多限制。 是
V-242461 必须启用 Kubernetes API 服务器审核日志。 是
V-242462 必须将 Kubernetes API 服务器设置为审核日志最大大小。 是
V-242463 Kubernetes API 服务器必须设置为审核日志最大备份数。 是
V-242464 必须设置 Kubernetes API 服务器审核日志保留。 是
V-242465 必须设置 Kubernetes API 服务器审核日志路径。 是
V-242466 Kubernetes PKI CRT 的文件权限必须设置为 644 或更多限制。 是
V-242467 Kubernetes PKI 密钥的文件权限必须设置为 600 或更多限制。 是
V-242468 Kubernetes API 服务器必须禁止使用 TLS 版本 1.0 和 1.1 以及 SSL 2.0 和 3.0 进行通信。 否 是 可以使用 ytt 覆盖网络解决此问题

基于计划的集群工作节点的 STIG 结果和异常

VID 查找标题 默认合规？ 是否可以解决？ 解释 / 异常
V-242387 Kubernetes Kubelet 必须禁用只读端口标记。 是
V-242391 Kubernetes Kubelet 必须禁用匿名身份验证。 是
V-242392 Kubernetes kubelet 必须启用显式授权。 是
V-242393 Kubernetes 工作节点不得运行 sshd 服务。 是
V-242394 Kubernetes 工作节点不得启用 sshd 服务。 否 否 异常 ssh 仅限于 Bastion 服务器，需要启用证书服务并安装监控工具
V-242396 Kubernetes Kubectl cp 命令必须提供预期的访问权限和结果。 是
V-242397 Kubernetes kubelet 静态 Pod 路径不能启用静态 Pod。 否 否 异常 staticPodPath 需要 TKG 才能正确安装，因为 tkg 系统中的多个 Pod 都在该处定义了异常
V-242398 不得启用 Kubernetes DynamicAuditing。 是
V-242399 不得启用 Kubernetes DynamicKubeletConfig。 是
V-242400 Kubernetes API 服务器必须禁用 Alpha API。 是
V-242404 Kubernetes Kubelet 必须拒绝主机名覆盖。 否 否 异常 Kubernetes 的公有云部署需要 hostname-override
V-242406 Kubernetes kubelet 配置文件必须由 root 拥有。 是
V-242407 Kubernetes kubelet 配置文件必须由 root 拥有。 是
V-242416 Kubernetes Kubelet 不得禁用超时。 否 是 可以使用 ytt 覆盖网络解决此问题
V-242420 Kubernetes Kubelet 必须设置 SSL 证书颁发机构。 是
V-242425 Kubernetes Kubelet 必须启用 tls-cert-file 进行客户端身份验证，以确保服务的安全。 否 是 这可以在控制器管理器和 kubelet 的功能门 RotateServerCertificates 与 kubelet 中定义的 client-ca-file 和 api 服务器中定义的 kubelet-certificate-authority 一起添加到覆盖层后手动启用。一旦集群在上述启用的情况下启动，则可以手动批准证书，因为 kubelet 服务的证书不会自动批准，然后可以修改 kubelet 配置以包括 tls-private-key-file 和 tls-cert-file，这两者都指向新创建的 kubelet-server-current.pem file。然后，只需重新启动 kubelet
V-242434 Kubernetes Kubelet 必须启用内核保护。 否 是 在创建自定义 AMI 或提前正确设置主机，然后通过 ytt 覆盖网络启用它后，即可以解决此问题
V-242449 Kubernetes Kubelet 证书颁发机构文件的文件权限必须设置为 644 或更多限制。 是
V-242450 Kubernetes Kubelet 证书颁发机构必须由 root 用户拥有。 是
V-242451 Kubernetes 组件 PKI 必须由 root 用户拥有。 是
V-242452 Kubernetes kubelet 配置必须将文件权限必须设置为 644 或更多限制。 是
V-242453 Kubernetes kubelet 配置必须由 root 用户拥有。 是
V-242454 Kubernetes kubeadm 必须由 root 用户拥有。 是
V-242455 Kubernetes kubelet 服务的文件权限必须设置为 644 或更严格。 是
V-242456 Kubernetes kubelet 配置必须将文件权限必须设置为 644 或更多限制。 是
V-242457 Kubernetes kubelet 配置必须由 root 用户拥有。 是
V-242466 Kubernetes PKI CRT 的文件权限必须设置为 644 或更多限制。 是

《NSA/CISA Kubernetes 强化指南》

标题 默认合规？ 是否可以解决？ 解释 / 异常
允许特权升级 否 是 通过 OPA 门禁程序策略和突变解决
非 root 容器 否 是 通过 OPA 门禁程序策略和突变解决。
异常某些 Pod（如 contour/envoy）需要 root 才能正常运行。Tanzu 系统输入需要与网络交互
自动映射服务帐户 否 是 已解决 OPA 门禁程序突变问题。
异常 门禁程序需要访问 API 服务器，以便自动挂载其服务帐户
配置文件中的应用程序凭据 否 否 异常配置文件中检测到的所有凭据都是误报，因为它们是公钥
Linux 强化 否 是 通过 OPA 门禁程序限制和突变解决，丢弃所有功能
异常某些 Pod（如 contour/envoy）需要高级特权才能正常运行。Tanzu 系统输入需要与网络交互
已启用 Seccomp 否 是 通过 OPA 门禁程序突变解决，为所有 Pod 设置 Seccomp 配置文件
主机 PID/IPC 特权 否 是 添加了门禁程序限制，以禁止所有 Pod 使用 PID/IPC 运行
危险功能 否 是 添加了门禁程序限制来禁止危险功能，并添加了一个突变以设置默认值。
异常某些 Pod（如 contour/envoy）需要高级权限才能正常运行。Tanzu 系统输入需要与网络交互
执行到容器中 否 否 Kubernetes 附带具有对 Pod 的访问权限的帐户，管理员可能需要这样做，建议使用面向客户的解决方案。例如，在 RBAC 中移除普通最终用户的 exec
允许的主机路径 否 是 添加了门禁程序限制以防止挂载主机路径
hostNetwork 访问 否 是 添加了门禁程序限制以防止使用主机网络。
异常 Kapp 控制器需要访问主机才能使 tanzu 正常工作，并且是控制平面外唯一允许访问主机网络的 Pod
公开的仪表板 是
集群管理员绑定 否 否 启动 k8s 需要集群管理员绑定，并且该绑定应为集群中唯一的绑定
资源策略 否 是 通过门禁程序突变为所有 Pod 设置默认值来修复此问题
控制平面强化 是
不安全的功能 否 是 添加了门禁程序限制来禁止危险功能，并添加了一个突变以设置默认值。
异常某些 Pod（如 contour/envoy）需要高级权限才能正常运行。Tanzu 系统输入需要与网络交互
不可变的容器文件系统 否 是 添加了一个门禁程序限制以防止禁用 readOnlyRootFilesystems。
异常 由 contour/envoy、fluentd、kapp 控制器、遥测代理以及需要在 k8s 上运行的所有其他数据服务创建的 Pod
小心此突变可能会导致集群中出现问题，并且可能是最不明智的实施选项。
特权容器 否 是 默认情况下，所有 Pod 的特权均设置为 false，但添加了限制以强制用户不启用特权。
已阻止输入和输出 否 是 可以在 Antrea 中实施默认拒绝集群网络策略
容器主机端口 否 是 添加了一个网关守护程序限制，以确保用户不使用主机端口。
异常 Kapp 控制器需要访问主机才能使 tanzu 正常工作，并且是控制平面外唯一允许访问主机网络的 Pod
网络策略 否 是 可以安装一套网络策略，以确保所有命名空间都具有网络策略
将 Fluent Bit 转发到 SIEM 否 是 需要安装 Fluent bit 并将其指向有效的输出位置
已启用 Fluent Bit 重试 否 是 用户需要在配置中启用重试的情况下安装 Fluent bit
IAAS 元数据端点被阻止 否 是 可以实施集群网络策略以限制所有 Pod 命中端点
check-circle-line exclamation-circle-line close-line
Scroll to top icon