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!

Well, all good things must come to an end. Over the last couple of years I’ve been using the Censys API to track the number of Kubernetes clusters exposed to the internet which disclose their version number, and I’ve written about it a couple of times here and here

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.

As part of the preparations for the workshop on container security that myself and Iain Smart ran at this year’s Steelcon, there were some concerns that our standard option of SSH access might be blocked by the venue’s Wi-Fi, so a backup plan was in order. As a result, we were looking into how to provide a browser based terminal for students running on a host in AWS EC2.

At Last week’s Kubecon EU I was fortunate enough to be on stage with Ian Coldwater, Brad Geesaman, and Duffie Cooley presenting a talk called “Malicious Compliance: Reflections on Trusting Container Scanners”.