Forthcoming features (and removals) in Kubernetes 1.25

Every Wednesday, Nick Chase and Eric Gregory from Mirantis go over the week’s cloud native and industry news on the Radio Cloud Native podcast.

This week they discussed:

• Forthcoming features (and removals) in Kubernetes 1.25

• GitLab mulls and reverses plans for deleting inactive repositories

• A social engineering cyber-attack on Twilio

• And more on the podcast, including pending incident reporting regulation from CISA and the SEC

You can download the podcast from Apple Podcasts, Spotify, or wherever you get your podcasts. If you'd like to tune into the next show live, follow Mirantis on LinkedIn to receive our announcement of the next broadcast.

Kubernetes 1.25 is set to drop in about two weeks, on August 23rd, so now’s not a bad time to look ahead at some forthcoming features—and forthcoming removals. 

Version 1.25 marks a big milestone with cgroup v2 support hitting general availability. cgroups are a key functionality of the Linux kernel that underlies containers and container orchestration–they’re the mechanism by which processes are organized and apportioned resources in a configurable way. Most of our core cloud native technologies were built on cgroup v1, but after the release of cgroup v2 in 2016, we’re just now hitting the point where you can use v2 with Kubernetes in production.

The expanded flexibility of cgroups v2 opens up some new options for Kubernetes users, including, notably, running non-root Kubernetes components and more easily running rootless containers. Those are some essential capabilities for security purposes, so it’ll be great to have those ready to utilize in production in a reliable and relatively straightforward way. 

cgroups v2 also allow for full implementation of eBPF, or extended Berkeley packet filter, the kernel functionality that sits behind technology like Cilium. So with cgroups v2 enabled, you can use the full capabilities of Cilium, like replacing kube-proxy to facilitate more performant networking and add load balancing.

So, cgroup v2 is a big deal all by itself. Also hitting general availability are ephemeral containers. This is a type of container intended for debugging rather than running applications—an ephemeral container isn’t tied to the lifecycle of their Pod, won’t restart automatically, and doesn't have any guarantees of resource availability. It’s like a little maintenance ghost flitting into a Pod to troubleshoot. Ephemeral containers can be particularly useful when you’re using minimal images without shells, which is often sensible for speed and security, but can hamper you a bit in debugging. We’ve had the feature for a while, but now it’s ready for prime time.

Hitting alpha is a new ability to implement user namespaces within Pods. This is distinct from the cluster namespaces used by Kubernetes—instead, these are Linux namespaces applied at the Pod level. The main goal here is to provide an additional level of isolation between the Pod and the host, with an eye toward security and vulnerabilities associated with container and Pod escape. With user namespaces, a process in a Pod can have a different user or group ID than the process running on the node—on the host. That process might have full privileges on the Pod, within the user namespace, but if it escapes out onto the host, it will only have limited privileges there. That can really mitigate a lot of existing vulnerabilities. So, while this feature is just in alpha, it’s set to give us a way to add an extra layer of security to Pods that need to be highly privileged.

The last big 1.25 item to discuss today isn’t a new feature or graduation, but a removal: the PodSecurityPolicy API will be gone as of Kubernetes 1.25, after being deprecated back in 1.21. PodSecurityPolicy was meant to provide a way to define rules for a set of pods’ capabilities, but ultimately a lot of folks found that it was too confusing and encouraged overly broad defaults. Now it’s being replaced with the Pod Security Admission controller, so anyone still using PodSecurityPolicy will want to migrate. The Kubernetes docs include some good instructions for migrating; you can check those out here.

Last week, GitLab reportedly mulled and then promptly scrapped plans to delete repositories that had been inactive for a year. 

The Register broke the story of the company’s initial plans to remove inactive repos, reporting that these quiet repositories account for about a quarter of GitLab’s hosting costs, at a value of about $1 million per year. So, you can see why they might be interested in sloughing off those costs. Under the proposed policy, users would have been given warning of “weeks or months” before deletion, and activity such as comments, commits, or new issues would have been sufficient to reset the twelve-month countdown clock.

Once revealed by The Register, apparently based on sources and documents from within the company, the plan met with outcry from users. Some noted that many open source projects reach a state of completion—they do what they need to do without issues, and might be widely or sporadically used but occupy an important position in the open source ecosystem, perhaps a pivotal position as a dependency for something else. Within a day, and reportedly on account of online outrage, GitLab reversed course, stating in a tweet that they would instead develop a system to archive less frequently used repos to object storage. The details of the new plan are still unclear and presumably still in flux, given the swift about-face last week.

This story comes amid wider upheaval in the git repository hosting landscape. GitHub Copilot’s utilization of user code for AI-based code recommendations has rankled some users, and signaled Microsoft’s willingness to experiment with the platform and its data in the interest of monetization. GitLab is clearly looking at ways to reduce costs. And all this demonstrates that massive volumes of open source work are sitting on edifices of free tier hosting that aren’t going to just sit there unchanged forever.

One thing you can depend on continuing into eternity: cyber-attacks. This month Twilio disclosed that they suffered a social engineering attack that gained access to employee and customer accounts.

The attack used text messages to employees, matching names to phone numbers, and prompting those employees to “change their login information” with malicious links. Curiously, Twilio alludes to unspecified other companies being affected by similar attacks, but we’ve seen no similar disclosures from other organizations as of yet.

Twilio says they’ve contacted customers who may have had information compromised, but the takeaway here is universal—social engineering attacks can be pretty sophisticated, sometimes using personal information you might not expect, so individuals need to be skeptical and cautious, and organizations need to issue very specific guidance about the kinds of communications they will send.

Check out the podcast for more of this week's stories.