本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。

在火山口边缘跳舞：Kubernetes 安全流程 - 详解

作者：Brandon Philips (CoreOS), Jess Frazelle (Google) |

运行在服务器上的软件支撑着世界上不断增长的商业、通信和物理基础设施。几乎所有这些系统都连接到互联网；这意味着必须迅速应用重要的安全更新。作为软件开发人员和 IT 专业人员，我们常常发现自己身处火山边缘：我们可能因为安全漏洞在修复之前被利用而陷入岩浆般的遗忘，或者我们可能因为处理安全漏洞的流程不足而滑下山坡。

Kubernetes 社区相信，我们可以通过建立在 Kubernetes 基础上的平台，帮助团队在这个火山上恢复立足点。而这个基础的基石，需要一个快速确认、修补和向不断增长的 Kubernetes 用户社区发布安全更新的流程。

拥有超过 1200 名贡献者和超过一百万行代码，每一次 Kubernetes 发布都是一项巨大的工程，由勇敢的志愿者发布经理负责。这些常规发布是完全透明的，过程公开进行。然而，安全发布必须以不同的方式处理，以在修复方案提供给用户之前，让潜在攻击者蒙在鼓里。

我们借鉴了其他开源项目，创建了Kubernetes 安全发布流程。与定期发布不同，安全发布必须以加速的时间表交付，我们为此成立了产品安全团队来处理这一流程。

该团队迅速选出一名负责人来协调工作，并管理与漏洞披露者和 Kubernetes 社区的沟通。安全发布流程还记录了使用通用漏洞评分系统 (CVSS) 3.0 版计算器衡量漏洞严重程度的方法。这一计算有助于在节假日或开发人员带宽有限的情况下，为发布节奏决策提供信息。通过使严重性标准透明化，我们能够更好地设定预期并在事件期间达到关键时间线，我们努力实现以下目标：

  • 在 24 小时内回应报告漏洞的人员或团队，并组建负责修复的开发团队
  • 在披露后 7 天内向用户披露即将发布的修复方案
  • 在披露后 14 天内向供应商提前通知
  • 在披露后 21 天内发布修复方案

随着我们不断强化 Kubernetes，安全发布流程将有助于确保 Kubernetes 仍然是一个安全的互联网规模计算平台。如果您有兴趣了解更多关于安全发布流程的信息，请观看 KubeCon Europe 2017 YouTube 上的演示，并查阅幻灯片。如果您有兴趣了解 Kubernetes 中的身份验证和授权，以及 Kubernetes 集群安全模型，请考虑加入 Kubernetes SIG Auth。我们还希望在下一次 Kubernetes 社区活动中看到您参加安全相关的演讲和小组讨论：2017 年 5 月 31 日和 6 月 1 日在旧金山举行的 CoreOS Fest 2017。

作为对 Kubernetes 社区的感谢，使用代码 k8s25code 或通过此特殊八五折链接注册 CoreOS Fest 2017，可享受 CoreOS Fest 的特别八五折优惠。