As the latest version of Kubernetes is already here, we look at some of the biggest changes the newest release brings with it and all the latest features. There are several new features that allow companies to securely use windows containers and take advantage of the numerous improvements in the supply chain security of Kubernetes. In this article, we will be looking at some of the latest updates and features that have been introduced by Kubernetes in its newest release.
- Dockershim Deprecation
Without a doubt, the biggest change in the newest Kubernetes release has been Dockershim’s removal entirely. It was Kubernetes’s legacy piece and offered direct support to Dockers as container runtimes, as that used to be required before the CRI (container runtime interface) had become the standard. Its removal has had a significant impact on clusters that have been using Dockers for their container runtimes, but others that are using common CRIs, like CRI-O and Containerd won’t be affected as much.
It should be noted that the three main managed distributions in Kubernetes that are EKS, GKE, and AKS have for some time all been using Containerd for newer clusters. That means it is most likely to have an impact on older clusters.
There are several options available in instances where clusters have been impacted by this. The best course of action is using Mirantis’ CRI-Dockerd, as that’s what Docker has done for its product, the Docker Desktop. The next option you have will be dependent on migrating your clusters to any of the alternate options for CRI that are available.
- The Signing of Artifacts in Kubernetes
One change that will be extremely useful for companies, especially those that download artifacts in Kubernetes directly from the project repositories in Kubernetes, is that after 1.24, they are all going to be signed with Cosign, as that allows users to validate the authenticity and integrity of artifacts.
To ensure that security processes such as digital signing are reliable and effective, they must be widespread. It doesn’t make sense to validate only 5% of the software consumed by you, and that’s why it’s great news to know that this functionality has been added by Kubernetes.
- Reducing Service Account Tokens that Are Secrets-Based
To ensure that the security of service account tokens was improved, Kubernetes 1.24 decided to reduce service account tokens that are secrets-based and move them into beta. In Kubernetes, it has been a tradition that there is no expiry date set for these credentials, which ensures that they are valid for the service account’s lifetime. That generally presents security risks for clusters, since attackers that manage to gain access to any service account token that is high-privileged can use them to obtain persistent access to clusters.
Now, Kubernetes has decided to shift towards a better designed system, which has tokens that are short-lived. The best part is that this feature will ensure the advancement of removing the older system that is secrets-based.
- Checking Windows Pods at API Admission
Another feature that will be useful for cluster operators that are using Windows containers is the ability to check windows pods at API admission. In essence, it makes the operating system of the container visible to admission controllers, and allows them to use various security policies depending on whichever operating system has been used.
It’s an extremely valuable point of note because Windows and Linux support multiple sets of settings for security context. This new change will ensure that you can easily create security policies that are in the best interests of your clusters.
- Turning Off Beta Features by Default
It’s not a code change; however, it’s going to have an impact on how newer features are going to roll out in Kubernetes releases in the future. Up to this point, the policy applied by Kubernetes has been that they will disable alpha features by default and will ensure that beta features are enabled. That has meant that many features are used whose APIs may change even before the release is announced.
Even though it’s best if you manage to get early feedback on the newer features, this approach poses several complexity and stability problems. To counter this problem, a decision has been made to ensure that all future releases for any of the features in Kubernetes that are in beta mode will be disabled. In Kubernetes clusters that are unmanaged, operators will be allowed to enable beta features when they pass flags to the API service in Kubernetes. However, in distributions that are managed, the providers will have full control over which beta features they want enabled.
The latest Kubernetes release has brought about a significant number of changes, which will need to be studied extensively and applied properly in clusters. The one main change that should be given significant attention is the Dockershim, especially if you want to ensure there aren’t any production issues and that you manage to get seamless upgrades.
It’s a good thing to see that Kubernetes is addressing the problems that it had in other clusters and working hard to ensure that future releases don’t have any issues. The ongoing progress that is being made on improving Kubernetes in its default security posture has meant that you can make new clusters safely and appropriately for both users and operators.
It’s something that Kubernetes has given significant thought and that has allowed the many changes to be made seamlessly and without any extensive oversight. As of now, the latest changes and updates in Kubernetes 1.24 will ensure that you get your money’s worth and can make easier clusters in Kubernetes that are going to provide you with extensive features.
Further blogs within this The Latest Updates in Kubernetes 1.24 category.