Kubernetes 1.33 安全强化：生产环境集群实用指南

在企业环境中，Kubernetes 集群仍然是最常被错误配置的基础设施组件之一。尽管安全工具已经成熟多年，容器安全意识也在不断提高，但审计结果始终显示相同类别的错误配置反复出现：过度宽松的 RBAC 权限、缺失的网络策略、在生产环境中运行未经扫描的镜像，以及以明文形式存储在环境变量中的密钥。Kubernetes 1.33 引入了默认安全态势的改进，但操作员做出的配置选择仍然决定了实际的安全结果。

RBAC：持续存在的错误配置问题

基于角色的访问控制（RBAC）是 Kubernetes 的主要授权机制，但它的实现往往过于宽松。最危险的模式是为应该具有有限命名空间范围访问权限的服务账户使用 ClusterAdmin 或集群范围的通配符权限。一个以 ClusterAdmin 权限运行的受损 Pod 可以枚举整个集群、读取所有密钥，并创建具有主机网络访问权限的特权 Pod。

有效的 RBAC 强化应从使用 kubectl-who-can 或 Fairwinds Insights 等工具审核现有权限开始，以识别过度权限的主体。对于每个服务账户，枚举您的应用程序实际进行的 API 调用，并创建一个恰好授予这些权限的 Role 或 ClusterRole — 不多不少。通过准入 Webhook 强制执行此纪律，拒绝具有通配符权限的服务账户。

Pod 安全：超越 Pod 安全策略

Pod 安全准入（PSA）在 Kubernetes 1.25 中取代了已弃用的 Pod 安全策略，强制执行三种安全配置文件：特权（无限制）、基线（防止已知的权限提升）和受限（遵循当前的强化最佳实践）。在 Kubernetes 1.33 中，默认执行模式已更新为将基线配置文件应用于所有命名空间，除非被明确覆盖。

对于生产工作负载，尽可能针对受限配置文件。这意味着以非 root 用户运行容器、删除所有功能、使用只读根文件系统，并要求 seccomp 配置文件。许多容器化应用程序只需要最少的更改即可符合受限配置文件 — 通常阻碍因素是在测试期间出现的关于文件系统写入访问或网络绑定能力的未记录假设。

网络策略

默认情况下，Kubernetes 允许集群中所有 Pod 之间进行无限制的通信。网络策略实现了微分段 — 允许您指定哪些 Pod 可以与哪些其他 Pod 通信，使用哪些端口，以及使用哪些协议。没有网络策略，一个受损的 Pod 可以到达集群中的任何其他服务，包括控制平面组件和密钥存储。

实施默认拒绝的 NetworkPolicy 来阻止所有入站和出站流量，然后仅明确允许必要的连接，这是最有效的方法。这需要仔细映射应用程序的实际网络依赖关系——这一发现过程常常揭示了不应存在的意外连接。发现成本是值得的：实施默认拒绝网络策略的组织报告称，在容器被攻破时，影响范围显著缩小。

密钥管理

存储在 etcd 中的 Kubernetes Secrets 默认是 base64 编码的——而非加密。任何能够访问 etcd 或有权读取目标 namespace 中 Secrets 的主体都可以获取密钥值。使用外部 KMS（AWS KMS、Google Cloud KMS 或 HashiCorp Vault）为 etcd 启用静态加密，可为存储的密钥提供真正的保护。

对于运行时密钥注入，应避免使用环境变量——它们对容器中运行的任何进程都可见，会出现在崩溃转储中，并且经常被包含在调试日志中。将密钥作为具有严格权限的卷挂载，或使用基于 sidecar 的密钥注入模式，在这种模式中密钥永远不会出现在 pod 规范中。External Secrets Operator 和 Vault Agent Injector 是该领域的成熟选项。

供应链安全

容器镜像供应链是许多组织安全保护不足的关键攻击面。在进入生产环境之前，应对镜像进行已知漏洞扫描——这是基本的安全措施。使用 Sigstore/Cosign 进行镜像签名和验证可确保只有来自可信注册表的签名镜像才能在集群中运行。像 Kyverno 或 OPA Gatekeeper 这样的策略引擎在准入时强制执行这些要求。

基础镜像固定——使用 SHA256 摘要而非像 “latest” 这样的可变标签——可以防止在初始安全审查后镜像被攻破的供应链攻击。固定您的基础镜像，并实施定期的更新节奏来轮换到修补版本，而不是依赖无法提供完整性保证的可变标签。

监控和运行时检测

Falco 仍然是 Kubernetes 环境中运行时安全监控的标准。其规则库涵盖了最常见的攻击模式——意外的出站连接、权限提升尝试、敏感文件访问和进程执行异常。将 Falco 警报集成到您的安全运营中心，可以创建一个检测层，补充上述的预防控制措施。

安全加固不是一次性项目。随着应用程序的演化和团队在时间压力下做出权宜之计，集群配置会逐渐偏离。针对已定义基线进行定期自动合规性扫描——使用像 kube-bench 这样的工具进行 CIS 基准合规性检查——可以在配置偏离成为安全事件之前捕获这些问题。

Anna Kowalski📍 Warsaw, Poland

Zero-Trust Architecture Analyst covering identity management, micro-segmentation, and European NIS2 compliance. PhD candidate in information security at Warsaw University of Technology.

More by Anna Kowalski →