{"id":46485,"date":"2022-05-04T19:02:15","date_gmt":"2022-05-04T19:02:15","guid":{"rendered":"http:\/\/38f6c74b-ef9b-4fa7-956a-b944514abf8b"},"modified":"2022-05-04T19:02:15","modified_gmt":"2022-05-04T19:02:15","slug":"kubernetes-1-24-stargazer-an-exceptional-release-with-two-major-changes","status":"publish","type":"post","link":"https:\/\/www.threatshub.org\/blog\/kubernetes-1-24-stargazer-an-exceptional-release-with-two-major-changes\/","title":{"rendered":"Kubernetes 1.24 Stargazer: An exceptional release with two major changes"},"content":{"rendered":"
\n
\n
\"Steven<\/span> <\/a> <\/div>\n<\/p><\/div>\n<\/p><\/div>\n

Kubernetes<\/a>, everyone’s favorite container orchestrator, in its latest release, Kubernetes 1.24 Stargazer<\/a>, has made two major changes: The developers dropped support for the Docker Engine container runtime<\/a> and added supply chain security via Sigstore<\/a>.  <\/p>\n

First, don’t start hyperventilating because Dockershim<\/a> has been deprecated. While Dockershim enabled you to use the Docker containerd runtime within Kubernetes, it was never designed to be embedded inside Kubernetes. Further, it’s incompatible with Kubernetes’ Container Runtime Interface (CRI)<\/a>. The fix was for dockershim to bridge the gap between Docker’s containerd<\/a> and CRI.  <\/p>\n

Maintaining dockershim, however, was a pain so Kubernetes started deprecating it. As Kat Cosgrove, a Pulumi<\/a> Developer Advocate and Cloud Native Computing Foundation (CNCF)<\/a> Ambassador, explained, in Kubernetes’ early days, “We only supported one container runtime. That runtime was Docker Engine.<\/a> Back then, there weren’t really a lot of other options out there and Docker was the dominant tool for working with containers, so this was not a controversial choice.”  <\/p>\n

But Kubernetes users wanted more runtime choices. They got that with CRI, but the Docker Engine was not CRI-compatible. The fix, Dockershim, filled in the gaps between Docker Engine and CRI. “However,” Cosgrove continued, “this little software shim was never intended to be a permanent solution. Over the course of years, its existence has introduced a lot of unnecessary complexity to the kubelet<\/a> itself. Some integrations are inconsistently implemented for Docker because of this shim, resulting in an increased burden on maintainers, and maintaining vendor-specific code is not in line with our open-source philosophy.” <\/p>\n

Unfortunately, Cosgrove admits, the Kubernetes developer community did a poor job of communicating what they were doing by removing Dockerhsim. It also doesn’t help that when we say “Docker,” we might refer to the container image<\/a>; Docker, the company<\/a>, or the Docker runtime. By removing Dockershim, we’re referring only to the runtime. Docker containers still run just fine on Kubernetes. As Cosgrove concluded, “Docker is not going away, either as a tool or as a company.” Still, “removing dockershim from kubelet is ultimately good for the community, the ecosystem, the project, and open source at large.  <\/p>\n

But if you really want to stick with the Docker Engine you can even if Kubernetes no longer natively supports it. Mirantis<\/a>, which now owns the Docker program, will continue to support Dockershim in Docker Engine<\/a> and Mirantis Container Runtime with Kubernetes<\/a>. This new Dockershim program, cri-dockerd<\/a>, provides a shim for Docker Engine, which enables you to control Docker via the Kubernetes CRI. <\/p>\n

You can also, of course, switch to one of the supported Kubernetes runtimes<\/a>, such as containerd v1.6.4 and later, v1.5.11 and later, or CRI-O 1.24 and later. <\/p>\n

For more on making sure your Kubernetes clustered are ready for the change, see Is Your Cluster Ready for v1.24?<\/a> <\/p>\n

In another major development, Kubernetes is now supporting encrypted software artifact signing to improve its software supply chain security<\/a>. According to founding Sigstore developer Dan Lorenc, Sigstore certificates enable Kubernetes users to verify the authenticity and integrity of the distribution<\/a> they’re using by “giving users the ability to verify signatures and have greater confidence in the origin of each and every deployed Kubernetes binary, source code bundle, and container image.” <\/p>\n

The Kubernetes programmers began working on Supply chain Levels for Software Artifacts, (SLSA<\/a>, pronounced salsa) compliance to improve Kubernetes software supply chain security in 2021. SLSA is a security framework that includes a checklist of standards and controls to prevent tampering, improve the integrity, and secure the packages and infrastructure of software projects.  <\/p>\n

The Sigstore program, which is SLSA Level 2 compliant, is a major step forward for Kubernetes security. It improves software supply chain security by making it easy to cryptographically sign release files, container images, and binaries. Once signed, the signing record is kept in a tamper-proof public log. This gives software artifacts a safer chain of custody that can be secured traced back to their source.  <\/p>\n

Kubernetes 1.24 brings other improvements as well. For example, new beta application programming interfaces (APIs) will no longer be enabled in clusters by default. However, existing beta APIs and new versions of them will continue to be enabled by default. In another API change, Kubernetes 1.24 offers beta support for publishing its APIs in the OpenAPI v3 format<\/a>. <\/p>\n

There have also been storage and volume changes. Storage capacity tracking<\/a> now supports exposing currently available storage capacity via CSIStorageCapacity objects<\/a> and enhances scheduling of pods that use Container Storage Interface (CSI)<\/a> volumes with late binding. In the meantime, you can resize existing persistent volume with Volume expansion<\/a>. Work is also underway to migrate the internals of in-tree storage plugins<\/a> to call out to CSI Plugins while maintaining the original API. So far, the Azure Disk<\/a> and OpenStack Cinder<\/a> plugins have both been migrated. <\/p>\n

Finally, while there are many other changes and improvements, I particularly bring your attention to Kubernetes 1.24’s new optional networking feature, which lets you soft-reserve a range for static IP address assignments<\/a> to Services. With the manual enablement of this feature, the cluster will prefer automatic assignment from the pool of Service IP addresses, thus reducing the risk of collision. I like this feature a lot. <\/p>\n

A Service ClusterIP can be assigned either: <\/p>\n