集群的云原生安全
作者：Pushkar Joglekar
在过去的几年中，一个关注安全的小型社区一直在努力工作，以加深我们对安全的理解，并给出了不断发展的云原生基础设施和相应的迭代部署实践。为了能够与社区的其他成员共享这一知识，由Emily Fox领导的CNCF SIG Security的成员（一个向CNCF TOC回报的小组，他们也是Kubernetes SIG Security的朋友）在白皮书中概述了整体的云原生安全问题和最佳实践。在来自世界各地35个成员的1200多个评论、修改和讨论之后，我们很自豪地与大家分享云原生安全白皮书v1.0，它是企业、金融和医疗保健行业、学术界、政府和非营利组织的安全领导必备的阅读材料。
https://www.cncf.io/blog/2020/11/18/announcing-the-cloud-native-security-white-paper
白皮书试图不关注任何特定的云原生项目。相反，其目的是将安全性建模并注入云原生应用生命周期的四个逻辑阶段：开发、分发、部署和运行时。
Kubernetes原生安全控制
当使用Kubernetes作为工作负载协调器时，这个版本的白皮书推荐的一些安全控制如下：
- Pod安全策略：为整个集群的“最少特权”工作负载实现一个真实源
- 资源请求和限制：对共享资源（如内存和CPU）应用请求（软约束）和限制（硬约束）
- 审计日志分析：启用Kubernetes API审计和筛选与安全相关的事件
- 控制平面身份验证和信任的证书根：启用相互TLS身份验证，使用可信的CA在集群内进行通信
- 秘密管理：与内置或外部秘密存储集成
云原生互补安全控制
Kubernetes直接参与部署阶段，较少参与运行时阶段。为了使Kubernetes中的工作负载“默认情况下是安全的”，必须确保安全地开发和分发工件。在云原生应用程序生命周期的所有阶段，存在一些针对Kubernetes编排的工作负载的补充性安全控制，包括但不限于：
- 开发：
- 镜像签名与验证
- 镜像漏洞扫描器
- 分发：
- 部署前检查是否存在过度特权
- 启用可观察性和日志记录
- 部署：
- 使用服务网格进行工作负载身份验证和授权
- 通过网络插件为工作负载间通信强制执行“默认拒绝”网络策略
- 运行时：
- 为工作负载部署安全监视代理
- 使用SELinux、AppArmor等隔离在同一节点上运行的应用程序。
- 根据公认的安全基线扫描节点、工作负载和协调器的配置
先了解，后安全
云原生方式（包括容器）为其用户提供了巨大的安全优势：不变性、模块化、更快的升级和跨环境的一致状态。意识到“做事方式”的这种根本性变化，促使我们从云原生的角度来看待安全问题。对于白皮书作者来说显而易见的一件事是，如果你不了解手头的工具、模式和框架，那么就如何以及哪些在云原生生态系统中进行保护就很难做出更明智的决定（除了了解自己的重要资产之外）。因此，对于那些想要成为合作伙伴而不是在操作、产品开发和合规方面为朋友看门人的安全从业者来说，让我们尝试学习更多知识以便更好地确保安全。
我们推荐遵循这7步R.U.N.T.I.M.E.路径来开始云原生安全：
- 阅读（Run ）白皮书和其中任何相关的材料
- 了解（Understand）环境中的挑战和限制
- 注意（Note）应用于环境的内容和控件
- 和你的同伴谈论（Talk）你的观察
- 让你的领导参与（Involve）进来，寻求帮助
- 基于现有的和缺失的安全控制，制作（Make）一个风险概要
- 在适当的地方，花费（Expend）时间、金钱和资源来改善安全状况并降低风险。
鸣谢
感谢Emily Fox、Tim Bannister（The Scale Factory）、Chase Pettet（Mirantis）和Wayne Haber（GitLab）为这篇博客提供的精彩建议。