「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。
大家好，我是张晋涛。
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
上游进展
可控制 kube-apiserver 和 etcd 健康检查之间的流量。
欢迎订阅我的文章公众号【MoeLove】
