云原生集群安全

在过去的几年里，一个专注于安全的小型社区一直在努力加深我们对安全性的理解，考虑到不断发展的云原生基础设施和相应的迭代部署实践。为了与社区其他成员分享这些知识，CNCF SIG Security（一个向 CNCF TOC 汇报的组织，并与 Kubernetes SIG Security 是朋友）的成员在 Emily Fox 的领导下，合作撰写了一份白皮书，概述了整体云原生安全问题和最佳实践。经过来自世界各地的 35 位成员的 1200 多条评论、更改和讨论后，我们很自豪地分享 云原生安全白皮书 v1.0，该白皮书是企业、金融和医疗保健行业、学术界、政府和非营利组织的安全领导层的必读之物。

该白皮书试图不关注任何特定的云原生项目。相反，其目的是在云原生应用程序生命周期的四个逻辑阶段：开发、分发、部署和运行时中建模并注入安全性。

Kubernetes 原生安全控制

当使用 Kubernetes 作为工作负载编排器时，此版本的白皮书推荐的一些安全控制包括

• Pod 安全策略：为整个集群实现“最小权限”工作负载的单一事实来源
• 资源请求和限制：对内存和 CPU 等共享资源应用请求（软约束）和限制（硬约束）
• 审计日志分析：启用 Kubernetes API 审计和安全相关事件的过滤
• 控制平面身份验证和证书信任根：启用具有受信任 CA 的相互 TLS 身份验证，以便在集群内进行通信
• 密钥管理：与内置或外部密钥存储集成

云原生补充安全控制

Kubernetes 直接参与部署阶段，并在较小程度上参与运行时阶段。确保安全地开发和分发工件对于使 Kubernetes 中的工作负载“默认安全”至关重要。在云原生应用程序生命周期的所有阶段，存在多种用于 Kubernetes 编排的工作负载的补充安全控制，其中包括但不限于

• 开发
  • 镜像签名和验证
  • 镜像漏洞扫描器
• 分发
  • 用于检测过度权限的预部署检查
  • 启用可观察性和日志记录
• 部署
  • 使用服务网格进行工作负载身份验证和授权
  • 通过网络插件强制执行工作负载间通信的“默认拒绝”网络策略
• 运行时
  • 部署用于工作负载的安全监控代理
  • 使用 SELinux、AppArmor 等隔离在同一节点上运行的应用程序
  • 根据公认的节点、工作负载和编排器的安全基线扫描配置

先理解，后安全

云原生方式，包括容器，为其用户提供了巨大的安全优势：不变性、模块化、更快的升级和整个环境中的一致状态。意识到“做事方式”的这种根本性变化，促使我们以云原生的视角来看待安全性。对于该白皮书的所有作者来说，显而易见的一件事是，如果您不了解手头的工具、模式和框架（除了了解自己的关键资产之外），就很难就如何在云原生生态系统中保护什么以及如何保护做出更明智的决策。因此，对于所有希望成为运营、产品开发和合规部门的朋友的合作伙伴，而不是看门人的安全从业人员来说，让我们尝试学习更多，以便更好地保护。

我们建议遵循此7 步 R.U.N.T.I.M.E. 路径开始云原生安全

1. R阅读白皮书及其中的任何链接材料
2. U了解您的环境的挑战和约束
3. N记录适用于您环境的内容和控制
4. T与您的同行讨论您的观察结果
5. I让您的领导层参与并寻求帮助
6. M根据现有和缺失的安全控制创建风险概况
7. E投入时间和金钱、资源，在适当的地方改善安全态势并降低风险。

致谢

非常感谢 Emily Fox、Tim Bannister（The Scale Factory）、Chase Pettet（Mirantis）和 Wayne Haber（GitLab） 为此博客文章提供了宝贵的建议。

• ←上一篇
下一篇→