本文发布已超过一年。较旧的文章可能包含过时内容。请检查页面中的信息自发布以来是否已不再正确。
云原生安全保护您的集群
在过去的几年里,一个专注于安全的、规模不大的社区一直在努力工作,以加深我们对安全的理解,考虑到不断发展的云原生基础设施和相应的迭代部署实践。为了将这些知识与社区其他人分享,CNCF SIG Security (一个向 CNCF TOC 报告并与 Kubernetes SIG Security 友好合作的小组)成员,由 Emily Fox 领导,合作撰写了一份白皮书,概述了整体的云原生安全考量和最佳实践。经过来自全球 35 位成员的 1200 多条评论、修改和讨论,我们自豪地发布了 云原生安全白皮书 v1.0,这对于企业、金融和医疗保健行业、学术界、政府和非营利组织的安全领导者来说是必读的。
本文试图不专注于任何特定的云原生项目。相反,其意图是将安全性建模并注入到云原生应用生命周期的四个逻辑阶段:开发、分发、部署和运行时。
Kubernetes 原生安全控制
当使用 Kubernetes 作为工作负载编排器时,本版白皮书推荐的一些安全控制包括:
- Pod 安全策略 (Pod Security Policies):为整个集群的“最小权限”工作负载实现单一真相来源
- 资源请求和限制 (Resource requests and limits):对内存和 CPU 等共享资源应用请求(软约束)和限制(硬约束)
- 审计日志分析 (Audit log analysis):启用 Kubernetes API 审计和过滤与安全相关的事件
- 控制平面认证和信任根证书 (Control plane authentication and certificate root of trust):启用与受信任 CA 的相互 TLS 认证,用于集群内部通信
- Secret 管理 (Secrets management):与内置或外部 Secret 存储集成
云原生补充安全控制
Kubernetes 直接参与 部署 阶段,并在较小程度上参与 运行时 阶段。确保制品得到安全的 开发 和 分发 对于使 Kubernetes 中的工作负载默认“安全”地运行是必要的。在云原生应用生命周期的所有阶段,针对 Kubernetes 编排的工作负载存在一些补充安全控制,包括但不限于:
- 开发
- 镜像签名和验证
- 镜像漏洞扫描器
- 分发
- 部署前检查以检测过度权限
- 启用可观测性和日志记录
- 部署
- 使用服务网格进行工作负载认证和授权
- 通过网络插件强制执行工作负载间通信的“默认拒绝”网络策略
- 运行时
- 为工作负载部署安全监控代理
- 使用 SELinux、AppArmor 等隔离在同一节点上运行的应用
- 根据已识别的安全基线扫描节点、工作负载和编排器的配置
先理解,后安全
包括容器在内的云原生方式为其用户带来了巨大的安全优势:不变性、模块化、更快的升级和跨环境的一致状态。认识到这种“做事方式”的根本性改变,促使我们以云原生的视角审视安全性。对所有作者来说,显而易见的一点是,如果你不理解手头的工具、模式和框架(除了了解你自己的关键资产),那么在云原生生态系统中就很难做出更明智的关于如何以及保护什么的安全决策。因此,对于所有希望成为运营、产品开发和合规部门朋友的伙伴而不是守门人的安全从业者,让我们努力去学习更多,以便更好地保障安全。
我们建议遵循这 7 步 R.U.N.T.I.M.E. 路径 来开始云原生安全工作
- Read:阅读白皮书及其中的任何链接材料
- Understand:理解你环境中的挑战和约束
- Note:记录适用于你环境的内容和控制措施
- Talk:与你的同行讨论你的观察结果
- Involve:让你的领导参与并寻求帮助
- Make:基于现有和缺失的安全控制制定风险画像
- Expend:投入时间和资源,在适当的情况下改进安全态势并降低风险。
致谢
特别感谢 Emily Fox, Tim Bannister (The Scale Factory), Chase Pettet (Mirantis), and Wayne Haber (GitLab) 为此博客文章贡献了他们的精彩建议。