手册

构建整体云原生安全策略。

→在 4C 模型（云、集群、容器和代码）中实施安全控制。

原因: 外部层（例如云）的漏洞会损害所有内部层的安全性。安全强度取决于其最薄弱的环节。

参考↗

防范单点安全故障。

→在不同层（例如 NetworkPolicies、RBAC、Security Contexts）实施多个重叠的安全控制。

原因: 如果一个控制失败或被绕过，其他层将继续提供保护，增加攻击者的难度。

在网络位置不是受信任边界的环境中保护网络流量。

→实施“永不信任，始终验证”模型。对每个请求进行身份验证和授权，通常使用服务网格实现 mTLS。

原因: 假设威胁可以存在于网络内部和外部，消除基于网络位置的隐式信任。

限制受损身份或组件的影响范围。

→仅授予所有主体（用户、Service Account、节点）执行其功能所需的最低权限。

原因: 减少攻击者利用窃取的凭据可能造成的潜在损害。

降低安全漏洞的成本和影响。

→将自动化安全扫描（SAST、SCA、镜像扫描）和策略检查集成到 CI/CD 流水线的早期阶段。

原因: 在开发生命周期的早期发现并修复漏洞，此时修复成本最低。

在 etcd 存储受损时保护敏感集群数据（尤其是 Secrets）。

→在 kube-apiserver 上，使用 `--encryption-provider-config` 为资源启用静态加密，然后再将其存储到 etcd 中。

原因: 默认情况下，Kubernetes Secrets 在 etcd 中仅进行 base64 编码。这提供了真正的磁盘加密。

参考↗

防止对 etcd 通信的未经授权访问和窃听。

→为 etcd 配置 mTLS，用于客户端 (`--client-cert-auth`) 和对等 (`--peer-client-cert-auth`) 通信。

原因: 确保只有经过身份验证的组件（apiserver、其他 etcd 成员）可以与 etcd 通信，并且流量是加密的。

防止未经身份验证访问 Kubernetes API 服务器。

→设置 `--anonymous-auth=false` 标志。使用 OIDC 或 x509 证书等强身份验证方法。

原因: 禁用 `system:anonymous` 用户，强制所有请求都经过身份验证并针对特定身份进行日志记录。

要求跟踪所有更改和访问尝试，以满足安全和合规性要求。

→使用 `--audit-policy-file` 启用 API 服务器审计日志记录，并将日志发送到外部的不可变日志系统。

原因: 为事件调查、威胁搜寻和合规性审计提供必要且防篡改的跟踪记录。

参考↗

减少工作节点的攻击面。

→设置 kubelet 标志：`--anonymous-auth=false`、`--authorization-mode=Webhook` 和 `--read-only-port=0`。

原因: 这强制所有对 kubelet API 的请求都由 API 服务器进行身份验证和授权，并禁用不安全、未经身份验证的只读端口。

防止控制平面组件的信息泄露。

→在生产环境中，在 kube-apiserver、kube-controller-manager 和 kube-scheduler 上设置 `--profiling=false` 标志。

原因: 分析端点可能会暴露内部性能数据和系统详细信息，这些信息可能有助于攻击者进行侦察。

保护控制平面组件免受未经授权的网络访问。

→使用防火墙规则（云安全组、iptables）将对 API 服务器（6443）和 etcd（2379）端口的访问限制为仅限受信任的来源。

原因: 网络级访问控制是防御的基础层，可以阻止攻击者甚至无法访问敏感组件 API。

授予用户或应用程序权限。

→优先使用命名空间 `Roles` 而非 `ClusterRoles`。授予特定的动词 (`get`, `list`) 而不是通配符 (`*`)。

原因: 遵循最小权限原则，将权限范围限制在特定命名空间内必要的范围。

参考↗

Pod 不需要与 Kubernetes API 通信。

→在 Pod 规约或 ServiceAccount 本身中设置 `automountServiceAccountToken: false`。

原因: 防止在 Pod 内部暴露不必要的凭据，从而在 Pod 受损时减少攻击面。

在命名空间中为所有 Pod 强制执行基线安全态势。

→通过应用命名空间标签（例如 `pod-security.kubernetes.io/enforce: baseline`）来使用内置的 `PodSecurity` 准入控制器。

原因: 提供了一种标准化、内置的方式，无需第三方工具即可防止有风险的 Pod 配置（如特权容器）。

参考↗

加强单个容器安全以防止权限提升。

→在 Pod 规约中，设置 `securityContext` 字段：`runAsNonRoot: true`、`allowPrivilegeEscalation: false`、`readOnlyRootFilesystem: true`。

原因: 这些控制可以防止以 root 身份运行，阻止获取新权限的机制，并使容器文件系统不可变，从而大幅减少漏洞利用的影响。

在集群内实施零信任网络模型。

→为每个命名空间应用一个默认拒绝的 NetworkPolicy，该策略选择所有 Pod (`podSelector: {}`) 并具有空的入站/出站规则列表。

原因: Kubernetes 网络默认允许。此策略将模型反转为默认拒绝，强制开发人员明确允许所需的流量。

仅允许特定应用程序层（例如，web 到 api）之间的流量。

→创建使用 `podSelector` 和 `namespaceSelector` 的 NetworkPolicies，以根据标签定义细粒度的入站和出站规则。

原因: 通过确保受损 Pod 只能与明确授权的对等体通信，防止攻击者的横向移动。

用户需要 `kubectl exec` 到容器进行调试的权限。

→在相关的 Role 或 ClusterRole 中，授予 `pods/exec` 子资源上的 `create` 动词。

原因: `exec` 操作反直觉地由 `create` 动词控制，因为它会创建一个新的 exec 会话。这是一个常见的混淆点。

攻击者获得对容器的访问权限并试图危害宿主节点。

→禁止特权容器 (`securityContext.privileged: false`)、宿主命名空间 (`hostNetwork`, `hostPID`) 和挂载 Docker socket。

原因: 这些配置有效地打破了容器隔离，使受损容器能够获得宿主机的 root 级访问权限。

防止部署包含已知漏洞或恶意代码的容器镜像。

→在 CI/CD 流水线中并通过准入控制实施镜像扫描（例如 Trivy）和镜像签名验证（例如 Cosign）。

原因: 提供纵深防御方法：扫描捕获已知漏洞，而签名验证镜像的完整性和来源。

攻击者已攻陷一个 Pod 并试图访问集群中的其他 Pod。

→实施默认拒绝的 NetworkPolicies，并且仅为所需的 Pod 到 Pod 通信创建特定的允许规则。

原因: 限制攻击者从受损 Pod 的“视线”，遏制漏洞并防止其扩散。

防止受损 Pod 从实例元数据服务窃取云 IAM 凭据。

→应用默认拒绝的出站 NetworkPolicy，明确阻止流向元数据 IP（例如 `169.254.169.254/32`）的流量。

原因: 这是云环境中常见的攻击路径。阻止此出站路径可降低从 Pod 窃取 IAM 凭据的风险。

防范耗尽节点资源的拒绝服务或加密劫持攻击。

→对命名空间应用 `ResourceQuota` 对象以限制总资源使用，并应用 `LimitRange` 对象以对单个 Pod 强制执行限制。

原因: 确保没有单个租户或工作负载会耗尽其他资源的可用性，从而提供稳定性并防止滥用。

攻击者试图维持对受损集群的长期访问。

→监控意外的 `DaemonSets`、`CronJobs` 或特权 Pod 的创建。限制创建这些资源的权限。

原因: 攻击者使用这些工作负载类型来确保其恶意代码持久运行，即使节点或 Pod 重新启动。

确保容器镜像在部署前没有已知漏洞。

→将 Trivy、Clair 或 Grype 等镜像扫描器集成到 CI/CD 流水线中，扫描镜像并在发现严重漏洞时使构建失败。

原因: 自动化早期漏洞检测（“左移”），防止有漏洞的代码进入生产环境。

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

→在 CI 流水线中使用 Cosign 等工具对镜像进行签名。在部署时使用验证准入控制器（例如 Kyverno、Gatekeeper）来验证签名。

原因: 提供镜像完整性（未被篡改）和来源（来自受信任源）的加密证明。

检测运行中容器内的恶意活动（例如，生成 shell，访问敏感文件）。

→部署 Falco 等运行时安全工具，该工具使用 eBPF 监控系统调用，并根据定义的规则集对可疑行为发出警报。

原因: 提供运行时活动的可见性，这是静态扫描和准入控制无法看到的。它对于检测活动入侵至关重要。

强制执行自定义、组织特定的安全策略（例如，“所有镜像必须来自我们的企业注册表”）。

→使用 OPA Gatekeeper 或 Kyverno 等策略引擎作为验证准入控制器，强制执行用 Rego 或 YAML 编写的策略。

原因: 允许灵活、声明式和自动化地强制执行超出 Kubernetes 内置控制范围的安全策略。

加密和验证集群内的所有服务到服务流量。

→实现服务网格（例如 Istio、Linkerd），为所有网格服务自动提供相互 TLS (mTLS)。

原因: 通过确保所有集群内流量都经过加密以及服务相互验证彼此身份来实现零信任网络。

运行需要比标准容器更强隔离的不可信或多租户工作负载。

→使用 gVisor 或 Kata Containers 等沙盒容器运行时，它们在容器和宿主内核之间提供额外的隔离层。

原因: 减少宿主内核的攻击面，使容器逃逸变得更加困难。

在内核级别对容器权限进行细粒度控制。

→使用 Seccomp 配置文件过滤允许的系统调用，并使用 AppArmor/SELinux 配置文件对文件和网络访问强制执行强制访问控制 (MAC)。

原因: 这些 Linux 原生安全功能提供了深层防御，限制了受损容器进程基本可以执行的操作。

减少容器镜像内的攻击面。

→使用仅包含应用程序及其直接依赖项的最小化或“无发行版 (distroless)”基础镜像构建应用程序镜像。

原因: 移除生产环境中不必要且可能在受损后被攻击者使用的 shell、包管理器和其他实用程序。

验证 Kubernetes 集群是否按照安全最佳实践进行配置。

→定期运行 `kube-bench`，这是一个自动化工具，用于根据 CIS Kubernetes Benchmark 检查集群。

原因: 提供标准化、全面和自动化的方式来审计集群安全态势并识别错误配置。

集群必须按照 PCI DSS 合规性要求处理和存储信用卡数据。

→使用 NetworkPolicies 进行网络分段以隔离持卡人数据环境 (CDE)，并为 etcd 启用静态加密。

原因: 这些控制直接映射到 PCI DSS 对网络分段（要求 1）和存储持卡人数据保护（要求 3）的要求。

集群处理受保护健康信息 (PHI) 且必须符合 HIPAA。

→实施严格的 RBAC，启用全面的审计日志记录，并确保数据在静态和传输中均已加密。

原因: 这些控制解决了 HIPAA 在访问控制、审计控制和传输安全方面的技术保障要求。

确保审计日志为合规性和取证目的而保留，即使集群被攻陷。

→配置 API 服务器将审计日志流式传输到外部的、一次写入/不可变的日志后端（例如，SIEM 或锁定的云存储桶）。

原因: 防止具有 cluster-admin 权限的攻击者通过修改或删除本地审计日志来掩盖其踪迹。