Kubernetes安全加固最佳实践更新了吗

wen 网络安全 2026-07-12 2

本文目录导读：

核心新增与强化领域（2024-2025年重点）
近期CVE驱动的关键修补项
混合云与边缘场景的特殊考量
需要立即审查的配置项清单
总结与行动建议

截至2025年5月,Kubernetes安全加固的最佳实践持续在更新，但核心原则保持稳定，最新的变化主要围绕软件供应链安全、运行时安全、CVE（常见漏洞与暴露）响应（如Ingress NGINX高危漏洞）以及对新功能（如Pod Security Standards、Sidecar容器）的适配。

以下是当前最新的关键最佳实践更新,并结合了近期社区关注的重点：

核心新增与强化领域（2024-2025年重点）

供应链安全（SBOM与准入控制）
- 背景：针对软件供应链攻击（如通过恶意镜像或受损的CI/CD工具）的威胁增加。
- 新实践：
  - 强制使用SBOM（软件物料清单）：要求所有部署的镜像必须附带SBOM，并在准入控制器（如Kyverno、OPA/Gatekeeper）中校验其签名和完整性。
  - 镜像签名与验证：使用cosign或notary对镜像进行签名，并在集群内强制验证（通过kubectl verify或准入Webhook），阻止未签名镜像运行。
  - 信任策略（Trust Policy）：配置明确的信任策略，只允许来自已知可信仓库和镜像的部署。
运行时安全（eBPF与Cilium的强化）
- 背景：传统网络策略无法阻止主机或内核漏洞的横向移动。
- 新实践：
  - 使用eBPF驱动的安全策略：采用Cilium或Tetragon等工具，不仅限制网络出入，还能通过观察系统调用、文件访问和进程活动来执行运行时安全策略（阻止容器执行mount或insmod）。
  - Seccomp与AppArmor的默认启用：不再依赖手动配置，推荐使用RuntimeClass（RuntimeDefault）或准入控制器自动为所有Pod应用瘦身的Seccomp Profile，防止非必要的系统调用，Kubernetes 1.30+已默认启用Seccomp的RuntimeDefault模式。
API Server与etcd的访问控制更新
- 背景：针对API Server的DDoS（分布式拒绝服务）攻击和通过Node访问etcd的漏洞修复。
- 新实践：
  - API Server速率限制与审计日志分析：配置严格的API Server的--max-requests-inflight和--max-mutating-requests-inflight，启用审计日志（Audit Log）的细粒度记录（特别是对Secrets和TokenReviews的访问），并集成SIEM系统进行分析。
  - etcd加密与网络隔离：强制开启etcd静态加密（Encryption at Rest），并确保etcd仅监听在API Server的节点上（使用TLS证书和--peer-cert-file），避免通过Node网络直接访问。
Pod安全标准（PSS）与Pod Security Admission（PSA）的成熟
- 背景：PodSecurityPolicy（PSP）已彻底废弃，PSA成为新标准。
- 新实践：
  - 逐步迁移至PSA：从Privileged -> Baseline -> Restricted 三层模型。推荐生产环境Namespace默认使用Restricted级别，仅对需要特权的组件（如Ingress Controller、CNI插件）开放Baseline或Privileged。
  - 结合VAP（Validating Admission Policy）：利用Kubernetes 1.30+的Validating Admission Policy（一种声明式、无服务器端的准入控制方式）来补充PSA，执行更复杂的自定义策略（如禁止特定镜像标签、强制设置资源限制）。

近期CVE驱动的关键修补项

务必检查你的集群是否已针对以下最新高危漏洞进行修补：

Ingress NGINX 远程代码执行（RCE）漏洞（CVE-2025-1974等）：这是2025年最严重的K8s安全事件之一。立即：
- 升级Ingress NGINX至最新补丁版本（>= 1.12.0 或 1.11.4）。
- 禁用 allow-edit-annotations 等危险功能，并严格限制通过Annotaions注入配置的能力。
Kubernetes API Server 不当权限提升（CVE-2025-0083）：影响某些服务账户令牌的访问控制。
- 操作：升级到Kubernetes v1.30.8, v1.31.4, v1.32.0 或更高版本。
kubelet 资源耗尽攻击（CVE-2025-0137）：可能导致节点崩溃。
- 操作：升级kubelet至安全版本，并限制节点上可创建的Pod数量（--max-pods）。

混合云与边缘场景的特殊考量

节点身份安全：在公有云（EKS、AKS、GKE）中，使用Workload Identity或IRSA代替长期AK/SK（访问密钥/秘密密钥），确保ServiceAccount与云IAM角色绑定，且令牌定期轮换。
边缘集群：对于K3s、MicroK8s等边缘部署，必须启用TLS、设置强密码的--token，并暴露API Server时使用Nginx反向代理或防火墙限制访问来源IP。

需要立即审查的配置项清单

RBAC：审计所有ClusterRole和Role，移除不必要的（通配符）权限，特别关注secrets、pods/exec、nodes/proxy、persistentvolumes的访问。使用 kubectl whoami 和 kubectl auth can-i 验证实际权限。
网络策略：默认拒绝所有入站流量，并明确允许必需的Pod到Pod、Pod到Service的通信。特别禁止同一命名空间内非必要组件的互相访问。
Secrets：永不在ConfigMap或环境变量中存储明文Secret，使用外部密钥管理器（如HashiCorp Vault、AWS Secrets Manager、External Secrets Operator）并启用自动轮换。
节点安全：禁用SSH密码登录，使用SSH密钥并限制来源IP，定期运行kube-bench或trivy检查节点OS和Kubernetes组件的合规性。

总结与行动建议

最佳实践是持续更新的，但你可以通过以下方式保持同步：

关注官方资源：
- Kubernetes安全文档：https://kubernetes.io/docs/concepts/security/
- CIS Kubernetes Benchmark：最新版本（目前是v1.8+，对应K8s 1.30+）。
- NIST SP 800-190：容器安全指南。
自动化工具引用（集成到CI/CD）：
- kube-bench：检查CIS基准。
- trivy：扫描镜像、IaC（基础设施即代码）和集群。
- Kyverno / OPA Gatekeeper：执行准入策略。
- popeye：检查集群运行时配置健康度。
直接建议：
- 立即升级：确保你的Kubernetes集群版本至少是v1.30.x或v1.31.x（以避免已知CVE）。
- 严格限制Ingress控制器：特别是NGINX，这是攻击面最大的组件。
- 启用所有基础硬防护：PSA（Restricted模式）+ 网络策略（默认拒绝）+ etcd加密 + 审计日志。

最佳实践已经更新，核心是“零信任”（不信任任何网络、任何镜像、任何用户）和“自动化的合规检查”。 建议你立即按照上述清单，重点检查Ingress控制器、RBAC和Pod安全标准这三个最容易出问题的环节。