I got a lesson today in the idea that it’s always worth re-visiting things you’ve used in the past to see how they’ve changed, as sometimes there will be cool new features!

I was looking at a Kubernetes issue the other day and it led me down a kind of interesting rabbit hole, so I thought it’d be worth sharing as I learned a couple of things.

There’s a new Kubernetes security vulnerability that’s just been disclosed and I thought it was worth taking a look at it, as there’s a couple of interesting aspects to it. CVE-2025-1767 exists in the gitRepo volume type and can allow users who can create pods with gitRepo volumes to get access to any other git repository on the node where the pod is deployed. This is the second recent CVE related to gitRepo volumes, I covered the last one here

For my first post of the year I thought it’d be interesting to look at a lesser known feature of the Kubernetes API server which has some interesting security implications.

Bit of a digression from the network series today, to discuss something I just saw in passing which is an interesting example of a possible sharp corner/foot gun in Kubernetes RBAC.

In my last blog I took a look at some of the different IP addresses that get assigned in a standard Kubernetes cluster, but an obvious follow-on question is, how do pods get those IP addresses?, and to answer that question we need to talk about network plugins.

When getting to grips with Kubernetes one of the more complex concepts to understand is … all the IP addresses! Even looking at a simple cluster setup, you’ll get addresses in multiple different ranges. So this is a quick post to walk through where they’re coming from and what they’re used for.

On Monday this week I noticed a new and really interesting blog from Imre Rad. The Blog Post described an unpatched issue in Kubernetes, which allows any user with the ability to create gitRepo volumes to execute code on the underlying host as the root user! For the details of how this works, please read Imre’s blog as all the cool research is his, I’m just looking at how it might be exploited :)

Debugging facilities can always be interesting for attackers, and in general for security, so I decided to take a look at Kubernetes support for Profiling, and where it could be a risk to cluster security. We’ll start with a little bit of background info.

Kubernetes has got a number of different components, each with it’s own API. Whilst most of the time you’ll interact with the main kube-apiserver API, and sometimes the Kubelet API, the other ones can have some interesting properties. The kube-proxy API is interesting, in that it has some differences from all the others.