As part of some talks I did for the recent NCC Con, I started looking at the gVisor project from Google (nothing like having to write a presentation to provide motivation!).
Yesterday I noticed a tweet from Derek Abdine about the Rapid7 OpenData collections which are free to access datasets of various types, so thought I’d have a quick look at something I’ve been meaning to for a while, information disclosed via SSL certificates in Internet facing Kubernetes clusters.
A common task in any security review, is auditing user access control, as excessive numbers of privileged users are a common theme, and privileged access a common point of attack.
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”
