关于kubernetes:K8S-生态周报-Istio-即将发布重大安全更新多个版本受影响

6次阅读

共计 3290 个字符，预计需要花费 9 分钟才能阅读完成。

「K8S 生态周报」内容次要蕴含我所接触到的 K8S 生态相干的每周值得举荐的一些信息。欢送订阅知乎专栏「k8s 生态」。

Istio 产品安全工作组近期发现 Istio 中存在一些安全漏洞，其中 最高级别的破绽被评级为高严重性。
鉴于以后 Istio 的破绽披露政策，所以目前咱们不会走漏具体的破绽细节。

在一周后的 2 月 22 日，将会公布 Istio v1.11.7、v1.12.3 和 v1.13.1 版本修改这些安全漏洞。届时会再更新破绽的具体内容。

请参考官网通告

此外，本周 Istio 也公布了 v1.13.0 正式版，在 v1.13.1 版本公布前，我不倡议大家将本人所用的 Istio 降级到 v1.13.0。

尽管不倡议当初降级，但咱们也能够关注下 v1.13.0 带来的一些值得关注的变更：

v1.13.0 版本中为东西向流量提供了基于主机名的多网络网关反对。主机名能够在管制面中被解析，解析记录可被用作 endpoint。
如果你不须要这个行为，或者想要复原到之前版本中的默认行为，能够为 istiod 增加 RESOLVE_HOSTNAME_GATEWAYS=false 的配置。

此外，它还反对重写 gRPC 探针，以及通过 proxyMetadata 提供了在 Envoy 工作线程间的重均衡，并且通过学习 Kubernetes 的探测
行为，改善了 istio-agent 健康检查的探测，这样它就不会再重用连贯了。请参考 #36390。

同时咱们会发现在这个版本中它对 Telemetry API 的反对减少了不少，尤其是它为 access log 反对了
Common Expression Language (CEL) filter。如果你感觉对 CEL 有些生疏，那么你能够看下我之前的文章《K8S 生态周报 | Kubernetes v1.23.0 正式公布，新个性一览》，其中就介绍到了在 Kubernetes v1.23 中对 CEL 的反对。（这样看起来 CEL 的储备很正确）

最初，就是 Istio 终于把 iptables 相干解决代码中对 22 端口硬编码的局部去掉了，能够通过 ISTIO_LOCAL_EXCLUDE_PORTS 进行配置。这段代码其实存在很久了，这是 Istio 为了兼容在虚拟机 VM 上的用例专门加的。

更多对于 Istio v1.13.0 版本的信息请参考其 ReleaseNote

Kyverno 是 Kubernetes 上原生的策略引擎，它次要的实现原理是利用 Kubernetes 提供的 Admission controller 机制。对于 Kubernetes Admission controller 机制能够参考我之前的文章：《搞懂 Kubernetes 准入管制（Admission Controller)》。

这个版本提供了很多乏味的性能，我挑几个特地值得关注的个性吧：

基于 sigstore Cosign 的镜像验证策略规定已进入到 beta 阶段。对于 Cosign 如何应用，能够参考我之前的文章云原生时代下的容器镜像平安（上）。
在这个版本中其实减少了包含 keyless, annotation 等相干的很多加强，这个个性也十分的不便；
能够在 Kyverno 策略中间接应用 OCI 容器镜像相干的元信息了，比方查看镜像的 label，挂载卷以及一些其余的配置。
比方，一种常见的应用场景是咱们心愿容器镜像不要过大，那么就能够应用如下的策略文件来限度集群内应用体积过大的容器镜像了。

如下策略文件示意仅容许应用体积小于 2Gi 的容器镜像，如果镜像过大，则间接回绝。

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: images
spec:
  validationFailureAction: enforce
  rules:
  - name: only-allow-small-images
    match:
      resources:
        kinds:
        - Pod
    preconditions:
      all:
      - key: "{{request.operation}}"
        operator: NotEquals
        value: DELETE
    validate:
      message: "images with size greater than 2Gi not allowed"  
      foreach:
      - list: "request.object.spec.containers"
        context: 
        - name: imageSize
          imageRegistry: 
            reference: "{{element.image}}"
            # Note that we need to use `to_string` here to allow kyverno to treat it like a resource quantity of type memory
            # the total size of an image as calculated by docker is the total sum of its layer sizes
            jmesPath: "to_string(sum(manifest.layers[*].size))"
        deny:
          conditions:
            all:
            - key: "2Gi"
              operator: LessThan
              value: "{{imageSize}}"

此外，这个版本中还减少了很多有用的函数，可用于进行数据处理。

更多具体内容可参考其 ReleaseNote

Trivy 是一款简略易用的破绽扫描工具，对于 Trivy 我之前曾经写过很多篇文章了，这里就不赘述了。近期它公布了 v0.23.0 版本，这个版本中有一些值得关注的内容：

Trivy DB 原先是通过应用 https://github.com/aquasecuri… 我的项目的 GitHub Release 进行下载的，然而目前如果呈现大量反复下载，会触发 GitHub 的限流策略。所以当初抉择将 Trivy DB 切换为应用 GitHub Container Registry 进行托管了。这样一方面能够躲避掉 GitHub 限流的问题，另一方面也能够能够利用 ghcr.io 提供的数据分析工具等。须要留神的是，这是一个破坏性变更。
Trivy 当初能够间接从 Azure 的 ACR 下载镜像并进行扫描了，不再须要装置 az 工具，或者事后下载镜像了；

更多具体内容可参考其 ReleaseNote

#107695 · kubernetes/kubernetes 这个 PR 实际上是对 Kubelet 治理的 Static Pod 生命周期局部的一个修改。咱们都晓得 Static Pod 的生命周期是不受 kube-apiserver 影响的，并且是由 Kubelet 治理的。然而之前几个相干的 issue 和 PR 都并没有笼罩到重启 Pod 时候须要名称完全相同。这个 PR 中对其逻辑进行了修改，减少了 Pod 的残缺名称；
#107775 · kubernetes/kubernetes 如果调度过程中，Pod 抢占失败，则在 event 中为其减少具体内容。这对于咱们去调试问题来说是十分有帮忙的；
#107317 · kubernetes/kubernetes 以后 Kubernetes 仓库中 in-tree 的 dockershim 组件的代码曾经删除，其余相干组件比方 kubelet 中的清理也根本实现了。这个 PR 中实现了 kubeadm 对于移除 in-tree dockershim 的相干反对和逻辑，次要是变更默认的容器运行时的配置，拜访地址等。对于 Kubernetes 移除 in-tree 的 dockershim 相干内容的具体内容可查看我之前的文章《K8S 弃用 Docker 了？Docker 不能用了？别逗了！》。我在本周五 (2 月 18 日) 早晨，也会做一场直播，和 SUSE Rancher 的两位小伙伴一起聊聊对于 Kubernetes 移除 dockershim 后，企业用户如何解决的话题。

最近一段时间没有继续更新，感激大家的关注。这段时间次要是两方面的起因，一方面是在进行集体的休整，另一方面也是事件较多。

不过，从这篇开始，「K8S 生态周报」将会失常的复原每周更新啦！心愿一直更！

欢送订阅我的文章公众号【MoeLove】

正文完