为你的集群提供云原生安全

在过去几年中，一个专注于安全的小社区一直在努力加深我们对安全的理解，鉴于云原生基础设施的不断演进和相应的迭代部署实践。为了与社区分享这些知识，由Emily Fox领导的 CNCF SIG 安全（一个向 CNCF TOC 汇报并与 Kubernetes SIG 安全 友好合作的组织）成员，共同撰写了一份白皮书，概述了整体云原生安全关注点和最佳实践。经过来自全球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. Read（阅读）白皮书及其中的任何链接材料
2. Understand（理解）您环境的挑战和限制
3. Note（注意）适用于您环境的内容和控制
4. Talk（讨论）与您的同行讨论您的观察
5. Involve（参与）您的领导层并寻求帮助
6. Make（制定）基于现有和缺失安全控制的风险配置文件
7. Expend（投入）时间和金钱以及资源，以改进安全态势并酌情降低风险。

致谢

非常感谢 *Emily Fox、Tim Bannister (The Scale Factory)、Chase Pettet (Mirantis) 和 Wayne Haber (GitLab)* 为这篇博客文章提供了精彩的建议。

• ←上一篇
• 下一篇→