Following a recent run of the container security training course I do, I was poking around a bit with the escalate verb in Kubernetes RBAC and found some interesting points, so thought it’d be worth documenting, as it’s not necessarily the best known part of RBAC.

When looking at an AKS cluster recently, I came across some unusual default behaviour, which I thought deserved some more investigation over the weekend. Seems like AKS is making some … interesting… choices with regards to user authentication, in some setups.

Over the last couple of months I’ve been looking at container vulnerability scanning a bit (some more info here), and there was one behaviour I noticed that’s probably worth commenting on, as it can be a bit unexpected, and that’s the handling of unfixed vulnerbilities.

Vulnerability Assessment is one of those foundational IT Security tasks that often gets overlooked or thought to be reasonably straightforward, where you can actually find some interesting complications that make it trickier than expected.

Introduction

Introduction

Introduction

Discovery

This is a neat trick which could be useful when troubleshooting Kubernetes services or testing Kubernetes clusters. This got used in a TGIK episode a while back and I’ve been meaning to test it and write it up for a while, as I’ve not seen many docs on it.

I’ve been starting to have a look at podman recently and in doing so, I noticed something potentially interesting from a security perspective, which is how podman handles the pulling of new container images. As podman is billed as a “drop-in” replacement for Docker (and indeed provides a package to alias docker commands to their podman equivalents), it’s interesting to note how default settings might differ, as these differences could trip up unsuspecting users moving from Docker to podman.