最近的几个事件串起来看，Kubernetes 的安全重心明显变了：集群本身的漏洞还在，但攻击者更多地在打供应链和 CI/CD 这一层。
几个真实事件
TanStack 遭遇了一次相当成熟的 npm 供应链攻击，波及 42 个包，影响范围甚至包括两台 OpenAI 员工的设备，迫使 macOS 更新。攻击者利用的是不安全的 CI 工作流模式。
Dell 为 Container Storage Modules 发布安全公告，其中 CVE-2026-63688 和 CVE-2026-63692 都是 CVSS 10.0：前者是 CSM Authorization 存储 gRPC 服务缺失认证，未认证的远程攻击者可获取所有已注册存储阵列的管理员凭据；后者可绕过认证提权，跨租户操纵存储资源。另外 CVE-2026-67269 评分 9.9，低权限远程攻击者可提权到集群节点 root。修复版本是 1.18.0 及以上。
HyperShift operator 的 CVE-2026-101919 则展示了另一种路径：operator 直接把租户提交的 kubeconfig secret 复制进特权命名空间且不校验，而 kubeconfig 支持 exec 凭据插件，下游控制器加载时就会执行攻击者指定的二进制。
该做的六件事
第一，供应链安全标准化：SLSA 来源验证、Sigstore 签名、依赖审计。Red Hat 的报告里，有明确策略的组织对供应链安全的信心是 61%，这个数字说明策略本身就是有效资产。
第二，加固 CI/CD：避免 pull_request_target 这类不安全的模式，做缓存隔离，把 GitHub Actions 固定到具体 SHA 而不是分支或标签。TanStack 事后做的就是这些。
第三，把 Kubernetes 扩展当成攻击面。存储控制器、安全控制器这些插件要定期更新、监控 CVE，并盘点所有自定义资源定义。
第四，严格执行最小权限。用短期的 OIDC 凭据替代长期 token，密钥放密钥管理系统而不是环境变量。
第五，审计提交自定义资源的权限。HyperShift 那个漏洞说明，能提交 secret 和 CR 的低权限账号，可能等价于控制平面权限。
第六，从救火转向平台化。把安全护栏直接嵌进开发和部署流水线，而不是靠事后扫描兜底。
一个判断
工具其实已经成熟——SLSA、Sigstore、策略引擎、加固的 CI 配置都在。多数团队缺的不是工具，是把这些变成默认流程的机制。
本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。