Kubernetes 1.22 meets the requirements of the industry

Kubernetes 1.22 meets the requirements of the industry

23.11.2021By Alex Chalkias *

“Kubernetes 1.22” has been available for a few weeks. Reason enough to take a look at the latest version of the open source container orchestration. How does it react to the challenges of data center multicloud-all-secure-demanding thinking?

Related companies

No concert without a treble clef, no application without encryption, no orchestration without leading security

(Photo by Gerd Altmann on Pixabay)

In the middle of the year, the “Kubernetes and Cloud Native Operations Report” was dedicated to exactly this topic. For the report, 1,200 IT professionals and seven industry experts were interviewed about Cloud native. In detail, it was about usage habits, challenges, goals and wishes of users and companies in this still quite new method of developing and providing software.

This Kubernetes version sends a clear signal to more security. Three of the most important new functions are dedicated to security.

A quick look at the report shows that this meets the needs of users. First and foremost, they are concerned about security: 46 percent believe that security should be at the top of the list for DevOps developers working with native cloud technologies. Security is also the top priority in the development of containers or the implementation of an edge strategy, with 56 and 49 percent respectively.

Kubernetes security comes first

These new Kubernetes security features should meet the desire of the developers:

• 1. Cluster-wide seccomp profile: Kubernetes 1.22 now includes a cluster-wide seccomp profile by default. In the Linux kernel, Seccomp has the task of binding processes to a very limited number of system calls. Before 1.22 Kubernetes already allowed the execution of containers using a seccomp profile. After all, the function has been stable since Kubernetes 1.19, but until now it had to be activated optionally via an ‘opt-in’. By default, the feature can now prevent hackers from exploiting a variety of known vulnerabilities and security risks (CVEs) and zero-day vulnerabilities.

• 2. Containers in rootless mode: Running containers as a non-root user is the most important best practice for container security. Kubernetes 1.22 takes full advantage of this concept, so that the K8s control level can be executed in the user area.
  In particular, can kubeadm well, if necessary, not as root can be operated by executing the control level with lower rights. The other components of the Kubernetes node cannot work as root as an experiment. This makes it much more difficult for attackers to attack the underlying infrastructure in a compromised Kubernetes cluster.

• 3. PodSecurity-Approval for the replacement of PodSecurityPolicy: A new feature for allowing PodSecurity is now included. It is intended to replace the PodSecurityPolicy, which has been deprecated since Kubernetes 1.21. The PodSecurity Admission Controller enforces pod security standards at the namespace level. According to the report, this method is the de facto way to isolate applications in Kubernetes.

The Admission Controller has three levels of policy enforcement:

• Enforce policy violations will result in pod rejection.

• Audit policy violations trigger an audit note, but are otherwise permissible.

• Warn policy violations trigger a warning for the user, but are otherwise allowed.

Opening Windows to New Worlds

Countless companies have developed and operated software for “Microsoft Windows” in the past. The operating system still has a certain way to go before it has become a “first-class resident of the Kubernetes platform”. However, Kubernetes 1.22 comes with a few improvements and simplifications for creating and operating containers on a large scale under Windows.

For example, privileged containers that are already available on Linux are now also supported on Windows. They have direct host access and are quite useful for administration, security and monitoring purposes, even if they are not suitable for all workloads.

As part of the new features for Windows, new developer tools have also been released with version 1.22. They support various CNI providers and are executable on several platforms. By manually creating Windows binaries for “Kubelet” and “Kube-Proxy”, you also make it possible to test early-support Kubernetes functions under Windows. Finally, CSI support for Windows, initially released as an alpha feature in Kubernetes 1.16, is now generally available.

Intent-based configuration

One of the technologies developed by Canonical, which is also part of the CNCF map, is the Charmed Operator Framework. This Cloud Native Landscape Project of the Cloud Native Computing Foundation (CNCF) aims to map the previously unexplored terrain of Cloud Native technologies and to categorize most projects and product offerings in the field of cloud Native technologies.

The framework allows users to move from configuration management to application management by capturing the business goals in a model. When evaluating the report, it turned out that most of the respondents, although they are still in the early stages of their K8s journey, really wanted to try Charmed Operators.

There is still a lot of work to be done to improve the overall management of the Kubernetes lifecycle; the introduction of operator patterns is an important stage in this process. Kubernetes is currently adding extensions that allow users to configure clusters and implementations more intuitively.

Also the step of Server-side Apply in stable mode in version 1.22 is important. This function makes it possible to manage resources via declarative configurations. Changes to a resource can be tracked field by field, implementing a fine-grained authorization model.

Alex Chalkias: “There is still a lot of work to be done to improve the overall management of the Kubernetes lifecycle, but ….“

(Image: Canonical)

Server-side Apply the command kubectl apply replace; the mechanism makes it easier for users and controllers to make changes to their configurations by specifying their intention. The new logic is implemented in the Kubernetes API server to fix most of the pitfalls of kubectl apply and make the operations directly accessible through the K8s API.

* Alex Chalkias is Product Manager for Data Centers at Canonical.