Non-Storage Related changes

Kubernetes 1.31 has a lot of changes which aren’t related to storage directly, however are important to note.

AppArmor Support goes GA

AppArmor is a policy based security system for Linux applications. The idea behind AppArmor is similar to SELinux. Which one is used on your Linux system, heavily depends on the distribution. While Red Hat based distributions commonly use SELinux, are Debian or SUSE based distributions on the AppArmor side. Whatever you use, Kubernetes has you covered with support for both, and the AppArmor support just went GA (general availability).

Editor’s note: ** We had Hannes Ullman from bifrost security on our podcast, talking about how to use automatically generated application behavior profiles and AppArmor to secure your Kubernetes hosted application.

Nftables for Kube-Proxy

For a very long time, iptables was the commonly used backend for firewalling in Linux. Since Linux kernel 3.13, its successor, nftables (netfilter), is available. Kubernetes 1.31 adds the necessary backend to interact with nftables, enabling us to use the more modern alternative on our worker nodes.

Cgroups V1 in Maintenance Mode

It’s about time. Linux cgroups (cgroups means control groups) version 1, the basis (together with namespaces ) for all containerization on Linux, was added in 2007. In 2016, its successor, the much more powerful version 2 was added to the Linux kernel. The use of v1 has been on a fast and steady decline, hence the deprecation of the cgroup v1 backend in Kubernetes. While it is not yet removed, moving to the v2-based backend is highly recommended.

Storage Related changes

While there are amazing non-storage changes, I think the storage related changes are the ones that really stand out. Therefore, we want to look into those with a deeper perspective.

Personally, my favorite feature of the release is the removal of over 1.3 million lines of code. Much of it are old storage adapters (in-tree volume plugin) which predated the availability of the Container Storage Interface (Kubernetes CSI).

Persistent Volume last Phase Transition Time goes GA

Before we come to the volume plugins though, there is one other amazing feature, the last phase transition timestamp on persistent volumes (PV). It represents the time when a PV last changed its state (like Pending, Bound, Released, Retain, Delete). Therefore, it provides a generic way to record and find this information. One use of it is alerting, where you could look at the current phase and the PV’s last transition time and alert if the PV stays in a specific state for too long (like the container has been reclaimed but the PV has not).

While available for some time, it finally made the jump to GA and is now considered stable.

Image Volume Support

With the rise of machine learning, artificial intelligence, and LLMs (large language models), providing a fixed data set to containers becomes ever more important. Oftentimes, those data sets or pre-trained models must be made available, best without making them available in the main image though. Either for simpler updates, to reduce the chances of vulnerabilities, or to simplify image creation.

For this use case, Kubernetes 1.31 adds a new VolumeSource type which directly supports OCI (Open Container Initiative) images and artifacts. While Kubernetes has strong support for OCI images, artifacts provide more object types that can influence lifecycle management, the resolution of other artifacts, or add additional validations, security checks, and configurations.

Removal of Vendor-Specific Storage Implementations

As said, much of the removed codebase are old storage provider implementations. At the time of writing, most of the providers are reimplemented as a CSI driver, and offered assisted migration during the last couple of releases.

The few remaining ones will follow soon. That means, going forward, it’ll be much easier to and much more streamlined to use any kind of storage backend, also in a mixed fashion with one pod using one and others using another storage. Storage classes for the win.

Removal of the CephFS Volume Plugin

The CephFS volume plugin was added to the codebase in . Since the release of Kubernetes 1.28 it has been deprecated. At the same time, the CSI driver variant was made available and is the recommended way to use CephFS today.

If you want to understand how to use CephFS, find the CSI driver plugin (ceph-csi) at Github.

Removal of the Ceph RBD Volume Plugin

Just like its brother, the CephFS volume plugin, the in-tree volume plugin for Ceph RBD has been removed. It was likewise marked deprecated in Kubernetes 1.28.

Today, the same CSI driver is used for both, CephFS and Ceph RBD, meaning the same Github repository provides the necessary implementation (ceph-csi).

Previous Deprecations and Removals

In earlier releases, additional in-tree volume plugins were removed from Kubernetes: awsElasticBlockStore was deprecated in 1.19 and removed in 1.27 azureDisk was deprecated in 1.19 and removed in 1.27 azureFile was deprecated in 1.21 and migration to the CSI driver is available cinder was deprecated in 1.11 and removed in 1.26 gcePersistentDisk was deprecated in 1.17 and removed in 1.28 gitRepo was deprecated in 1.11 and shouldn’t be used due to a vulnerability (CVE-2018-11235). Simplyblock is working on helping to remove this volume plugin. glusterfs was deprecated in 1.25 and removed in 1.26 portworxVolume was deprecated in 1.25 and migration to the CSI driver is available vsphereVolume was deprecated in 1.26 and migration to the CSI driver is available.

The Day of the Storage

Kubernetes release 1.31, like always, brings a great set of new features or moving features along their path to general availability. However, the most existing features for the last couple of releases are storage related.

With the introduction of the Container Storage Interface (CSI) to Kubernetes through the SIG Storage group marked the move to seamless integration of external storage engines without the need for a Kubernetes release to integrate them, hence mostly eliminating integration complexity with Kuberentes.

Ever since the CSI adoption has increased as has the feature set, offering more features today than any of the previous in-tree volume plugins provided. And yet, there is more to come.

Due to the large number of CSI drivers and optional features in the CSI specification, our searchable list of CSI drivers provides a quick way to find the storage implementation you need.

If you look for hyper-converged or disaggregated cloud-native storage though, look no further than simplyblock!

Our own CSI driver enables our intelligent storage orchestration, enabling you to combine the best of cloud storage (such as Amazon EBS), object storage (such as Amazon S3), local instance storage, and clustered NVMe storage for your mix of high-performance, low latency, high availability, and capacity. Paired with thin provisioning, copy-on-write clones, encryption, and automatic tiering between all of the above storage backends, simplyblock enables cloud-native storage that decreases cost while increasing the feature set.

The post Kubernetes 1.31: Day of the Storage appeared first on simplyblock.

This interview is part of the simplyblock Cloud Frontier Podcast, available on Youtube, Spotify, iTunes/Apple Podcasts, and our show site.

In this episode of simplyblock’s Cloud Commute podcast, Chris Engelbert sits down with Hannes Ullman, co-founder and CTO of Bifrost Security, to discuss how developers can automatically secure applications using personalized application firewalls. Hannes shares insights into runtime security and how tools like AppArmor and eBPF are used to secure containerized environments, particularly in Kubernetes. If you’re interested in learning about the next generation of security automation, especially for containerized workloads, this episode is packed with valuable takeaways.

Key Takeaways

What is Runtime Security, and how does it Protect Applications in Production?

Runtime security refers to the protection of applications while they are running in production environments. It focuses on detecting and mitigating security threats as they occur during the application’s runtime, rather than pre-runtime testing or post-mortem analysis. This type of security is critical for identifying attacks that exploit vulnerabilities not caught during development or deployment. Runtime security tools monitor the application’s behavior and identify anomalies or suspicious activities, helping to prevent attacks such as privilege escalation or unauthorized access.

How does Bifrost Security Enhance Container Security at Runtime?

Bifrost Security enhances container security by automating the creation of security profiles for each application. Using Linux Security Modules (LSMs) like AppArmor, Bifrost dynamically generates and updates profiles that enforce strict security rules. This ensures that each application can only perform specific actions, reducing the risk of exploits like privilege escalation. Additionally, Bifrost continuously audits the application’s behavior, adjusting profiles based on real-time activities and locking down unexpected behaviors.

What are the Benefits of using AppArmor for Containerized Application Security?

AppArmor is a Linux security module that enforces access control over programs, providing a way to restrict applications to a limited set of actions. When used with containers, AppArmor helps prevent applications from accessing resources or executing commands that they shouldn’t, protecting against various types of attacks. AppArmor profiles can be tailored to fit each container’s specific behavior, providing an extra layer of defense even if a vulnerability is discovered within the application.

In addition to highlighting the key takeaways, it’s essential to provide deeper context and insights that enrich the listener’s understanding of the episode. By offering this added layer of information, we ensure that when you tune in, you’ll have a clearer grasp of the nuances behind the discussion. This approach enhances your engagement with the content and helps shed light on the reasoning and perspective behind the thoughtful questions posed by our host, Chris Engelbert. Ultimately, this allows for a more immersive and insightful listening experience.

Key Learnings

What is EBPF, and how is it used for Auditing and Securing Containerized Environments?

eBPF (extended Berkeley Packet Filter) is a powerful tool for securing containerized environments by enabling real-time monitoring of system calls, network traffic, and application behaviors. eBPF integrates at the kernel level, providing deep visibility into potential security threats while imposing minimal performance overhead.

Simplyblock Insight:

While eBPF focuses on deep auditing at the kernel level, simplyblock complements this by ensuring that data accessed and processed within these environments is securely managed. With scalable, per logical volume encrypted storage, simplyblock allows organizations to store audit logs, telemetry data, and critical information securely and with high availability, helping to maintain the integrity of the entire security workflow.

What are the Security Challenges of Deploying Applications in Containerized Environments?

Containers present unique security challenges, including ensuring proper isolation between workloads, preventing misconfigurations, and managing shared resources. Addressing these challenges involves applying strict security policies, monitoring runtime behavior, and continuously updating security profiles to minimize the risk of attacks.

Simplyblock Insight:

Simplyblock supports secure containerized environments by offering resilient, encrypted storage that integrates seamlessly into container orchestration systems like Kubernetes. This enables organizations to securely manage shared data and configuration files across containers, reducing the risk of data breaches or misconfigurations affecting sensitive information. With simplyblock’s storage solutions, data integrity is maintained, even as applications scale and evolve.

How does Automated Security Profiling Improve Application Security in Kubernetes?

Automated security profiling tools continuously monitor and assess the behavior of applications, creating dynamic security profiles that adapt as applications evolve. This helps to proactively contain threats by restricting applications to approved actions, improving overall security in Kubernetes environments.

Simplyblock Insight:

Simplyblock’s robust storage solutions provide a reliable foundation for securely storing and accessing the outputs of automated security profiling tools. As profiles are generated and updated, simplyblock ensures that the underlying data infrastructure remains secure and accessible, allowing real-time insights and actions to be performed without compromising on performance or security. This reinforces an automated and secure DevOps pipeline, where every layer of the application lifecycle is protected.

Additional Nugget of Information

What is Zero-trust Security, and how does it Apply to Containerized Workloads?

Zero-trust security is a security model that assumes no entity, whether inside or outside a network, should be trusted by default. In containerized workloads, zero-trust principles are applied by ensuring that each container, service, or microservice is only allowed access to the resources it absolutely needs. This involves strict enforcement of network policies, container security profiles, and regular auditing to ensure that no unauthorized actions are taken. By minimizing the surface area of trust, zero-trust security helps reduce the risk of data breaches and unauthorized access.

Conclusion

As containerized applications become the backbone of modern cloud infrastructure, securing them in real-time is more critical than ever. Tools like Bifrost Security, combined with AppArmor and eBPF, offer developers an automated way to monitor, audit, and secure their applications at runtime. By continuously generating and updating security profiles, Bifrost ensures that your applications stay protected from evolving threats without slowing down development cycles.

At simplyblock, we’re committed to providing secure and scalable cloud environments that support cutting-edge tools like Bifrost. Our infrastructure is designed to help businesses protect their applications with real-time monitoring, automated security, and robust defenses against the latest threats.

If you’re ready to take your application security to the next level, be sure to tune in to future episodes of the Cloud Commute podcast for more expert insights!

The post Automatically secure your application with your personal Application Firewall | Hannes Ullman appeared first on simplyblock.