With another Kubernetes release upon us, there are, as ever, a load of new features to consider. These include features to help companies use Windows containers securely and improvements in Kubernetes’ supply chain security. In this post, we’ll take a look at some of the more significant features of this release.
Dockershim deprecation
Undoubtedly, the most significant change in this release of Kubernetes is the removal of the Dockershim. This is a legacy piece of Kubernetes that provided direct support for Docker as a container runtime, which was needed before the container runtime interface (CRI) became standardized.
The removal will have an impact on clusters that use Docker as their container runtime, but not on ones that use other common CRIs, such as Containerd and CRI-O. Notably, the three major managed Kubernetes distributions, GKE, AKS, and EKS, have all been using Containerd for new clusters for some time, so this is likely to only affect older clusters.
Where a cluster is affected by this, there are a couple of options. One is to use Mirantis’ CRI-Dockerd, which is what Docker is doing for its Docker Desktop product. The other option would be to migrate the cluster to one of the alternative CRI options available.
The Kubernetes project maintains a documentation page with more information about this topic.
Signing of Kubernetes artifacts
One useful change for companies that download Kubernetes artifacts directly from the Kubernetes project repositories is that from 1.24 they will be signed with Cosign, which will allow users to validate the artifacts’ integrity and authenticity. For security processes like digital signing to be effective and reliable, they need to be widespread. There’s not a lot of sense in validating just 5% of the software you consume, so it’s great to see the Kubernetes project adding this functionality.
Reduction of secrets-based service account tokens
As part of the move to improve the security of service account tokens, the reduction of secret-based service account tokens is moving to beta in 1.24. Traditionally, in Kubernetes, these credentials have no expiry date set, so they will remain valid for the lifetime of the service account. This can present a security risk for clusters because an attacker who gains access to a high-privileged service account token can use it to persist access to a cluster.
Kubernetes is moving to a better system that has short-lived tokens, and this feature will advance the removal the old secrets-based system.
Identify Windows pods at API admission
Identifying Windows pods at the API admission level will be a useful feature for cluster operators who use Windows containers. Essentially, it will make the container operating system visible to admission controllers, which will allow them to apply different security policies based on the operating system that’s being used. This is important, since Linux and Windows support different sets of security context settings. With this change, it will be possible to create better security policies for your clusters.
Beta features off by default
This isn’t a code change, but it will affect how new features roll out in future Kubernetes releases. Until now, Kubernetes’ policy was to have alpha features disabled by default and beta features enabled by default. This has led to a lot of use of features whose APIs might change before they get to release.
While it’s useful to get early feedback on new features, that approach does pose possible stability and complexity problems. Against this backdrop a decision has been taken, so that for future releases any features that hit beta will be disabled by default. In an unmanaged Kubernetes cluster, operators can enable beta features by passing flags to the Kubernetes API server. However, in managed distributions, it will be up to the provider which, if any, beta features are enabled.
Conclusion
This latest release of Kubernetes brings some changes that will need careful studying, especially Dockershim, to ensure that upgrades are seamless and don’t cause any production issues. It’s also nice to see ongoing progress on improving Kubernetes’ default security posture, making newer clusters a safer prospect for operators and users.
