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.
Recently several new CVEs in the ingress nginx controller for Kubernetes were announced. I thought I’d take a closer look at one of them, CVE-2023-5044. Whilst there’s some details in the CVE announcement and some hints in a post from the CVE reporter here there’s not any actual PoC that I could find, so I decided to see if I could write one!
One of the truisms of container security is that when a container is run as privileged (in the sense of the Docker flag, not just running as the root user) it’s insecure and possible to break out. However, there aren’t always great examples of how to break out of a privileged container in practice.
I’ve been thinking about a project where I could travel to conferences with hardware to run a workshop that doesn’t rely on cloud resources (to avoid those concerns about network access or cloud uptime) and of course, the first part of any project like that is the fun part, buying the hardware! As I’d promised a review to a couple of people on-line, here it is.
