There’s a number of steps needed to get all this setup properly, but at the end of it you should be able to run Linux and Windows containers on a Windows host from WSL bash…
Kubernetes network policies are a useful security feature which allow for traffic into and (sometimes) out of pods to be restricted.
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.
