Kubernetes version 1.22 release – everything you should know

Kubernetes version 1.22, the latest release of Kubernetes, comes with bug fixes, enhancements, and new features that make the platform more stable, scalable, and user-friendly. There are a total of 56 improvements with different maturity levels and a considerable number of API removals.

In this article, I’ll focus on the security-related changes in Kubernetes as well as a few other significant changes in Kubernetes API and usability. You’ll find notable security changes grouped under two headings—auth special interest groups (SIGs) and Node SIGs.This should help you easily find the updates that will have the greatest impact for your enterprise.

Authorization &Authentication

Auth SIGs focus on Kubernetes authorization, authentication, and cluster security policies. In the new Kubernetes version, there are three critical changes to auth SIGs. The first and the most significant change is the PodSecurity replacement, followed by the graduation of Bound Service Account Token Volume, and finally the audit log fixes.

PodSecurityPolicy Replacement

This policy replacement is the most significant change in this release, as it introduces a new admission controller for enforcing the Pod Security Standards.

The primary motivation for this change is the depreciation of the PodSecurityPolicy in v1.21. This change offers are placement without compromising the current ability of the platform to limit privilege escalations.

With v1.22, you can implement policies at the namespace level by setting labels. There are three modes for taking action when the policy is violated:

●      Enforcing: The pod will be rejected.

●      Audit: It will create an audit annotation, but the pod is allowed.

●      Warning: It will make a user-facing warning, but the pod is allowed.

The primary goal of this change is to create a way to limit pod permissions so that all pods aren’t running with root permissions on the nodes. Further examples and documentation related to this change are available in Kubernetes Enhancement Proposal (KEP) #2579,where you’ll find specific information about the pod security standards to handle host ports, AppArmor and SeLinux options, and volume operations.

Bound Service Account Token Volume to GA

The second important change from Auth SIGis the graduation of the BoundServiceAccountTokenVolume feature to GA. With this change, rather than a secret-based volume, the service account admission controller will add a volume similar to what you see in the example volume configuration below:

There are three noteworthy elements in the service account token volume definition:

1. The ServiceAccountToken is retrieved from kube-apiserver, and it is bound to the pod.
2. The configMap contains a CA bundle to verify connections to the kube-apiserver.
3. The downwardAPI references the namespace of the pod.

This change aims to create a novel method to provision service account tokens while following the scalability and security requirements of Kubernetes. It’s important to check the required attenuations in tokens—such as audience, time, and object bindings—if you plan to use tokens in your applications.

You can learn more about the design motivation and find example usages of service account token volumes from the KEP #1205.

Audit Logs

if you are using the audit log files and validating admission webhooks, there are two bug fixes for the audit log operations in this release that you need to be careful about using:

●      KubernetesAPI will create new audit log files with an access mode of 0600; however, the existing file permissions will not be changed. If you are reading the audit log files using a non-root user, you will need to recreate the file with the correct access permissions.

●      An audit logentry will be recorded when the Kubernetes API cannot reach a validating admission webhook. You can check the changed files and source code in PR #92739.

Node

There are two significant security-related changes in this release from Node SIG, which are responsible for the components and interactions between pods and host resources.

Rootless Mode Containers

This new feature allows running the Kubernetes components—such as kubelet, Container Runtime Interface (CRI), or Container Network Interface (CNI)—as a non-root user on the host. You can do this by using a user namespace and cgroup.Therefore, the new feature is mentioned in the documentation as Rootless Containers following the POC named usernetes.

The main motivation for this change is to protect hosts from potential vulnerabilities caused by the container workloads.The change also enables end-users to securely share the host machines such asHigh Performance Computing (HPC) instances. You can check  further implementation details and examplesin KEP #2033.

SeccompDefault

Version 1.22 adds a new alpha feature gate named SeccompDefault.  It enables seccomp by default for all pods running in the cluster to improve the security of the overall Kubernetes system.

This change adds a new security layer to prevent CVEs or 0-day vulnerabilities by enabling seccomp as default. Design details and example usages are available as part of the KEP #2413.

Now that I’ve covered the key security updates, let’s look at some additional significant changes that could enhance your daily use of Kubernetes.

Additional Updates

kubectl

●      The –record flag is deprecated from kubectl and is replaced with the HTTP request headers mentioned in KEP #859.

●      The LASTRESTART column is added to the output of kubectl get pods, similar to the following:

StatefulSets

StatefulSets API is enhanced with minReadySeconds and AvailableReplicas with the corresponding changes in spec and in the status. With the new optional field .spec.minReadySeconds, you can specify the minimum number of seconds that it should take for a newly created pod to be considered ready.

The default of this optional field is 0, which means the pod should be regarded as ready as soon its probes are alive. You can check the KEP #2607 and changes in the documentation to start using the new field.

etcd

The etcd version is updated to3.5.0-rc.0-0 with the corresponding server and clients in Kubernetes API. It’s especially important to check your client versions if you access Kubernetes etcd directly, or if you backup and restore it for disaster recovery.

Conclusion

With the new release, Kubernetes will provide user-friendly features with enhanced security and become a more stable environment.

In this article, I’ve focused on the security-related changes from Auth and Node SIGs because security changes impact every aspect of your application. Pod security changes, service account tokens, and audit log fixes from Auth SIG will all harden the Kubernetes security. Similarly, Rootless Containers and enabling seccomp by default fromNode SIG will ensure Kubernetes nodes are safe.

For more details on the upcoming release, you can search through the release notes and check the changelog of v1.22.

For additional security, you can watch a demo with ARMO to improve the security and control in your Kubernetes environment

To learn about the new version of Kubernetes v1.25, you can read here