Kubernetes security release in version 1.26: What's new

What’s new in Kubernetes security? The Kubernetes release v1.26 released in December 2022, introduces and builds on several features that can impact cluster security. In this post, we will look at several changes and what they mean for security across your Kubernetes environments as you plan your Kubernetes security operations in the new year.  Several smaller feature enhancements collectively have a significant impact, especially regarding the overall Kubernetes security posture.

We’ve previously tackled Kubernetes security releases to keep an eye on the latest features. Today is no different. Keep reading for everything DevOps engineers, platform providers, maintainers, and security teams need to know about Kubernetes 1.26 security. In this article, we'll discuss how Kubernetes brings incremental security to the platform.

Key Kubernetes security updates in release 1.26

Let's start by walking through the significant updates in Kubernetes 1.26 that have an impact on security:

• #3031 Release Artifact signing

  In Kubernetes v1.26, the Kubernetes project has upgraded support for release artifact signing via cosign to beta (it was first introduced as an alpha feature in K8s 1.24). This feature allows users of these releases to embed signature verification as part of their release process, reducing the risk of a supply chain compromise. Release artifacts include things like container images, binaries, and other files that are distributed as part of a Kubernetes release.

• #3488 Built-in admission control

  Kubernetes v1.26 introduces a new alpha feature that allows cluster operators to validate workloads at admission using Common Expression Language (CEL) templates, without the need for additional software. This feature is implemented as an in-cluster controller that uses CEL templates to evaluate incoming requests against a set of predefined policies. This makes it simpler for cluster operators to implement security policies, such as image signing controls, and reduces the risks associated with using external admission controllers. However, it is important to note that this version of the feature only validates admission webhooks and does not support workload mutation. An external product such as Kyverno or OPA Gatekeeper would still be required for that kind of functionality

• #2317 CSI control of fsGroup

  With the Kubernetes 1.26 release, Pod Container Storage Interface (CSI) drivers were introduced with the capability of applying ownership and permissions settings to storage resources when volumes are attached or mounted. Specifically, the addition of the fsGroup field in the VolumeAttachment API allows you to specify a group ownership for the storage resources. This allows users to ensure that pods running with a certain fsGroup have appropriate access to the storage resources. It also helps to ensure that the right access controls will be enforced over storage resources as soon as those resources are exposed to clusters. By extension, this change makes it easier to enforce Kubernetes security rules that conform with standardized guidelines.

• #3325 Auth API to query user self attributes

  Since Kubernetes lacks the concept of a "user" object, and instead relies on several authentication mechanisms to assign usernames and group memberships based on the information provided during authentication, it can be difficult for users to find out what groups they belong to when troubleshooting authorization issues in the cluster. A new feature, introduced alpha level in v1.26, aims to fill this gap by providing an API endpoint that users can call to get information about themselves after authentication.

• #2799 Reduction of secret-based service account tokens

  This isn’t really a net new feature but more of an update on how Kubernetes handles service accounts to enhance cluster security. To authenticate to the API server, prior to 1.26, service accounts have traditionally been assigned credentials based on Kubernetes secrets at pod creation time. The downside of this approach is that these secrets do not expire, meaning that if one of them is lost or stolen, the only way to revoke access is to delete the service account itself which can be especially cumbersome if it is a system service account. The new approach is to make use of the TokenRequest API to provide service accounts with expiring JSON web tokens (JWT) in place of those secrets. This has the obvious benefit of reducing the risk of an attacker stealing a token. This means that a pod can request a token only when it needs to authenticate to the Kubernetes API, however it also means that cluster operators will need to configure and manage token refreshes accordingly.

• #1981 Windows privileged containers

  The new release supports running Windows containers in privileged mode as a stable feature. Previously, only Linux containers supported privileged mode on Kubernetes. Although running privileged containers can be a security risk when you do it unnecessarily, the ability to operate privileged containers on Windows in a Kubernetes-native way makes it easier to keep containers that require special privileges. These include the ability to control networking and storage resources at the host level, inside Kubernetes, rather than using a less secure, ad-hoc approach.

Adding these valuable additions will not solve all existing Kubernetes security issues, so they still need to be augmented with tools that address significant vulnerabilities, such as, securing Kubernetes API calls.

As Kubernetes approaches its tenth anniversary (in 2024), it is noteworthy that the new releases continue to incorporate enhancements that make Kubernetes more secure, more reliable, and more observable. This update makes Kubernetes cluster security easier for operators and engineers and enhances the overall Kubernetes experience and security posture.

Want to read more about Kubernetes security? Check out our post on Kubernetes and multi-cloud security in the modern enterprise environment.

Pallavi Kalapatapu is a Principal Engineer at Outshift, formerly Cisco’s Emerging Technology & Incubation organization.