K8S 生态周报| Kubernetes 公布两个全版本受影响的漏洞

Jintao Zhang

发布于 2023-09-03 13:43:02

3540

发布于 2023-09-03 13:43:02

文章被收录于专栏：MoeLoveMoeLove

“「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」[1]。 ”

大家好，我是张晋涛。

KIND v0.20.0 正式发布

KIND 是我一直参与，也日常一直在使用的项目，用于快速的在本地或者 CI 环境中启动 Kubernetes 集群。

上周新发布的 v0.20.0 版本有很多值得关注的内容：

Breaking Changes

当前 KIND 支持的最低版本的 Docker 更新到了 v20.10+ ，无论是服务器/CI 或者使用 Docker Desktop 的用户都可以比较容易的满足这个版本要求。

另外，如果是想要使用 KIND v0.20.0+ 版本构建 Node image 的话，要求主机是 cgroups v1 的环境，这一点非常重要。比如我现在就无法在我本地用最新版来构建 Node image 了，我本地很早之前就已经设置成了默认 cgroups v2。

此外，默认的 Kubernetes 版本也更新到了 v1.27.3 。

最后，由于构建的 Node image 中 container runtime 使用的是 containerd，但是 containerd 弃用了其旧的 CRI mirrors 的配置方式，所以如果使用了 KIND 本地镜像仓库的用户 https://kind.sigs.k8s.io/docs/user/local-registry/ 请更新下自己使用的脚本。其中有一个 config_path 配置的更新。之后 KIND 应该也会逐步升级到使用 containerd v2.0 。

新特性和其他

kind build node-image 命令中对 Kubernetes 代码仓库位置的检索逻辑做了一些修改，按如下顺序：(pwd), {GOPATH}/src/k8s.io/kubernetes,
runc 升级到 1.1.7, containerd 升级到 1.7.1；

此外，给 kubelet 的 systemd service 默认设置了一个 KillMode=process 选项。这个事情我觉得比较值得聊一下：

KillMode 在 systemd service 配置文件中用于指定服务停止时进程终止的方式。以下是可用的选项：

control-group（默认值）：当服务停止时，systemd 将向整个控制组（cgroup）发送 SIGTERM 信号，包括主进程及其所有子进程。如果在指定的超时时间内进程仍未终止，将发送 SIGKILL 信号以强制终止它们；
process：当服务停止时，systemd 仅向主进程发送 SIGTERM 信号。子进程不会受到影响，将继续运行。这也就是这次修改的主要内容，这样的话，主进程收到信号后可以做一些清理操作，进行优雅关闭；
mixed：当服务停止时，systemd 向主进程发送 SIGTERM 信号，如果在指定的超时时间内主进程仍未终止，将发送 SIGKILL 信号以强制终止它，即使它没有优雅关闭;
none：当服务停止时，systemd 不会发送任何信号。这意味着服务进程不会被强制终止，除非它们自己检测到服务停止并执行相应的操作。这种设置可能在某些特殊情况下有用，但通常不建议使用;

对于实际的部署时，建议在 Kubelet systemd service 中加上此配置项。

#上游进展

Kubernetes 公布了两个新漏洞 CVE-2023-2727 和 CVE-2023-2728

我在这里就直接把这两个一起来谈了。

简单来说都是绕过了 Admission plugin 的策略限制。如果对于 Kubernetes Adminssion 机制不太了解的小伙伴，可以看看我之前写的这篇理清 Kubernetes 中的准入控制（Admission Controller) | MoeLove

具体而言，这两个漏洞触发的条件都包含了 Pod 使用 ephemeral containers(临时容器)的情况。如果通过审计日志未发现集群中使用此功能，则并未受到这两个漏洞的影响。

其中 CVE-2023-2727 也可以通过 Allowed Repositories | Gatekeeper Library 或者 Allowed Image Repositories | Kyverno 来进行防护。

这两个漏洞影响了之前的所有版本，并在如下版本进行了修复：

kube-apiserver v1.27.3
kube-apiserver v1.26.6
kube-apiserver v1.25.11
kube-apiserver v1.24.15

可以考虑进行升级。

如果 cgroups aware OOM killer 可用时将会启用

use the cgroup aware OOM killer if available by tzneal · Pull Request #117793 · kubernetes/kubernetes

Kubernetes 在 v1.25 中对 cgroups v2 的支持达到了 GA ，可参考我之前的文章 K8S 生态周报| Kubernetes v1.25.0 正式发布，新特性一览 | MoeLove

但是在 Linux 4.19 内核中对于 cgroups v2 还添加了一个 cgroup-aware OOM killer 的支持。这个功能允许 OOM killer 杀死整个 cgroup，而不仅仅是杀死内存使用最多的进程。这可以帮助防止内存碎片化，并确保系统保持稳定。关于 Linux 内核如何处理 OOM ，可以参考我之前的一篇文章 Docker 容器资源管理 - 知乎，简单来说就是在 torvalds/linux/mm/oom_kill.c 中有个 select_bad_process() 选择所谓的 bad 进程来杀掉。

回过头来看看 cgroup-aware OOM killer 首先计算 cgroups 中所有进程的总内存使用量，如果总内存使用量超过了cgroups 的内存限制，则 OOM killer 将会杀死该 cgroup。

cgroup-aware OOM killer 还考虑了每个进程在 cgroup 中的 oom_score。oom_score 是一个指示进程被 OOM killer 杀死可能性有多大的值。具有更高 oom_score 值的进程比具有较低 oom_score 值的进程更容易被杀死。

通过将 cgroup_enable_memory_accounting 内核参数设置为 1 即可启用 cgroup-aware OOM Killer 。大多数Linux发行版默认情况下启用此参数。

前面提到了它的好处有防止内存碎片化和确保系统保持稳定，但它也有一些可能的劣势，那就是如果整个 cgroup 被杀掉了，某些情况下可能导致数据丢失，另外，也可能导致不太好进行排查。

但整体来看，社区认为利大于弊，所以也就合并了这个 PR 。

感谢大家，我们下期再见！

TheMoeLove