178 lines
12 KiB
Markdown
178 lines
12 KiB
Markdown
---
|
||
layout: blog
|
||
title: “使用更新后的 Go 版本保持 Kubernetes 安全”
|
||
date: 2023-04-06
|
||
slug: keeping-kubernetes-secure-with-updated-go-versions
|
||
---
|
||
<!--
|
||
layout: blog
|
||
title: "Keeping Kubernetes Secure with Updated Go Versions"
|
||
date: 2023-04-06
|
||
slug: keeping-kubernetes-secure-with-updated-go-versions
|
||
-->
|
||
|
||
<!--
|
||
**Author**: [Jordan Liggitt](https://github.com/liggitt) (Google)
|
||
-->
|
||
|
||
**作者**：[Jordan Liggitt](https://github.com/liggitt) (Google)
|
||
|
||
**译者**：顾欣 (ICBC)
|
||
|
||
### 问题 {#the-problem}
|
||
|
||
<!--
|
||
Since v1.19 (released in 2020), the Kubernetes project provides 12-14 months of patch releases for each minor version.
|
||
This enables users to qualify and adopt Kubernetes versions in an annual upgrade cycle and receive security fixes for a year.
|
||
-->
|
||
从 2020 年发布的 v1.19 版本以来，Kubernetes 项目为每个次要版本提供 12-14 个月的补丁维护期。
|
||
这使得用户可以按照年度升级周期来评估和选用 Kubernetes 版本，并持续一年获得安全修复。
|
||
|
||
<!--
|
||
The [Go project](https://github.com/golang/go/wiki/Go-Release-Cycle#release-maintenance) releases new minor versions twice a year,
|
||
and provides security fixes for the last two minor versions, resulting in about a year of support for each Go version.
|
||
Even though each new Kubernetes minor version is built with a supported Go version when it is first released,
|
||
that Go version falls out of support before the Kubernetes minor version does,
|
||
and the lengthened Kubernetes patch support since v1.19 only widened that gap.
|
||
-->
|
||
[Go 项目](https://github.com/golang/go/wiki/Go-Release-Cycle#release-maintenance)每年发布两个新的次要版本，
|
||
并为最近的两个版本提供安全修复，每个 Go 版本的维护期约为一年。
|
||
尽管每个新的 Kubernetes 次要版本在最初发布时都是使用受支持的 Go 版本编译构建的，
|
||
但在这一 Kubernetes 次要版本被停止支持之前，对应的 Go 版本就已经不被支持，
|
||
并且由于 Kubernetes 从 v1.19 开始延长了补丁支持期，这个差距被进一步扩大。
|
||
|
||
<!--
|
||
At the time this was written, just over half of all [Go patch releases](https://go.dev/doc/devel/release) (88/171) have contained fixes for issues with possible security implications.
|
||
Even though many of these issues were not relevant to Kubernetes, some were, so it remained important to use supported Go versions that received those fixes.
|
||
-->
|
||
在编写本文时，包含了可能对安全产生影响的问题修复的 [Go 补丁发布版本](https://go.dev/doc/devel/release)
|
||
刚刚过半（88/171）。尽管这些问题中很多都与 Kubernetes 无关，但有些确实相关，
|
||
因此使用受支持的、已包含了这类修复的 Go 版本是非常重要的。
|
||
|
||
<!--
|
||
An obvious solution would be to simply update Kubernetes release branches to new minor versions of Go.
|
||
However, Kubernetes avoids [destabilizing changes in patch releases](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/cherry-picks.md#what-kind-of-prs-are-good-for-cherry-picks),
|
||
and historically, this prevented updating existing release branches to new minor versions of Go, due to changes that were considered prohibitively complex, risky, or breaking to include in a patch release.
|
||
Examples include:
|
||
-->
|
||
显而易见的解决方案之一是直接更新 Kubernetes 的发布分支，使用 Go 的新次要版本。
|
||
然而，Kubernetes 避免在[补丁发布中引入破坏稳定性的变更](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/cherry-picks.md#what-kind-of-prs-are-good-for-cherry-picks)，
|
||
过去，因为这些变更被认为包含过高的复杂性、风险或破坏性，不适合包含在补丁发布中，
|
||
所以不能将现有发布分支更新到 Go 的新次要版本。
|
||
示例包括：
|
||
|
||
<!--
|
||
* Go 1.6: enabling http/2 by default
|
||
* Go 1.14: EINTR handling issues
|
||
* Go 1.17: dropping x509 CN support, ParseIP changes
|
||
* Go 1.18: disabling x509 SHA-1 certificate support by default
|
||
* Go 1.19: dropping current-dir LookPath behavior
|
||
-->
|
||
* Go 1.6: 默认支持 http/2
|
||
* Go 1.14: EINTR 问题处理
|
||
* Go 1.17: 取消 x509 CN 支持, ParseIP 更改
|
||
* Go 1.18: 默认禁用 x509 SHA-1 证书支持
|
||
* Go 1.19: 取消当前目录 LookPath 行为
|
||
|
||
<!--
|
||
Some of these changes could be easily mitigated in Kubernetes code,
|
||
some could only be opted out of via a user-specified `GODEBUG` envvar,
|
||
and others required invasive code changes or could not be avoided at all.
|
||
Because of this inconsistency, Kubernetes release branches have typically remained on a single Go minor version,
|
||
and risked being unable to pick up relevant Go security fixes for the last several months of each Kubernetes minor version's support lifetime.
|
||
-->
|
||
其中一些更改可以基本不会影响 Kubernetes 代码，
|
||
有些只能通过用户指定的 `GODEBUG` 环境变量来选择放弃更新，
|
||
而其他变更则需要侵入式的代码变更或完全无法避免。
|
||
由于这种不一致性，Kubernetes 的发布分支通常保持使用某个固定的 Go 次要版本，
|
||
并在每个 Kubernetes 次要版本支持生命周期的最后几个月内，面临无法得到重要的 Go 安全修复的风险。
|
||
|
||
<!--
|
||
When a relevant Go security fix was only available in newer Kubernetes minor versions,
|
||
users would have to upgrade away from older Kubernetes minor versions before their 12-14 month support period ended, just to pick up those fixes.
|
||
If a user was not prepared to do that upgrade, it could result in vulnerable Kubernetes clusters.
|
||
Even if a user could accommodate the unexpected upgrade, the uncertainty made Kubernetes' annual support less reliable for planning.
|
||
-->
|
||
当某项重要的 Go 安全修复仅出现在较新的 Kubernetes 次要版本时，
|
||
用户必须在旧的 Kubernetes 次要版本的 12-14 个月支持期结束之前完成升级，以获取这些修复。
|
||
如果用户没有准备好升级，可能导致 Kubernetes 集群的安全漏洞。
|
||
即使用户可以接受这种意外升级，这种不确定性也使得 Kubernetes 在年度支持从规划角度看变得不太可靠。
|
||
|
||
### 解决方案 {#the-solution}
|
||
|
||
<!--
|
||
We're happy to announce that the gap between supported Kubernetes versions and supported Go versions has been resolved as of January 2023.
|
||
-->
|
||
我们很高兴地宣布，自2023年1月起，受支持的 Kubernetes 版本与受支持的 Go 版本之间的差距已得到解决。
|
||
|
||
<!--
|
||
We worked closely with the Go team over the past year to address the difficulties adopting new Go versions.
|
||
This prompted a [discussion](https://github.com/golang/go/discussions/55090), [proposal](https://github.com/golang/go/issues/56986),
|
||
[talk at GopherCon](https://www.youtube.com/watch?v=v24wrd3RwGo), and a [design](https://go.dev/design/56986-godebug) for improving backward compatibility in Go,
|
||
ensuring new Go versions can maintain compatible runtime behavior with previous Go versions for a minimum of two years (four Go releases).
|
||
This allows projects like Kubernetes to update release branches to supported Go versions without exposing users to behavior changes.
|
||
-->
|
||
在过去的一年里，我们与 Go 团队密切合作，以解决采用新的 Go 版本的困难。
|
||
这些工作推动了一场[讨论](https://github.com/golang/go/discussions/55090)、
|
||
[提案](https://github.com/golang/go/issues/56986)、
|
||
[GopherCon 演讲](https://www.youtube.com/watch?v=v24wrd3RwGo)和[设计](https://go.dev/design/56986-godebug)，
|
||
以提高 Go 的向后兼容性，
|
||
确保新的 Go 版本至少在两年（四个 Go 版本）内能够与之前的 Go 版本保持兼容的运行时行为。
|
||
这使得像 Kubernetes 这样的项目能够将发布分支更新到受支持的 Go 版本，
|
||
而不是将行为上的变更暴露给用户。
|
||
|
||
<!--
|
||
The proposed improvements are on track to be [included in Go 1.21](https://tip.golang.org/doc/godebug), and the Go team already delivered targeted compatibility improvements in a Go 1.19 patch release in late 2022.
|
||
Those changes enabled Kubernetes 1.23+ to update to Go 1.19 in January of 2023, while avoiding any user-facing configuration or behavior changes.
|
||
All supported Kubernetes release branches now use supported Go versions, and can pick up new Go patch releases with available security fixes.
|
||
-->
|
||
所提议的改进正按计划[包含在 Go 1.21 中](https://tip.golang.org/doc/godebug)，
|
||
而且 Go 团队已经在 2022 年底的 Go 1.19 补丁发布中提供了针对兼容性的改进。
|
||
这些更改使 Kubernetes 1.23+ 在 2023 年 1 月升级到 Go 1.19，并避免了任何用户可见的配置或行为变化。
|
||
现在所有受支持的 Kubernetes 发布分支都使用受支持的 Go 版本，
|
||
并且可以使用包含可用的安全修复的、新的 Go 补丁发布。
|
||
|
||
<!--
|
||
Going forward, Kubernetes maintainers remain committed to making Kubernetes patch releases as safe and non-disruptive as possible,
|
||
so there are several requirements a new Go minor version must meet before existing Kubernetes release branches will update to use it:
|
||
-->
|
||
展望未来，Kubernetes 维护者仍致力于使 Kubernetes 补丁发布尽可能安全且不会造成破坏，
|
||
因此在现有的 Kubernetes 发布分支更新使用新的 Go 次要版本之前，新的 Go 次要版本必须满足几个要求：
|
||
|
||
<!--
|
||
1. The new Go version must be available for at least 3 months.
|
||
This gives time for adoption by the Go community, and for reports of issues or regressions.
|
||
2. The new Go version must be used in a new Kubernetes minor release for at least 1 month.
|
||
This ensures all Kubernetes release-blocking tests pass on the new Go version,
|
||
and gives time for feedback from the Kubernetes community on release candidates and early adoption of the new minor release.
|
||
3. There must be no regressions from the previous Go version known to impact Kubernetes.
|
||
4. Runtime behavior must be preserved by default, without requiring any action by Kubernetes users / administrators.
|
||
5. Kubernetes libraries like `k8s.io/client-go` must remain compatible with the original Go version used for each minor release,
|
||
so consumers won't *have* to update Go versions to pick up a library patch release (though they are encouraged to build with supported Go versions,
|
||
which is made even easier with the [compatibility improvements](https://go.dev/design/56986-godebug) planned in Go 1.21).
|
||
-->
|
||
1. 新的 Go 版本必须至少已经推出 3 个月。
|
||
这给了 Go 社区足够的时间进行报告并解决问题。
|
||
2. 新的 Go 版本在新的 Kubernetes 次要版本中至少已经使用了 1 个月。
|
||
这确保 Kubernetes 所有可能阻塞发布的测试都需要能在新的 Go 版本下通过，
|
||
并在早期为 Kubernetes 社区对发布候选版本和新次要版本提供反馈时间。
|
||
3. 与先前的 Go 版本相比，不能出现新的已知会影响 Kubernetes 的问题。
|
||
4. 默认情况下必须保持运行时行为，而无需 Kubernetes 用户/管理员采取任何操作。
|
||
5. Kubernetes 库，如 `k8s.io/client-go` 必须与每个次要版本最初使用的 Go 版本保持兼容，
|
||
以便在获取库补丁时，用户不必更新 Go 版本（不过还是鼓励他们使用受支持的 Go 版本构建，
|
||
因为 Go 1.21 计划中的[兼容性改进](https://go.dev/design/56986-godebug)会使得这一操作变简单）。
|
||
|
||
<!--
|
||
The goal of all of this work is to unobtrusively make Kubernetes patch releases safer and more secure,
|
||
and to make Kubernetes minor versions safe to use for the entire duration of their support lifetime.
|
||
-->
|
||
所有这些工作的目标是在不引人注意的情况下使 Kubernetes 补丁发布更加安全可靠，
|
||
并确保在整个支持周期内 Kubernetes 次要版本用起来都是安全的。
|
||
|
||
<!--
|
||
Many thanks to the Go team, especially Russ Cox, for helping drive these improvements in ways that will benefit all Go users, not just Kubernetes.
|
||
-->
|
||
非常感谢 Go 团队，尤其是 Russ Cox，他们推动了这些改进，
|
||
使所有 Go 用户受益，而不仅仅是 Kubernetes。
|
||
|