Kubernetes Latest Version 1.31 Security Features

Kubernetes version 1.31 new security features 

The last few Kubernetes versions have incorporated security features in varying levels. Kubernetes v1.29 was the most dense with security features, but also included larger themes around cloud interoperability, performance and observability. These themes are all echoed in the later two versions, Kubernetes v1.30 and v1.31, which is released today. But today’s release is not without features of interest; and starts by tamping down on a tactic that has been used repeatedly by attackers to hack their way into Kubernetes clusters.

Only allow anonymous auth for configured endpoints in alpha

Many security incidents have relied on the ability to gain anonymous authentication into Kubernetes endpoints. For example, the Dero cryptocurrency miner, a targeted Kubernetes attack in 2023, gained initial access by first scanning for Kubernetes APIs where authentication was set to --anonymous-auth=true (which allows anyone anonymous access to the Kubernetes API). It is not stated in the research on the attack, but for this entry point to work, the cluster would also need an RBAC configuration that would allow for the creation of pods in that cluster.

This new proposal allows users to specify which endpoints can be reached by anonymous requests, while ensuring that other endpoints cannot receive these requests, even if RBAC configuration allows it. When used correctly, this new feature would effectively stop attacks like Dero. A recent pull from DockerHub showed that the Dero campaign is still alive and well; below is a detection from RAD’s behavioral detection and response platform for the campaign.

Fine-grained SupplementalGroups control in alpha

On Kubernetes.io, a supplementalgroup is “A list of groups applied to the first process run in each container, in addition to the container's primary GID. If unspecified, no groups will be added to any container. Note that this field cannot be set when spec.os.name is windows.”

Currently, supplemental groups apply to container runtimes (CRI-O and Containerd) at two levels, the OCI and the Kubernetes API. These result in two definitions of how the supplementalgroup should apply, creating conflict, such that the Kubernetes API interaction might allow unintended group memberships defined in the container image, versus the default and the supplementalgroup of the user/uid in /etc/passwd from the container.

This means that using a custom image could allow somebody to bypass policy enforcement and gain unexpected file access permission.  

This new proposal suggests a new API field to the Kubernetes API and CRI levels that would transparently control the applicable groups for a container process, solving this issue with the supplementalgroup.

Bound service account token improvements still in beta

This enhancement is still in beta, with docs available around the service account JWT schema and decisions on the specific approach. https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/4193-bound-service-account-token-improvements 

Service accounts are the machine or API users in RBAC - aka the most likely ones to be overlooked or forgotten. This enhancement allows for better tracking and quicker transparency into the token usage of service accounts. For example, this enhancement allows somebody to understand who made an original access request from a service account through the token; by binding info about the node for which the token is being used, to the JWT token itself. 

This means it’s easier to check if the host identity is indeed the one tied to the token, and determine where the original request for a serviceaccount token came from, without having to perform complicated cross-referencing.

nftables kube-proxy backend in beta

Kube-proxy is an essential part of Kubernetes networking, matching Services (which manage ip addresses across ephemeral workloads) to pods. The kube-proxy lives on each node, generally as a Daemonset or Linux process on the node. The two supported backends for kube-proxy are ip-tables and ipvs. Iptables are a massive bottleneck for kube-proxy services, slowing down performance and in some cases causing crashes.

The iptables implementation is relatively unstable and hard to add rules to via the API, and has already been deprecated in RedHat. It also has some built-in security issues that can’t be removed without breaking current users.

It is worth noting that some runtime security tools rely on iptables. The nftables mode, which is new, might not be compatible with network plugins or these runtime security tools as of yet.  

The overall goal of this proposal is to provide a new option, nftables, to the iptables and ipvs backends, and provide some graceful migration. This project is now moving into beta.

Authorize with Field and Label Selectors in alpha

In Kubernetes, field and label selectors help you to filter through the thousands of objects across your clusters, including pods, ReplicaSets, Deployments, Services and more. Sometimes it’s important to filter and sort through all of these objects. For example, you might have different teams working on certain Services or Deployments, so you need to label by team. Or you need to run a filter to find which pods have a new critical CVE running in them.

In this proposal, the field and label selectors would be available criteria for authorization decisions; in other words, third party authorizers could use these elements when making a decision whether or not to let a user access an object.

The capability would apply to certain verbs (currently targeting List, Watch and DeleteCollection), which makes sense given these verbs are included in the top RBAC over-permissions. The capability would also apply to webhook authorization, SelfSubjectAccessReview (SSAR) and more. 

Recursive Read-Only (RRO) Mounts in beta

A bind mount is when a directory tree is mounted, or saved into another place. Previously, when mounting a volume to a container with a bind mount, some pieces of the directory of the file are actually not read-only afterward.  This creates an obvious security issue. In this feature, the issue is fixed so that the bind mount is indeed read-only. Essentially, if a volume is mounted as read-only, it’s submounts should be read-only too.

Runc is the default container runtime underpinning other higher-level runtimes like Docker and CRI-O. Previously, this issue was fixed at higher levels, creating inconsistency across other higher level runtime implementations. The proposal aims to fix the issue now at the lower-level of runtime, in runC.

This was introduced in Alpha in Kubernetes v1.30

Split Image Filesystem into readable and writeable now in beta

This capability was released as alpha in 1.29, and is still in alpha in 1.30. In Kubernetes. In the kubelet, there is a layer that doesn’t change very much (the image layer), which is referred to as the readable layer, and the container and node layers, which can be referred to as the writable layer, because it contains the temporary files required for the kubelet to run.

The goal is to enhance the performance of the kubelet by separating readable and writable file systems, while ensuring the writable files required for running the kubelet are available on the kubelet itself. 

This enhancement could prevent an unwanted decline in performance of the Kubelet and make garbage collecting more transparent, because today when the image disk gets too full the garbage collector doesn’t have any context on which files it is taking from, as they are both stored in the same place. 

Add AppArmor Support to K8s now stable

AppArmor is a way to give access control capabilities to Linux, allowing for the creation of certain profiles that govern who can and can’t access what. Adding support for Kubernetes means that AppArmor can help you get better auditing through system logs and restrict what containers are allowed to do. It is installed as a kernel module on the node.

In Kubernetes v1.30 support for AppArmor was moved into GA.

Custom profiling support in kubectl debug command now in beta

The kubectl debug command deploys a pod to a node that you want to troubleshoot.The purpose of this enhancement is to allow more flexibility for the profiles of the pods that are deployed in this process, beyond a few defined debug profiles. In this debug profile, for example, the pod can access the node’s root file system.  Despite these profiles, users still want a way to specify environment variables, security contexts, etc. that should be implemented with these new pods. Currently, to do this, the pod that is deployed needs to be patched manually but at scale this is hard.

The new feature proposes the ability to create custom profiles for pods deployed into nodes for the kubectl debug command.

Multiple Service CIDRs in beta

In networking, uptime and availability can be limited by the fact that Kubernetes services like LoadBalancer, ClusterIP and NodePort are limited to the number of IPs that are available. This causes several availability and security issues:

• The logic of allocating Services IPs could possibly leak ClusterIPs
• The Service IP range is not exposed, so no other components can use it
• Users can increase the availability of IPs assigned to Services, and clusters can run out of available IPs

This enhancement proposes more scalable, flexible and dynamic logic for services to use and receive IP addresses. 

This capability was introduced in alpha in Kubernetes v1.29.

Conclusion

By and large, the theme of this latest Kubernetes release is impactful iteration on features with security implications, with one big new security feature introduced that will aim to reduce the amount of successful anonymous requests to any endpoint, including the Kubernetes API. To get real-time visibility into your Kubernetes risk posture, schedule a demo today with the RAD Security team!