The content of "K8S Ecological Weekly" mainly contains some recommended weekly information related to the K8S ecology that I came into contact with. Welcome to subscribe to the column "k8s ecology" [1].
Helm v3.3.4 was released this week. This version is a bugfix version that fixes some problems introduced in Helm v3.3.2.
helm repo add is an idempotent operation, but since v3.3.2, in order to fix security issues, a break change has been introduced. If you want to add a repo with the same name, you need to add --force -update parameter is fine. This caused many automation tools to fail, so this was fixed in the v3.3.4 version. That is: if the added repo is exactly the same, this operation is still idempotent. If the repo only has the same name, but the url or repo information is different, you need to add the --force-update parameter.Docker v19.03.13 has been released. Although this version does not seem to have many changes, and there is not much explanation in the ReleaseNote, this version actually requires special attention.
defer function used to clean up in the code were incorrect;The containerd v1.2 series was originally scheduled to end maintenance (EOL) on September 26, 2020. Now after discussion by the maintainers, it has been decided to extend this time to October 15 for migration to v1.3.
In other words, if you are in charge of the Docker/related container basic environment, I suggest you upgrade the Docker version to v19.03.13, or directly upgrade containerd from the v1.2 series to v1.3.7.
As for the changes between containerd v1.3 and v1.2, I suggest you read my previous "K8S Ecological Weekly". Since the release of containerd v1.3.0 in September last year, I have introduced almost every version in detail. .
Podman has brought many new features in v2.1, let's take a look:
podman save and podman load Now you can also create or load archive files containing multiple images like docker;$HOME/.config/containers/containers.conf by default. If you upgrade from the old version, you may encounter the following prompt:WARN[0000] Found deprecated file /home/tao/.config/containers/libpod.conf, please remove. Use /home/tao/.config/containers/containers.conf to override defaults.
WARN[0000] Ignoring libpod.conf EventsLogger setting "journald". Use "/home/tao/.config/containers/containers.conf"if you want to change this setting and remove libpod.conf files.
WARN[0000] Found deprecated file /home/tao/.config/containers/libpod.conf, please remove. Use /home/tao/.config/containers/containers.conf to override defaults.
WARN[0000] Ignoring libpod.conf EventsLogger setting "journald". Use "/home/tao/.config/containers/containers.conf"if you want to change this setting and remove libpod.conf files.
podman network related functions are now fully supported, and rootless containers can join the network; podman run and podman create added a new option --cgroups=split to --cgroups mode, which is more useful when running podman container as a systemd unit; podman play kube has made a lot of improvements, such as supporting read-only mounting, processing HostAlias, etc.; Podman run and podman create can add the --tz parameter to directly set the time zone of the container, which is a useful feature.CVE-2020-14386[2] For this vulnerability, I saw the news from the mailing group in early September. At that time, I did a general test, but I didn't write any relevant content.
Today, a friend happened to discuss this loophole again, so let’s talk about it briefly.
This is a vulnerability with a wide range of impacts, because it is a kernel vulnerability rather than an application layer vulnerability, and the kernel version is between v4.6-rc1 and v5.9-rc4, all will be affected by this vulnerability.
I am on a CentOS 8 system and directly download https://seclists.org/oss-sec/2020/q3/att-146/trigger_bug_c.bin After compiling with gcc, execution will immediately crash the system and restart.
ReaHat has an introduction to this vulnerability[3], which introduces that the condition for triggering this vulnerability is that only local users with CAP_NET_RAW permission can trigger this vulnerability.
For cloud native practitioners, if you are using Kubernetes, then I suggest that if there is no special reason, you can directly set the PSP and prohibit the CAP_NET_RAW permission.
Or skip the affected version of the kernel. Currently, the kernels 5.4.64 and 5.8.8 have been fixed. I have upgraded my environment to kernel version 5.8.11.
kubectl portforward can continue to forward TCP and UDP.Welcome to subscribe to my article public account【MoeLove】
TheMoeLove
[1]
k8s ecology: https://zhuanlan.zhihu.com/container
[2]
CVE-2020-14386: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14386
[3]
CVE-2020-14386 RedHat: https://access.redhat.com/security/cve/CVE-2020-14386
Recommended Posts