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

在火山的边缘跳舞：Kubernetes 安全过程 - 解释

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

在服务器上运行的软件支撑着世界上越来越多的商业、通信和物理基础设施。而且几乎所有这些系统都连接到互联网；这意味着必须快速应用重要的安全更新。作为软件开发人员和 IT 专业人员，我们常常发现自己在火山边缘跳舞：我们可能会因为在修复之前被利用的安全漏洞而陷入岩浆导致的遗忘，或者可能会因为处理安全漏洞的过程不充分而从山腰滑落。

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

拥有超过 1,200 名贡献者和超过一百万行代码，Kubernetes 的每次发布都是一项庞大的任务，由勇敢的志愿者发布经理负责。这些常规发布是完全透明的，并且该过程是公开进行的。但是，安全发布必须以不同的方式处理，以使潜在的攻击者在向用户提供修复程序之前一直处于黑暗中。

为了创建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，可享受 CoreOS Fest 特别的 25% 折扣。