本文发布已超过一年。较旧的文章可能包含过时内容。请检查页面上的信息自发布以来是否已不正确。

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

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

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

Kubernetes 社区认为，我们可以通过建立在 Kubernetes 之上的基础，帮助团队在火山上站稳脚跟。这个基础的基石是需要一个快速确认、修补和向日益壮大的 Kubernetes 用户社区发布安全更新的流程。 

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

我们借鉴了其他开源项目的经验，创建了Kubernetes 安全发布流程。与定期发布的版本不同，安全发布必须按加速计划交付，我们创建了产品安全团队来处理此流程。 

该团队快速选择一名负责人来协调工作并管理与漏洞披露者和 Kubernetes 社区的沟通。安全发布流程还记录了使用通用漏洞评分系统 (CVSS) 3.0 版计算器衡量漏洞严重性的方法。这种计算有助于在面对假期或有限的开发者带宽时，指导发布节奏的决策。通过使严重性标准透明化，我们能够更好地设定预期，并在事件发生时达到关键时间节点，我们努力做到：

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

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

作为对 Kubernetes 社区的感谢，使用代码 k8s25code 或通过这个特别的 25% 折扣链接注册今天的 CoreOS Fest 2017，可享受 25% 的特别折扣。