K8S Eco Weekly | Istio is about to release a major security update, multiple versions are affected

The content of "K8S Ecological Weekly" mainly includes some recommended weekly information related to the K8S ecology that I have come into contact with. Welcome to subscribe to know the column "k8s ecology" .

Istio is about to release a major security update, multiple versions are affected

The Istio Product Security Working Group recently discovered a number of security vulnerabilities in Istio, with the highest rated vulnerability rated as high severity.
Given the current Istio vulnerability disclosure policy, we will not disclose specific vulnerability details at this time.

A week later, on February 22, Istio v1.11.7, v1.12.3 and v1.13.1 will be released to fix these security holes. The details of the vulnerability will be updated in due course.

Please refer to official announcement

In addition, this week Istio also released the official version v1.13.0, Before the v1.13.1 version is released, I do not recommend that you upgrade your Istio to v1.13.0 .

Although it is not recommended to upgrade now, we can also pay attention to some noteworthy changes brought by v1.13.0:

The v1.13.0 release provides hostname-based multi-network gateway support for east-west traffic. Hostnames can be resolved in the control plane, and resolution records can be used as endpoints.
If you don't need this behavior, or want to revert to the default behavior in previous versions, you can add RESOLVE_HOSTNAME_GATEWAYS=false to istiod.

In addition, it supports rewriting gRPC probes, and provides rebalancing between Envoy workers via proxyMetadata , and probing by learning Kubernetes
behavior, improved detection of istio-agent health checks so that it doesn't reuse connections anymore. Please refer to #36390 .

At the same time, we will find that its support for Telemetry API has increased a lot in this version, especially it supports access log
Common Expression Language (CEL) filter. If you feel a little unfamiliar with CEL, then you can read my previous article "K8S Ecological Weekly | Kubernetes v1.23.0 Officially Released, List of New Features" , which introduces the support for CEL in Kubernetes v1.23 . (so it looks like CEL's reserves are correct)

Finally, Istio finally removed the hard-coded part of port 22 in the iptables-related processing code, which can be configured through ISTIO_LOCAL_EXCLUDE_PORTS . This code has actually existed for a long time, which is specially added by Istio to be compatible with the use case on the virtual machine VM.

For more information about Istio v1.13.0, please refer to its ReleaseNote

Kyverno v1.6.0 is officially released

Kyverno is a native policy engine on Kubernetes. Its main implementation principle is to use the Admission controller mechanism provided by Kubernetes. For the Kubernetes Admission controller mechanism, please refer to my previous article: "Understanding Kubernetes Admission Controller (Admission Controller)" .

This version provides a lot of interesting features, let me pick a few features that are particularly noteworthy:

• The sigstore Cosign-based image verification policy rule has entered the beta stage. For how to use Cosign, you can refer to my previous article Container Image Security in the Cloud Native Era (Part 1) .
  In this version, many enhancements including keyless, annotation and other related enhancements have been added, and this feature is also very convenient;
• Meta information related to OCI container images can be used directly in Kyverno policies, such as checking image labels, mounted volumes, and some other configurations.
  For example, a common usage scenario is that we hope that the container image should not be too large, then the following policy file can be used to limit the use of excessively large container images in the cluster.

The following policy file indicates that only container images with a volume less than 2Gi are allowed to be used. If the image is too large, it will be rejected directly.

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}}"

In addition, many useful functions have been added in this release for data manipulation.

For more details, please refer to its ReleaseNote

Trivy v0.23.0 officially released

Trivy is an easy-to-use vulnerability scanning tool. I have written many articles about Trivy before, so I won't go into details here. It recently released version v0.23.0, and there are some interesting things in this version:

• Trivy DB was originally downloaded by using the GitHub Release of the https://github.com/aquasecurity/trivy-db project, but at present, if a large number of repeated downloads occur, GitHub's current limiting policy will be triggered. So now it's time to switch Trivy DB to use GitHub Container Registry for hosting. In this way, on the one hand, the problem of GitHub's current limit can be avoided, and on the other hand, the data analysis tools provided by ghcr.io can also be used. Note that this is a breaking change.
• Trivy can now download and scan images directly from Azure's ACR, no need to install az tools, or pre-download images;

For more details, please refer to its ReleaseNote

Upstream progress

• #107695 · kubernetes/kubernetes This PR is actually a fix for the Static Pod lifecycle part of Kubelet management. We all know that the life cycle of Static Pod is not affected by kube-apiserver and is managed by Kubelet. However, the previous related issues and PRs did not cover the need to have the same name when restarting the Pod. The logic has been corrected in this PR, adding the full name of the Pod;
• #107775 · kubernetes/kubernetes If Pod preemption fails during scheduling, add details to the event. This is very helpful for us to debug the problem;
• #107317 · kubernetes/kubernetes The code of the dockershim component of the in-tree in the current Kubernetes repository has been deleted, and the cleaning of other related components such as kubelet has been basically completed. This PR completes kubeadm's support and logic for removing in-tree dockershim, mainly changing the default container runtime configuration, access address, etc. For details on Kubernetes' removal of in-tree dockershim, see my previous article "K8S Deprecated Docker? Docker doesn't work anymore? Give me a break! " . On the evening of this Friday (February 18), I will also do a live broadcast to chat with two friends from SUSE Rancher about how enterprise users will deal with Kubernetes after dockershim is removed.

Off topic

There has been no continuous update for a while, thank you for your attention. This period of time is mainly due to two reasons. On the one hand, I am taking a personal rest. On the other hand, there are many things to do.

However, starting from this article, the "K8S Ecological Weekly" will resume its weekly updates as normal! Hope to keep changing!

---

Welcome to subscribe my article public account [MoeLove]