1 - Kubernetes 问题追踪
要报告安全问题，请遵循 Kubernetes 安全问题公开流程。
使用 GitHub Issues 跟踪 Kubernetes 编码工作和公开问题。
与安全性相关的公告将发送到 kubernetes-security-announce@googlegroups.com 邮件列表。
2 - Kubernetes 安全和信息披露
本页面介绍 Kubernetes 安全和信息披露相关的内容。
安全公告
加入 kubernetes-security-announce 组，以获取关于安全性和主要 API 公告的电子邮件。
报告一个漏洞
我们非常感谢向 Kubernetes 开源社区报告漏洞的安全研究人员和用户。 所有的报告都由社区志愿者进行彻底调查。
如需报告，请将你的漏洞提交给 Kubernetes 漏洞赏金计划。 这样做可以使得社区能够在标准化的响应时间内对漏洞进行分类和处理。
你还可以通过电子邮件向私有 security@kubernetes.io 列表发送电子邮件，邮件中应该包含 所有 Kubernetes 错误报告 所需的详细信息。
你可以使用安全响应委员会成员的 GPG 密钥加密你的发往邮件列表的邮件。揭示问题时不需要使用 GPG 来加密。
我应该在什么时候报告漏洞？
- 你认为在 Kubernetes 中发现了一个潜在的安全漏洞
- 你不确定漏洞如何影响 Kubernetes
- 你认为你在 Kubernetes 依赖的另一个项目中发现了一个漏洞
- 对于具有漏洞报告和披露流程的项目，请直接在该项目处报告
我什么时候不应该报告漏洞？
- 你需要调整 Kubernetes 组件安全性的帮助
- 你需要应用与安全相关更新的帮助
- 你的问题与安全无关
安全漏洞响应
每个报告在 3 个工作日内由安全响应委员会成员确认和分析，这将启动安全发布过程。
与安全响应委员会共享的任何漏洞信息都保留在 Kubernetes 项目中，除非有必要修复该问题，否则不会传播到其他项目。
随着安全问题从分类、识别修复、发布计划等方面的进展，我们将不断更新报告。
公开披露时间
公开披露日期由 Kubernetes 安全响应委员会和 bug 提交者协商。 我们倾向于在能够为用户提供缓解措施之后尽快完全披露该 bug。
当 bug 或其修复还没有被完全理解，解决方案没有经过良好的测试，或者为了处理供应商协调问题时，延迟披露是合理的。
信息披露的时间范围从即时（尤其是已经公开的）到几周不等。 对于具有直接缓解措施的漏洞，我们希望报告日期到披露日期的间隔是 7 天。 在设置披露日期方面，Kubernetes 安全响应委员会拥有最终决定权。
3 - 官方 CVE 订阅源
Kubernetes v1.25 [alpha]
这是由 Kubernetes 安全响应委员会（Security Response Committee, SRC）公布的经社区维护的官方 CVE 列表。 更多细节请参阅 Kubernetes 安全和信息披露。
Kubernetes 项目就已发布的安全问题发布了一个可使用程序访问的 JSON Feed。 你可以通过执行以下命令来查阅这些安全问题：
curl -Lv https://k8s.io/docs/reference/issues-security/official-cve-feed/index.json
| CVE ID | 问题描述 | CVE GitHub Issue URL |
|---|---|---|
| CVE-2022-3172 | Aggregated API server can cause clients to be redirected (SSRF) | #112513 |
| CVE-2021-25749 | `runAsNonRoot` logic bypass for Windows containers | #112192 |
| CVE-2021-25741 | Symlink Exchange Can Allow Host Filesystem Access | #104980 |
| CVE-2021-25737 | Holes in EndpointSlice Validation Enable Host Network Hijack | #102106 |
| CVE-2021-25735 | Validating Admission Webhook does not observe some previous fields | #100096 |
| CVE-2020-8554 | Man in the middle using LoadBalancer or ExternalIPs | #97076 |
| CVE-2020-8566 | Ceph RBD adminSecrets exposed in logs when loglevel >= 4 | #95624 |
| CVE-2020-8565 | Incomplete fix for CVE-2019-11250 allows for token leak in logs when logLevel >= 9 | #95623 |
| CVE-2020-8564 | Docker config secrets leaked when file is malformed and log level >= 4 | #95622 |
| CVE-2020-8563 | Secret leaks in kube-controller-manager when using vSphere provider | #95621 |
| CVE-2020-8557 | Node disk DOS by writing to container /etc/hosts | #93032 |
| CVE-2020-8559 | Privilege escalation from compromised node to cluster | #92914 |
| CVE-2020-8558 | Node setting allows for neighboring hosts to bypass localhost boundary | #92315 |
| CVE-2020-8555 | Half-Blind SSRF in kube-controller-manager | #91542 |
| CVE-2020-10749 | IPv4 only clusters susceptible to MitM attacks via IPv6 rogue router advertisements | #91507 |
| CVE-2019-11254 | kube-apiserver Denial of Service vulnerability from malicious YAML payloads | #89535 |
| CVE-2020-8552 | apiserver DoS (oom) | #89378 |
| CVE-2020-8551 | Kubelet DoS via API | #89377 |
| CVE-2018-1002102 | Unvalidated redirect | #85867 |
| CVE-2019-11248 | /debug/pprof exposed on kubelet's healthz port | #81023 |
| CVE-2019-11249 | Incomplete fixes for CVE-2019-1002101 and CVE-2019-11246, kubectl cp potential directory traversal | #80984 |
| CVE-2019-11247 | API server allows access to custom resources via wrong scope | #80983 |
| CVE-2019-11243 | rest.AnonymousClientConfig() does not remove the serviceaccount credentials from config created by rest.InClusterConfig() | #76797 |
| CVE-2019-1002100 | json-patch requests can exhaust apiserver resources | #74534 |
| CVE-2018-1002105 | proxy request handling in kube-apiserver can leave vulnerable TCP connections | #71411 |
| CVE-2017-1002102 | atomic writer volume handling allows arbitrary file deletion in host filesystem | #60814 |
| CVE-2017-1002101 | subpath volume mount handling allows arbitrary file access in host filesystem | #60813 |
| CVE-2017-1000056 | PodSecurityPolicy admission plugin authorizes incorrectly | #43459 |
此订阅源会自动刷新，但从宣布 CVE 到可在此订阅源中找到对应的 CVE 会有一个明显却很小的延迟（几分钟到几小时）。
此订阅源的真实来源是一组 GitHub Issue，通过受控和受限的标签 official-cve-feed 进行过滤。
原始数据存放在 Google Cloud Bucket 中，只有社区少数受信任的成员可以写入。