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

宣布 Kubernetes 漏洞赏金计划

作者： Maya Kaczorowski 和 Tim Allclair，Google，代表 Kubernetes 产品安全委员会

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

建立新的漏洞赏金计划

我们旨在尽可能透明地建立此漏洞赏金计划，包括 初步提案、供应商评估 以及 范围内的组件工作草案。一旦我们与选定的漏洞赏金计划供应商 HackerOne 签约，这些文档将根据 HackerOne 的反馈以及最近 Kubernetes 安全审计 中学到的内容进一步完善。漏洞赏金计划已经私下发布了几个月，受邀研究人员可以提交漏洞并帮助我们测试分类过程。在最初提案提出近两年后，该计划现在已准备好供所有安全研究人员贡献！

令人兴奋的是，这很罕见：一个针对开源基础设施工具的漏洞赏金。存在一些开源漏洞赏金计划，例如 互联网漏洞赏金，它主要涵盖在不同环境中持续部署的核心组件；但大多数漏洞赏金仍然适用于托管式网络应用程序。事实上，Kubernetes 有超过 100 个经过认证的发行版，漏洞赏金计划需要适用于为所有这些发行版提供支持的 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 安全专家来处理有效的报告。此过程中的其他内容均未更改——产品安全委员会将继续开发修复、构建私有补丁并协调特殊安全发布。带有安全补丁的新版本将在 kubernetes-security-announce@googlegroups.com 公布。

如果您想报告漏洞，则无需使用漏洞赏金——您仍然可以遵循 现有流程 并将您的发现报告给 security@kubernetes.io。

开始使用

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

如果您是安全研究员，并且是 Kubernetes 新手，请查看这些资源以了解更多信息并开始漏洞搜寻

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