STIG 和 NSA/CISA 强化

默认情况下，由独立管理集群部署的 Tanzu Kubernetes Grid (TKG) 工作负载集群强化到 STIG 结果和异常以及 CIS 结果和异常中显示的级别。本主题介绍了如何进一步强化集群。

方法取决于集群是基于类还是基于计划，如工作负载集群类型中所述。

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

基于类的工作负载集群中的其他 Kubernetes 强化

要在基于类的工作负载集群中提高 Kubernetes 的 STIG 和 CIS 合规性，请按照以下部分中所述对其进行配置。

要进行更精细的异常处理，可以按照 STIG 结果和异常和 CIS 结果和异常中的异常表中列出的解决办法进行操作。

STIG 强化

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

在集群配置文件中包含以下变量设置

设置本地环境中的变量，例如使用 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

NSA/CISA 强化

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

查看下面的事件速率限制配置。如果要更改任何设置，请将代码保存到 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

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

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

在集群配置文件中包含以下变量设置

设置本地环境中的变量，例如使用 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==

基于类的工作负载集群中的其他操作系统强化

要根据 STIG 或 CIS 标准强化基于类的工作负载集群中的 Ubuntu OS v20.04，请运行具有 STIG 或 CIS 强化的 ansible_user_vars 设置的 Image Builder，以便为集群创建自定义强化虚拟机映像，如构建 Linux 影像中所述

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

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

您可以通过在 CLI 配置中将 allow-legacy-cluster 设置为 true 来创建旧版集群，如《Tanzu CLI 架构和配置》中的功能所述。

STIG 强化

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

以下代码片段是 ytt 覆盖网络以设置 tls-min-version (STIG: V-242378)（在 api-server 上）。

#@ 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 部署的风险偏好。

《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 命中端点