Somewhat following on from my previous post about running containers in non-root environments I’ve been spending some more time reading up on Capabilities, so thought it would be worth making some notes.
As some environments which allow for Docker images to run (e.g. OpenShift Origin’s default setup) don’t allow containers to run as the root user, its worth knowing about other ways to get some networking and security tools run without having to have root.
Anyone who’s used images from Docker Hub will likely have noticed that there can be quite a few old and stale images up there. People will post an image to help them achieve a goal but then might not remember to maintain it, which reduces the usefulness for others over time as software versions get outdated and projects that are incorporated into the image move on. I’m guilty of this myself with quite a few images up on Hub that haven’t been updated since I initially uploaded them.
etcd is a key element of most Kubernetes deployments as it stores the cluster state including items like service tokens, secrets and service configurations.
When you’re doing security testing of container environments one of the things that can be pretty useful is having a container with useful tools connected to the container network. From there you can run network scans of the container network and also test the scenario of “malicious container”
The first release candidate of the new OWASP Top 10 got released last week and one of the changes in particular seems to be generating a lot of comment, so I thought I’d chip in too with some thoughts.
Whilst spending some more time looking at Kubernetes, to help out with the forthcoming CIS Security standard, I was looking at cluster component authentication and noticed something that might not be known by everyone using Kubernetes, so I thought it’d be worth a post.
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.
