Kubernetes CVE-2022-3172 安全漏洞

扩展 Kubernetes 的方法有很多种，目前扩展 API 方面用到最多的是自定义资源定义（CRD）和聚合 API（Aggregation API）。自定义资源定义主要是为了让 Kubernetes 集群中可以识别到新的资源，此处我主要说明下后者。

聚合 API 实际上是在 kube-apiserver 中运行的，在新 API 注册之前，它并不会工作。如果要添加新的 API，则需要创建一个APIService 对象，用来申请 Kubernetes 中新的 URL 路径。注册成功后，当有发送到此路径中的请求，则会被转发到已经注册的 APIService 上。

本次公布的 CVE-2022-3172 便与聚合 API 有关。

就像我前面介绍的那样，当新的 URL 被注册成功后，发送到该路径的请求便会被转发到已经注册的 APIService 上。安全人员发现，目前的实现中存在一个漏洞，APIService 可以将客户端的请求转发到任意的 URL 上，这就有可能会导致 Client 发送请求时，所携带的一些认证信息可能会被发送给第三方。

这也就是我们在安全领域常提到的 SSRF（Server Side Request Forgery），即：服务端请求伪造。与之对应的是 CSRF（Client Side Request Forgery）,即：客户端请求伪造。它们的区别主要在于攻击目标和过程不同，这里不展开了。

想要知道自己是否可能受到影响？可以执行如下命令进行验证：

kubectl get apiservices.apiregistration.k8s.io -o=jsonpath='{range .items[?(@.spec.service)]}{.metadata.name}{"\n"}{end}'

比如，我在我的某一个集群中执行该命令得到的结果如下：

tao@moelove:~$ kubectl get apiservices.apiregistration.k8s.io -o=jsonpath='{range .items[?(@.spec.service)]}{.metadata.name}{"\n"}{end}'
v1alpha1.cluster.karmada.io

这是由于该集群是 Karmada 的一个 host 集群，而 Karmada 的主要实现方式便是通过聚合 API 来实现的。当然，大家比较容易接触到的利用聚合 API 的另一服务可能是 metrics-server 。

影响范围

此漏洞几乎影响了当前所有的 Kubernetes 版本。具体如下：

kube-apiserver v1.25.0
kube-apiserver v1.24.0 - v1.24.4
kube-apiserver v1.23.0 - v1.23.10
kube-apiserver v1.22.0 - v1.22.13
kube-apiserver <= v1.21.14

解决办法

由于聚合 API 默认是 Kubernetes control plane 受信任的部分，之前并没有规避它的办法。所以想要彻底解决该问题的话，仅能通过升级进行解决。新版本中增加对来自 APIService 响应状态码的判断，如果是 3xx 的，则按照配置来决定是否要跟随重定向。

集群维护者可以通过设置 --aggregator-reject-forwarding-redirect=true (默认 true) 来设置拒绝跟随重定向，来避免 SSRF 。

缓解办法

由于本次问题主要是在聚合 API 上，缓解办法可以通过限制对 APIService 资源的操作来达到。也可以仅仅部署可信来源的 APIService 来避免受到影响。

检测

此外，除了验证自己是否有使用聚合 API 外，也可以通过审计日志中的 responseStatus.code 来进行判断是否有出现重定向的情况。

Helm v3.10.0-rc.1 发布

Helm 其实一直都在比较积极的进行开发和迭代，只不过 Helm 目前功能上已经非常丰富了，所以最近的一些版本中并没有特别大的变更。更多的都是一些 UX 和 bugfix 之类的。

相比于 v3.9.4 而言，此版本中一些值得聊的变更如下：

新增 helm list --no-headers 参数，可以在执行 helm list 的时候不输出表头。尽管原先我们通过 jq 或者 shell 等都可以实现；
增加了 --burst-limit 参数，用于控制 client-side throttling limit；
新增 --kube-insecure-skip-tls-verify 和 HELM_KUBEINSECURE_SKIP_TLS_VERIFY，用于控制是否要跳过 kube-apiserver 的证书校验；

更多内容可以参考其 ReleaseNote

Trivy v0.32 发布

Trivy 我之前的文章中已经介绍过多次了，这里就不再重复了。

Trivy 其实与上面提到的 Helm 类似，功能上已经相对丰富了，所以每次版本中并没有特别显著的新特性，整体趋于平稳。

此版本中值得关注的内容如下：

增加了对 Rust 二进制文件的依赖扫描；
增加了对 gradle.lockfile 和 conan.lock 文件的支持；
还有一些对 SBOM 的支持，比如增加对 SPDX 的扫描；

更多内容可以参考其 ReleaseNote

上游进展

support removal of event handlers from SharedIndexInformers by alexzielenski · Pull Request #111122 · kubernetes/kubernetes
rate limite etcd healthcheck request by aojea · Pull Request #112046 · kubernetes/kubernetes

可控制 kube-apiserver 和 etcd 健康检查之间的流量。