手册

根据行业标准安全最佳实践评估集群配置。

→使用 `kube-bench` 对控制平面和工作节点运行 CIS Kubernetes 基准检查。

原因: `kube-bench` 是此特定任务的标准工具，可自动化针对全面 CIS 指南的检查。

参考↗

对所有 API 服务器请求强制执行强身份验证。

→设置 `kube-apiserver` 标志：`--anonymous-auth=false` 以拒绝未经身份验证的请求，并设置 `--client-ca-file` 以强制执行客户端证书验证 (mTLS)。

原因: 这些标志是消除匿名访问并强制执行与 API 服务器的经过身份验证的加密通信的基本控制。

参考↗

保护集群的 etcd 状态存储，防止未经授权的访问和数据盗窃。

→为所有客户端和对等通信配置 etcd 的 mTLS（`--cert-file`、`--key-file`、`--peer-cert-file`）。通过 API 服务器的 `--encryption-provider-config` 标志启用静态秘密加密。

原因: etcd 包含所有集群秘密。加密传输中 (mTLS) 和静态数据对于保护敏感信息至关重要，即使 etcd 节点遭到入侵。

参考↗

在零停机时间内轮换 etcd 静态加密密钥。

→1. 将新密钥添加为 `EncryptionConfiguration` 文件中的第一个条目。2. 重启所有 API 服务器。3. 强制重新加密所有秘密（`kubectl get secrets -A -o json | kubectl replace -f -`）。4. 验证后，从配置中移除旧密钥并再次重启 API 服务器。

原因: 更改配置仅影响新写入。必须重写现有数据才能使用新密钥加密。过早移除旧密钥将导致您无法访问数据。

在命名空间内实施零信任网络模型。

→应用一个 `NetworkPolicy`，其中 `podSelector: {}` 为空，`policyTypes: [Ingress, Egress]`，但没有 `ingress` 或 `egress` 规则。这将选择所有 Pod 并拒绝所有流量。

原因: 此策略建立了一个“拒绝所有”基线，强制所有必需的通信都必须有明确的“允许”规则，这是零信任网络的基础。

参考↗

出口 NetworkPolicy 正在阻止 Pod 的 DNS 解析。

→添加一个特定的出口规则以允许流量流向集群 DNS 服务。允许 UDP 和 TCP 协议的 53 端口出站。如果可能，通过 `namespaceSelector` 和 `podSelector` 选择 kube-dns Pod。

原因: NetworkPolicy 是精细的。指向 IP 块的通用出口规则可能无法涵盖 DNS 所需的特定协议 (UDP)，从而导致解析失败。

通过 Ingress 暴露的服务实现外部访问安全。

→通过添加引用类型为 `kubernetes.io/tls` 的 Kubernetes Secret 的 `tls` 部分来配置 Ingress 资源。该 Secret 必须包含 TLS 证书和私钥。

原因: 这在 Ingress 控制器处集中了 TLS 终止，加密了从客户端到集群边界的流量，并简化了后端服务的证书管理。

仅授予用户或应用程序所需的最小权限。

→尽可能使用命名空间范围的 `Roles` 和 `RoleBindings`。避免在 `verbs` 或 `resources` 中使用 `cluster-admin` 和通配符（`"*"`)。授予诸如 `["get", "list"]` 对 `["pods"]` 的特定权限。

原因: 这最大限度地减少了账户或令牌被入侵时的影响范围，防止横向移动和权限提升。

参考↗

减少不需要与 Kubernetes API 交互的 Pod 的攻击面。

→通过在 ServiceAccount 或 Pod 规范中设置 `automountServiceAccountToken: false` 来禁用服务账户令牌的自动挂载。

原因: 如果 Pod 遭到入侵，攻击者无法利用挂载的令牌访问 API 服务器，从而防止源自受损 Pod 的集群级攻击。

验证特定用户或服务账户是否具有执行某个操作的权限。

→使用 `kubectl auth can-i <verb> <resource> --as=<user>` 或 `kubectl auth can-i <verb> <resource> --as=system:serviceaccount:<ns>:<sa-name>`。

原因: 此命令允许模拟，以准确检查有效权限，而无需手动解析所有 Role 和 Binding。

通过定期轮换控制平面和 kubelet 证书来维护集群安全。

→对于 kubeadm 集群，使用 `kubeadm certs renew all`。对于其他集群，请遵循文档化的手动或自动化轮换过程。通过配置启用 kubelet 客户端/服务器证书轮换。

原因: 定期轮换限制了攻击者使用受损证书的时间窗口。这是一项关键的安全卫生实践。

参考↗

一个工作节点被怀疑遭到入侵，必须立即隔离。

→首先，使用 `kubectl cordon <node-name>` 阻止新 Pod 被调度。然后，使用 `kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data` 安全地驱逐运行中的工作负载。

原因: 封锁 (cordoning) 和排空 (draining) 是将节点从服务中移除的标准、非破坏性过程，允许工作负载在其他地方重新调度，同时保留受损节点以进行取证分析。

限制容器可以向主机内核发出的系统调用。

→在 Pod 或容器的 `securityContext` 中，将 `seccompProfile.type` 设置为 `RuntimeDefault` 以获得安全基线，或设置为 `Localhost` 并指定自定义 JSON 配置文件的路径以进行更严格的控制。

原因: Seccomp 从容器内部减少了内核攻击面，通过阻止未使用或危险的系统调用来防止针对内核漏洞的利用。

参考↗

通过限制对文件、网络功能和其他资源的访问来约束容器进程。

→通过注解将 AppArmor 配置文件应用于容器：`container.apparmor.security.beta.kubernetes.io/<container_name>: localhost/<profile_name>`。该配置文件必须预先加载到节点上。

原因: AppArmor 提供了强制访问控制 (MAC)，增加了一个关键的深度防御层，用于遏制受损应用程序并阻止其访问未经授权的资源。

参考↗

容器需要执行特定的特权操作（例如，绑定到端口 80），而无需以 root 身份运行。

→在 `securityContext.capabilities` 中，先 `drop: ["ALL"]`，然后 `add: ["NET_BIND_SERVICE"]`。

原因: 这遵循了最小权限原则，仅授予所需的特定 Linux 功能，避免了以 root 身份运行的广泛权限。

防止容器获得对主机系统的完全访问权限。

→设置 `securityContext.privileged: false`（这是默认值）。使用 Pod 安全标准或 OPA/Kyverno 在整个集群中强制执行此策略。

原因: 特权容器几乎拥有所有主机功能和设备访问权限，从而有效地禁用了容器隔离。它是容器逃逸的主要途径。

在命名空间级别强制执行 Pod 的基线或严格安全配置。

→向命名空间应用标签，例如 `pod-security.kubernetes.io/enforce: restricted`。模式包括 `enforce`、`audit` 和 `warn`。

原因: Pod 安全标准 (PSS) 提供了一种内置的多级安全策略，取代了已弃用的 PodSecurityPolicy，使其易于强制执行安全最佳实践。

参考↗

通过同时应用多个安全控制来强化 Pod。

→配置一个 `securityContext`，结合 `runAsNonRoot: true`、`allowPrivilegeEscalation: false` 和 `readOnlyRootFilesystem: true`。

原因: 这种深度防御方法分层了多重保护：阻止 root 执行，阻止特权提升向量（如 setuid），并使容器文件系统不可变。

以比标准容器更强的隔离性运行不受信任或多租户工作负载。

→定义一个指向沙盒运行时处理程序（例如 gVisor、Kata Containers）的 `RuntimeClass` 资源。使用 `spec.runtimeClassName` 将 Pod 分配给它。

原因: 沙盒运行时使用用户空间内核或轻量级虚拟机来拦截系统调用，在容器和主机内核之间提供额外的隔离层。

参考↗

强制执行标准 Kubernetes 控制未涵盖的复杂自定义安全策略。

→部署 OPA Gatekeeper。使用 `ConstraintTemplate`（Rego 逻辑）定义策略，并使用 `Constraint` 资源应用它们。

原因: Gatekeeper 作为验证准入 webhook 运行，允许您强制执行任意规则，例如要求特定标签、禁止主机路径或强制执行资源限制。

参考↗

以最安全的方式向 Pod 提供秘密。

→将秘密作为文件挂载到卷中。为了更高的安全性，使用秘密存储 CSI 驱动程序直接将秘密从外部保管库（例如 HashiCorp Vault、AWS Secrets Manager）挂载到 Pod 中。

原因: 以文件形式挂载比环境变量更安全（环境变量可能会被记录或暴露）。CSI 驱动程序完全避免将秘密存储在 etcd 中。

自动加密和认证所有 Pod 到 Pod 的网络流量。

→部署像 Istio 或 Linkerd 这样的服务网格。网格会将一个 Sidecar 代理注入到每个 Pod 中，以处理 mTLS 加密、身份验证和策略执行。

原因: 服务网格提供了透明的零信任网络，无需任何应用程序代码更改，从而保护所有内部服务通信。

防止部署包含已知漏洞 (CVE) 的容器镜像。

→将 Trivy 或 Grype 等扫描器集成到 CI/CD 流水线中。如果漏洞超过定义的严重性阈值（例如 HIGH 或 CRITICAL），则使构建失败。

原因: 这种“左移”方法在漏洞进入生产环境之前尽早捕获它们，从而大幅减少运行中应用程序的攻击面。

参考↗

确保只有受信任的、未修改的容器镜像部署到集群中。

→在 CI 构建过程中使用 `cosign` 签署镜像。使用策略引擎（Kyverno、OPA Gatekeeper）作为准入控制器，在允许创建 Pod 之前，根据公钥验证签名。

原因: 密码签名提供了镜像完整性（未被篡改）和真实性（来自受信任来源）的强有力保证。

参考↗

最小化容器镜像本身的攻击面。

→使用最小化的基础镜像（例如 distroless、Alpine）。使用多阶段 Dockerfile 丢弃构建工具。使用 `USER` 指令设置非 root 用户。使用 `.dockerignore` 排除敏感文件。

原因: 最小化镜像包含更少的软件包和工具，提供了更少的潜在漏洞，并使得攻击者在容器被入侵时更难进行横向移动。

强制执行所有部署的镜像必须源自组织私有仓库的策略。

→使用准入控制器（如 OPA Gatekeeper 或 Kyverno）创建策略，根据注册表主机名白名单验证所有容器规范的 `image` 字段。

原因: 这可以防止开发人员从 Docker Hub 等公共仓库拉取不受信任或未经扫描的镜像，确保所有代码都经过了内部安全检查。

维护容器镜像中所有软件组件和依赖项的清单。

→将 `Syft` 等工具集成到 CI/CD 流水线中，以生成 SPDX 或 CycloneDX 等标准格式的软件物料清单 (SBOM)。

原因: SBOM 对于供应链安全至关重要，当在依赖项中发现新漏洞时，能够快速识别所有受影响的资产。

在 Kubernetes YAML 清单应用之前识别其中的安全配置错误。

→在 CI 流水线中，使用 `trivy config` 或 `kubesec` 等工具扫描 Kubernetes 清单文件，查找危险配置，例如以 root 身份运行、允许特权提升或挂载敏感主机路径。

原因: 这种主动检查在基础设施即代码中捕获安全问题，防止它们在运行中的集群中创建漏洞。

检测并警报运行中容器内部或集群节点上的可疑活动。

→将 Falco 作为 DaemonSet 部署。Falco 使用 eBPF 或内核模块监控系统调用，并根据其规则集（例如容器中的 shell、意外的网络连接）对异常行为发出警报。

原因: Falco 提供对运行时行为的实时可见性，能够检测静态扫描无法发现的威胁，例如容器逃逸、加密挖矿或数据外泄。

参考↗

默认的 Falco 规则产生了过多的误报。

→创建一个自定义 Falco 规则文件以覆盖默认规则。在规则的 `condition` 中添加例外，以排除已知正常行为，例如特定进程或容器镜像（例如 `and not container.image.repository contains "debug"`）。

原因: 调整规则对于运行时安全的操作化至关重要。减少噪音可确保安全团队能够专注于可操作的、高优先级的警报。

记录所有针对 Kubernetes API 执行操作的按时间顺序排列的不可变日志。

→通过提供 `--audit-policy-file` 和 `--audit-log-path` 标志，在 `kube-apiserver` 上启用审计日志。配置策略以定义要记录的内容和级别。

原因: 审计日志对于安全分析、事件调查和合规性至关重要。它们提供了谁在何时做了什么的明确记录。

参考↗

审计对 Secrets 等敏感资源的访问，但不记录秘密内容本身。

→将 Secrets 的审计策略规则配置为使用 `level: Metadata`。这将记录用户、时间戳、资源和动词，但省略请求和响应正文。

原因: 这提供了对谁访问秘密的问责制，同时避免了通过将敏感数据写入审计日志而产生新的安全风险。

聚合所有集群组件和应用程序的日志以进行集中分析。

→部署一个日志收集代理（例如 Fluentd、Vector）作为 DaemonSet，从节点收集日志并将其转发到集中式 SIEM 或日志管理系统（例如 Elasticsearch、Splunk）。

原因: 集中式日志记录对于在事件调查期间关联集群中的事件以及维护长期合规记录至关重要。

将 Falco 安全警报转发到外部系统以进行通知和响应。

→与 Falco 一起部署 `Falcosidekick`。配置它以接收来自 Falco 的警报并将其转发到 Slack、PagerDuty 或 SIEM 等输出。

原因: Falcosidekick 提供了一种灵活而强大的机制，可将 Falco 的实时警报集成到现有的操作和安全工作流中。

检测运行中的容器是否已被修改，这可能表明存在入侵。

→使用 `readOnlyRootFilesystem: true` 强制执行不可变容器。使用像 Falco 这样的运行时安全工具来监控并警报对意外位置的任何文件写入。

原因: 在不可变模型中，容器在运行时永不更改；它们被替换。任何偏离此模式的行为都是潜在安全漏洞的强烈指示。