December 5, 2021 | Cloud, Kubernetes
Kubernetes’ second release in 2021, version 1.22, has been out for a little while now and with 1.23 on its way, we thought we’d take a look back. Kubernetes 1.22 was a highly comprehensive release with 53 enhancements in all three graduation levels: 13 features have graduated to stable, 24 enhancements reached beta status, and 16 new features have been accepted into the alpha stage.
The latest version has some noteworthy security features such as running Kubelet without root access, pod security policies, and seccomp. There are also a couple of deprecated and removed APIs. In this blog, we’ll discuss the significant changes in v1.22, as well as how to handle the removed APIs.
WRITTEN BY
The server-side apply feature has graduated to general availability (GA) in Kubernetes v1.22. The new feature moves the logic of kubectl apply to the Kubernetes API server, which makes it easier for tools other than kubectl to manage Kubernetes resources. For example, the Kubernetes Terraform provider makes use of it with its kubernetes_manifest resource. It comes with a new field management method to prevent multiple tools and controllers making conflicting changes, and defines how resources should be managed as declarative configurations. So, if you’re changing the field test-key of a configmap test-cm in a kubectl apply, then the ownership of the field moves to the manager kubectl as follows:
apiVersion: v1
kind: ConfigMap
metadata:
name: test-cm
namespace: default
managedFields:
- manager: kubectl
operation: Apply
apiVersion: v1
time: "2021-10-01T0:00:00Z"
fieldsType: FieldsV1
fieldsV1:
f:data:
f:test-key: {}
data:
test-key: test-value
The server-side apply feature provides a more straightforward and declarative mechanism to follow changes to resources. If you’re developing a controller, this means you can simplify the resource update logic on your side, but you also need to resolve conflicts when multiple managers are acting on the same fields.
Kubernetes client credential plugins were a feature available in the previous releases, and it has now graduated to GA with Kubernetes v1.22. The providers make it possible to authenticate using external systems such as a Key Management System (KMS) or Hardware Security Module (HSM), or using third-party tools such as the AWS CLI to retrieve short-lived credentials for accessing the Kubernetes API. If you’re writing your own custom provider, you can check out the sample-exec-plugin to get started.
etcd is the database of Kubernetes where the state of each Kubernetes resource is stored. In Kubernetes v1.22, the etcd version is upgraded to 3.5.0, which provides better performance and more security features. If you’re using the same etcd instance or backup and recovery mechanisms, updating your clients to version 3 for compatibility is suggested.
Control groups (cgroups) is the Linux kernel feature that makes the containerization of processes possible. It limits and isolates the resource usage (CPU, memory, disk, networking) of processes and makes them run separately. Kubernetes was using cgroups v1 API where QoS class for pods only applied on CPU resources. In Kubernetes v1.22, cgroups v2 API is an alpha feature to manage memory allocation and isolation.
If you’re not into container runtime and memory management on the nodes, you won’t face any side effects. However, container lifetime and node availability will increase with the usage of cgroups V2 API.
The new version of Kubernetes comes with another alpha feature to make system administrators’ life easier: running nodes with swap memory. In the previous releases, you had to disable swap space in your Kubernetes nodes, whereas this new feature provides running nodes where swap is enabled. Furthermore, you can configure swaps on Linux servers with a portion of block storage as virtual memory.
Although the feature seems like only a slight improvement, it makes installing Kubernetes and node management simpler and increases the operator experience.
Another alpha feature of the v1.22 release is SeccompDefault. The new flag enables seccomp by default for all pods and creates a new layer of security to prevent 0-day vulnerabilities or Common Vulnerabilities and Exposures (CVE). When the flag is in use, security administrators of Kubernetes clusters will have fewer things to worry about. If you want to enhance the security of your clusters and try this new feature out, a tutorial on enabling and configuring seccomp profiles is already available in the Kubernetes documentation.
Running processes as root is always a security red flag, as faulty or misconfigured applications can exploit their root access. With this new feature, it’s now possible to run Kubelet, the agent that runs on each node, as a non-root user, which will make the clustersless vulnerable to attacks.
The Kubernetes API is a living system that evolves with every new feature. When the new features become alpha, beta, and finally GA, their endpoints are reorganised. In v1.22, many APIs have been removed from Kubernetes, as they have graduated to GA, and new stable APIs have been added. The following beta APIs have been removed:
admissionregistration.k8s.io/v1beta1: ValidatingWebhookConfiguration and MutatingWebhookConfiguration
apiextensions.k8s.io/v1beta1: CustomResourceDefinition
apiregistration.k8s.io/v1beta1: APIService
authentication.k8s.io/v1beta1: TokenReview
authorization.k8s.io/v1beta1: SubjectAccessReview, LocalSubjectAccessReview, SelfSubjectAccessReview
certificates.k8s.io/v1beta1: CertificateSigningRequest
coordination.k8s.io/v1beta1: Lease
extensions/v1beta1: Ingress
networking.k8s.io/v1beta1: Ingress
If you have one of the listed resources in your manifest files or Helm charts, you need to update their API versions. In addition, there may be structural changes in the resource definitions. Thus, a migration guide for each resource is available in the Kubernetes documentation, including each step you need to take.
Kubernetes v1.22 comes with new features that are security-oriented and focused on increasing the user experience. This article focused on the significant changes you need to consider before upgrading to Kubernetes v1.22. For more details, you can have a look at the Kubernetes release notes and read through the changelog as well.
This blog is written exclusively by the OpenCredo team. We do not accept external contributions.
Cloud for Business in 2023: Raconteur and techUK webinar (Recording)
Check out the recording of our CEO/CTO Nicki Watt, and other panellists at the Raconteur and techUK webinar discussing “The Cloud for Business Report,” which…Lunch & Learn: Secure Pipelines Enforcing policies using OPA
Watch our Lunch & Learn by Hieu Doan and Alberto Faedda as they share how engineers and security teams can secure their software development processes…