Getting into a bind with Kubernetes
Following on from looking at the escalate verb in Kubernetes RBAC, I thought it would be worth looking at another one of the unusual verbs you can see in Kubernetes RBAC, bind.
Following on from looking at the escalate verb in Kubernetes RBAC, I thought it would be worth looking at another one of the unusual verbs you can see in Kubernetes RBAC, bind.
One of the interesting areas of Kubernetes to explore is how it handles networking, and this is a quick post looking at one assumption which can be made about Kubernetes networking and how it doesn’t always hold. Whilst Kubernetes can assign pod IP addresses on the same LAN as the host VM, it’s more normal for the CNI to hand out IP addresses from a separate range, and then implement some kind of overlay networking between the cluster nodes to get traffic from pods on one node, to pods on other nodes. As part of this duty, Kubernetes nodes will often act as routers, so if you can get traffic to the node they’ll happily forward it on.
With the release of Docker 20.10, the rootless containers feature has left experimental status. This is an important step for Docker security as it allows for the entire Docker installation to run with standard user prvivileges, no use of root required. Other container solutions like Podman have had this feature for a while but if your used to Docker’s approach it’s nice to see it being available.
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.