Merge pull request #33909 from Sea-n/zh-security

[zh] Sync issues-security
pull/33921/head
Kubernetes Prow Robot 2022-05-24 08:26:06 -07:00 committed by GitHub
commit d380c85197
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 24 additions and 21 deletions

View File

@ -1,6 +1,7 @@
---
title: Kubernetes 问题追踪
weight: 10
aliases: [/zh/cve/, /zh/cves/]
---
<!--
@ -29,6 +30,6 @@ Work on Kubernetes code and public issues are tracked using [GitHub Issues](http
<!--
Security-related announcements are sent to the [kubernetes-security-announce@googlegroups.com](https://groups.google.com/forum/#!forum/kubernetes-security-announce) mailing list.
-->
与安全性相关的公告发送到
与安全性相关的公告发送到
[kubernetes-security-announce@googlegroups.com](https://groups.google.com/forum/#!forum/kubernetes-security-announce)
邮件列表。

View File

@ -1,5 +1,6 @@
---
title: Kubernetes 安全和信息披露
aliases: [/zh/security/]
content_type: concept
weight: 20
---
@ -27,7 +28,7 @@ This page describes Kubernetes security and disclosure information.
<!--
## Security Announcements
-->
## 安全公告
## 安全公告 {#security-announcements}
<!--
Join the [kubernetes-security-announce](https://groups.google.com/forum/#!forum/kubernetes-security-announce) group for emails about security and major API announcements.
@ -37,28 +38,28 @@ Join the [kubernetes-security-announce](https://groups.google.com/forum/#!forum/
<!--
## Report a Vulnerability
-->
## 报告一个漏洞
## 报告一个漏洞 {#report-a-vulnerability}
<!--
Were extremely grateful for security researchers and users that report vulnerabilities to the Kubernetes Open Source Community. All reports are thoroughly investigated by a set of community volunteers.
We're extremely grateful for security researchers and users that report vulnerabilities to the Kubernetes Open Source Community. All reports are thoroughly investigated by a set of community volunteers.
-->
我们非常感谢向 Kubernetes 开源社区报告漏洞的安全研究人员和用户。
所有的报告都由社区志愿者进行彻底调查。
<!--
To make a report, please email the private [security@kubernetes.io](mailto:security@kubernetes.io) list with the security details and the details expected for [all Kubernetes bug reports](https://git.k8s.io/kubernetes/.github/ISSUE_TEMPLATE/bug-report.md).
To make a report, submit your vulnerability to the [Kubernetes bug bounty program](https://hackerone.com/kubernetes). This allows triage and handling of the vulnerability with standardized response times.
-->
如需报告,请连同安全细节以及预期的[所有 Kubernetes bug 报告](https://git.k8s.io/kubernetes/.github/ISSUE_TEMPLATE/bug-report.md)
详细信息电子邮件到[security@kubernetes.io](mailto:security@kubernetes.io)列表
如需报告,请将你的漏洞提交给 [Kubernetes 漏洞赏金计划](https://hackerone.com/kubernetes)。
这样做可以使得社区能够在标准化的响应时间内对漏洞进行分类和处理
<!--
You can also email the private [security@kubernetes.io](mailto:security@kubernetes.io) list with the security details and the details expected for [all Kubernetes bug reports](https://github.com/kubernetes/kubernetes/blob/master/.github/ISSUE_TEMPLATE/bug-report.yaml).
-->
你还可以通过电子邮件向私有 [security@kubernetes.io](mailto:security@kubernetes.io)
列表发送电子邮件,邮件中应该包含
[所有 Kubernetes 错误报告](https://github.com/kubernetes/kubernetes/blob/master/.github/ISSUE_TEMPLATE/bug-report.yaml)
所需的详细信息。
<!--
You may encrypt your email to this list using the GPG keys of the [Security Response Committee members](https://git.k8s.io/security/README.md#product-security-committee-psc). Encryption using GPG is NOT required to make a disclosure.
-->
@ -68,45 +69,45 @@ GPG 密钥加密你的发往邮件列表的邮件。揭示问题时不需要使
<!--
### When Should I Report a Vulnerability?
-->
### 我应该在什么时候报告漏洞?
### 我应该在什么时候报告漏洞? {#when-should-i-report-a-vulnerability}
<!--
- You think you discovered a potential security vulnerability in Kubernetes
- You are unsure how a vulnerability affects Kubernetes
- You think you discovered a vulnerability in another project that Kubernetes depends on
- For projects with their own vulnerability reporting and disclosure process, please report it directly there
- For projects with their own vulnerability reporting and disclosure process, please report it directly there
-->
- 你认为在 Kubernetes 中发现了一个潜在的安全漏洞
- 你不确定漏洞如何影响 Kubernetes
- 你认为你在 Kubernetes 依赖的另一个项目中发现了一个漏洞
- 对于具有漏洞报告和披露流程的项目,请直接在该项目处报告
- 对于具有漏洞报告和披露流程的项目,请直接在该项目处报告
<!--
### When Should I NOT Report a Vulnerability?
-->
### 我什么时候不应该报告漏洞?
### 我什么时候不应该报告漏洞? {#when-should-i-not-report-a-vulnerability}
<!--
- You need help tuning Kubernetes components for security
- You need help applying security related updates
- Your issue is not security related
-->
- 你需要帮助调整 Kubernetes 组件安全性
- 你需要帮助应用与安全相关更新
- 你需要调整 Kubernetes 组件安全性的帮助
- 你需要应用与安全相关更新的帮助
- 你的问题与安全无关
<!--
## Security Vulnerability Response
-->
## 安全漏洞响应
## 安全漏洞响应 {#security-vulnerability-response}
<!--
Each report is acknowledged and analyzed by Security Response Committee members within 3 working days. This will set off the [Security Release Process](https://git.k8s.io/security/security-release-process.md#disclosures).
-->
每个报告在 3 个工作日内由安全响应委员会成员确认和分析这将启动[安全发布过程](https://git.k8s.io/sig-release/security-release-process-documentation/security-release-process.md#disclosures)。
每个报告在 3 个工作日内由安全响应委员会成员确认和分析这将启动[安全发布过程](https://git.k8s.io/sig-release/security-release-process-documentation/security-release-process.md#disclosures)。
<!--
Any vulnerability information shared with Product Security Team stays within Kubernetes project and will not be disseminated to other projects unless it is necessary to get the issue fixed.
Any vulnerability information shared with Security Response Committee stays within Kubernetes project and will not be disseminated to other projects unless it is necessary to get the issue fixed.
-->
与安全响应委员会共享的任何漏洞信息都保留在 Kubernetes 项目中,除非有必要修复该问题,否则不会传播到其他项目。
@ -118,7 +119,7 @@ As the security issue moves from triage, to identified fix, to release planning
<!--
## Public Disclosure Timing
-->
## 公开披露时间
## 公开披露时间 {#public-disclosure-timing}
<!--
A public disclosure date is negotiated by the Kubernetes Security Response Committee and the bug submitter. We prefer to fully disclose the bug as soon as possible once a user mitigation is available.
@ -132,7 +133,8 @@ It is reasonable to delay disclosure when the bug or the fix is not yet fully un
当 bug 或其修复还没有被完全理解,解决方案没有经过良好的测试,或者为了处理供应商协调问题时,延迟披露是合理的。
<!--
The timeframe for disclosure is from immediate (especially if it's already publicly known) to a few weeks. As a basic default, we expect report date to disclosure date to be on the order of 7 days. The Kubernetes product security team holds the final say when setting a disclosure date.
The timeframe for disclosure is from immediate (especially if it's already publicly known) to a few weeks. For a vulnerability with a straightforward mitigation, we expect report date to disclosure date to be on the order of 7 days. The Kubernetes Security Response Committee holds the final say when setting a disclosure date.
-->
信息披露的时间范围从即时(尤其是已经公开的)到几周。作为一个基本的约定,我们希望报告日期到披露日期的间隔是 7 天。在设置披露日期时Kubernetes 产品安全团队拥有最终决定权。
信息披露的时间范围从即时(尤其是已经公开的)到几周不等。
对于具有直接缓解措施的漏洞,我们希望报告日期到披露日期的间隔是 7 天。
在设置披露日期方面Kubernetes 安全响应委员会拥有最终决定权。