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

宣布 Kubernetes 漏洞赏金计划

作者：Maya Kaczorowski 和 Tim Allclair（谷歌），代表 Kubernetes 产品安全委员会

今天，Kubernetes 产品安全委员会正在启动一个由 CNCF 资助的 新的漏洞赏金计划，以奖励在 Kubernetes 中发现安全漏洞的研究人员。

建立新的漏洞赏金计划

我们的目标是尽可能透明地建立这个漏洞赏金计划，一份初步提案、对供应商的评估，以及范围内组件的工作草案。一旦我们启动选定的漏洞赏金计划供应商 HackerOne，这些文件根据 HackerOne 的反馈以及在最近的Kubernetes 安全审计中了解到的信息进行了进一步的完善。漏洞赏金计划已经私下发布了几个月，受邀的研究人员能够提交错误并帮助我们测试分类过程。自最初的提案以来，经过近两年的时间，该计划现在已准备好让所有安全研究人员做出贡献！

令人兴奋的是，这是罕见的：一个针对开源基础设施工具的漏洞赏金。存在一些开源漏洞赏金计划，例如 互联网漏洞赏金，它主要涵盖在各个环境中一致部署的核心组件；但大多数漏洞赏金仍然是针对托管的 Web 应用程序。事实上，拥有超过 100 个经过认证的 Kubernetes 发行版，漏洞赏金计划需要适用于为所有这些发行版提供支持的 Kubernetes 代码。到目前为止，这里最耗时的挑战一直是确保该计划提供商 (HackerOne) 及其执行第一线分类的研究人员了解 Kubernetes 并能够轻松测试报告的错误的有效性。作为引导过程的一部分，HackerOne 的团队通过了 Kubernetes 管理员认证 (CKA) 考试。

范围是什么

漏洞赏金范围涵盖 GitHub 上主要 Kubernetes 组织的代码，以及持续集成、发布和文档工件。基本上，您认为的“核心” Kubernetes 的大多数内容，包括在 https://github.com/kubernetes 上，都在范围内。我们特别关注集群攻击，例如特权提升、身份验证错误以及 kubelet 或 API 服务器中的远程代码执行。有关工作负载的任何信息泄漏或意外的权限更改也值得关注。从集群管理员的角度来看，我们还鼓励您关注 Kubernetes 供应链，包括构建和发布过程，这将允许任何未经授权的访问提交，或发布未经授权的工件的能力。

值得注意的是，社区管理工具（例如，Kubernetes 邮件列表或 Slack 频道）不在范围内。容器逃逸、对 Linux 内核或其他依赖项（例如 etcd）的攻击也不在范围内，应向相应的方报告。我们仍然希望任何 Kubernetes 漏洞（即使不在漏洞赏金范围内）能够私下披露给 Kubernetes 产品安全委员会。在 计划报告页面上查看完整范围。

Kubernetes 如何处理漏洞和披露

Kubernetes 的 产品安全委员会是一群以安全为中心的维护人员，负责接收和响应 Kubernetes 中安全问题的报告。这遵循已记录的安全漏洞响应流程，其中包括初始分类、评估影响、生成和推出修复程序。

通过我们的漏洞赏金计划，初始分类和初步评估由漏洞赏金提供商（在本例中为 HackerOne）处理，使我们能够更好地扩展我们有限的 Kubernetes 安全专家，只处理有效的报告。此过程中的其他任何内容都没有改变 - 产品安全委员会将继续开发修复程序、构建私有补丁并协调特殊的安全版本。包含安全补丁的新版本将在 [email protected] 上发布。

如果您想报告错误，则无需使用漏洞赏金 - 您仍然可以按照现有流程并通过 [email protected] 报告您发现的内容。

开始

正如许多组织通过雇用开发人员来支持开源一样，支付漏洞赏金可以直接支持安全研究人员。此漏洞赏金是 Kubernetes 建立安全研究人员社区并奖励他们辛勤工作的关键一步。

如果您是安全研究人员，并且是 Kubernetes 的新手，请查看以下资源以了解更多信息并开始查找漏洞

如果您发现任何问题，请在 Kubernetes 漏洞赏金计划的 https://hackerone.com/kubernetes 上报告安全错误。