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.
One of the features of Kubernetes security, is its flexible model. This allows cluster operators to have multiple Authentication or Authorization modes running covering a number of use cases. This does introduce some complexity though both in terms of operation and also in terms of reviewing or auditing rights.
I’ve written before about how there’s lots of innovative uses for Tailscale and I was playing with another scenario for my Cloud Native Rejekts talk (Video Recording here ), so I thought it’d be worth writing up as I learned some things along the way!
This year, I’ve started looking at how observability can work well for security and as part of that I’ve been investigating Open Telemetry, to understand more about how it works.
I came across an interesting change in how Kubeadm based clusters handle initial credential setup in Kubernetes 1.29 and later, so thought it was worth a quick post. Smarticu5 had a really unusual error, which was that on a newly created Kubeadm cluster he was getting a forbidden error when using the default admin.conf credential created by Kubeadm.
