Kubernetes 的默认态势是灵活性优先，而非安全性。每个开放端口、每个宽松的 RBAC 角色、每个不受限制的 Pod 都是一个邀请。加固集群意味着系统地关闭这些漏洞，同时不破坏依赖它们的工作负载。这不是一个清单检查项——它是一个持续的工作纪律，涉及身份、网络、工作负载和供应链层面。
首先锁定控制平面
API 服务器是任何集群中价值最高的单一目标。首先禁用匿名身份验证并强制使用强身份验证方法——与身份提供者的 OIDC 集成优于永不过期的静态令牌或客户端证书。限制对 etcd 数据存储的访问，因为它以明文形式保存每个密钥和配置对象，除非启用了静态加密。使用 KMS 提供程序为密钥启用加密，而不是依赖 base64 编码（它提供零实际保护）。应从第一天开始启用审计日志；没有它，当出问题时你就没有法医踪迹。
RBAC：最小权限，而非便利
生产集群中最常见的配置错误是 RBAC 绑定过于宽泛——cluster-admin 被授予仅需要在一个命名空间中读取 Pod 的服务账户。围绕实际工作职能构建角色，并尽可能将其范围限定在命名空间内。避免在 Role 和 ClusterRole 定义中使用通配符动词和资源。使用 kubectl auth can-i --list 或 rbac-lookup 等工具定期审计绑定，以捕捉权限蔓延。服务账户应该受到与人类用户相同的审查——禁用不需要 API 访问的 Pod 的服务账户令牌自动挂载。
Pod 安全：假设已被入侵
Pod 安全准入（取代了已弃用的 PodSecurityPolicy）允许你在命名空间级别强制基准或受限配置文件。至少禁止特权容器、主机命名空间共享和权限提升。设置 runAsNonRoot: true 并默认删除所有 Linux 功能，仅添加回明确需要的功能。只读根文件系统可防止攻击者将恶意二进制文件写入正在运行的容器。这些控制之所以重要，是因为容器逃逸或被利用的应用程序漏洞不应导致完整的节点破坏。
网络策略不是可选的
默认情况下，Kubernetes 集群中的每个 Pod 都可以与其他所有 Pod 通信。这种平坦网络模型是攻击者横向移动的梦想。实现 NetworkPolicy 资源以强制执行默认拒绝入站和出站，然后明确仅允许应用程序所需的流量流。这需要一个真正支持 NetworkPolicy 强制执行的 CNI 插件——Calico、Cilium 和其他插件承担了这一角色，因为基础 Kubernetes 网络模型本身不强制任何东西。按信任边界对命名空间进行分段，并在其上层叠网络策略为你提供真正的纵深防御。
镜像和供应链完整性
加固不只是在运行时配置处停止——它从你部署的内容开始。在容器镜像到达你的仓库之前扫描它们是否存在已知漏洞，并使用 Kyverno 或 OPA Gatekeeper 等准入控制器强制只有经过签名、验证的镜像才能在集群中运行。将镜像标签固定到摘要而不是 latest 等可变标签，这些标签可能会在你不知情的情况下更改。限制 Pod 允许从哪些仓库拉取镜像，关闭供应链攻击的常见路径，在这种情况下，被破坏或使用了打字错误的镜像会悄悄进入生产环境。
密钥管理超越 Kubernetes 默认值
原生 Kubernetes Secrets 总比没有好，但它们不是真正的密钥管理解决方案。考虑集成外部密钥管理器——Vault、AWS Secrets Manager 或类似的——并在运行时注入密钥，而不是将它们存储为集群对象。如果必须使用原生 Secrets，请确保启用 etcd 加密，并通过 RBAC 严格限制读取访问，因为任何对命名空间中的密钥拥有 get 权限的 Pod 或用户都可以泄露凭据。
持续验证，而非一次性设置
随着新工作负载的部署和优先级从安全转向速度，加固配置会随时间而漂移。kube-bench 等工具根据 CIS Kubernetes Benchmark 检查合规性，而 kube-hunter 可以模拟对集群的攻击者侦察。将这些检查融入 CI/CD 管道中，以便在错误配置到达生产环境之前被捕捉到，而不是在事件响应电话中。
Kubernetes 加固不是关于单个银弹控制，而是关于在身份、网络、工作负载和供应链中分层防御——使得一层中的失败不会级联到完整的破坏。有关云基础设施安全模式和防御工具的更多信息，请探索 Korra Studio 的 DEFENSE_GRID 平台上的相关部分。
