So following on from my post about the kube-exploit, I thought it would be interesting to look more at the attack surface of my sample Kubernetes cluster from the perspective of a Rogue container. The setup follows the same path as the last post and I’m running from a kali linux container running on my cluster, to simulate an attacker who has compromised a single container on a cluster.
I’ve been reading up on Kubernetes a bit recently and Jesse Hertz pointed me at an interesting item around Kubernetes security that illustrates common problem of insecure defaults, so I thought it might be worth a post walking through the issue, mainly as a way for me to improve my Kubernetes knowledge but also could be useful for others who are deploying it.
Another new cool facet of the 1.12 release of Docker Engine is that Macvlan and Ipvlan support is leaving experimental and is available for all users. So now instead of the rather convoluted procedure I mentioned last time I looked at this we can now simplify the setup of containers attached to the same network as the host, removing the need for NAT translation from the container network to the host network.
It’s Dockercon time of year again, and of course you know what that means… loads of cool new features coming to the Docker ecosystem. I’ve been (enviously) watching all the action remotely on twitter and various blogs and one of the features that jumped out at me was the new swarm mode for Docker engine. The idea of providing very easy to use clustering features for containerization is of course very attractive, but there are possible security concerns, both with encryption of traffic amongst swarm nodes and authentication/authorisation for systems joining the cluster.
One of the things that you get used to after using Burp for a while is that if there’s any area that it doesn’t have native functionality for, it’s possible to use Extender to code up your own. I had cause to do a bit of this recently and as with the previous time I looked at this (for passive scanner checks) there were some gaps in the documentation for doing this with JRuby, so I thought I’d write it up.
I’ve been presenting a bit recently on docker and in an attempt to keep my presentation environment relatively simple, I decided to move off from using prezi which doesn’t have a linux client to something a bit more platform agnostic.
Since my last post on this there have been quite a few conversations had on twitter and we’ve now got Kenna’s blog post with additional details on their methodology.
So it’s Verizon DBIR time of year again and as with last year there seems to be a little bit of debate around the Top 10 exploited CVEs. My twitter handle got copied in via some tweets from last year, so I thought I’d take the opportunity of providing a tester’s perspective on this. A more detailed and comprehensive look at this issue is available on the OSVDB Blog.
One of the things about Docker is that whilst it provides you with a sane set of defaults from a security persective, it’s still pretty easy to quickly reduce the level of security/isolation provided if you deviate from those defaults without understanding the consequences.
Along with the new version of Docker Engine which came out recently there were some handy updates to Docker Compose. Back when I started looking at using compose and Docker containers for pen testing one of the drawbacks was that there was no great way to define a shared area for all the containers to save their data to as part of the compose setup.
