Based on the Kubernetes security reviews I’ve done, one of the most problematic areas for clusters is user authentication. Whilst Kubernetes provides a wide range of options, it lacks the “traditional” user database that you might expect to see with a multi-user networked system. Using external OIDC or webhook providers is often complex, so many clusters make use of the in-built authentication options which are :-
One of the key elements of the success of Docker is the availability of Docker Hub, which provides an effective “app store” of pre-build Docker images with a huge variety of pre-installed software. Everything from Databases, to CRM software to hacking tools is easily available at the drop of a docker run command.
Following on from looking at katacontainers and gVisor, I thought it might be interesting to look at the containerd project and the idea of using containerd and runc without docker to run containers. Looking round the documentation, I couldn’t find a good look at getting containerd and runc setup together without installing Docker, so lets do that.
This is the second part of a series, taking a brief look at some alternate container runtimes, which can be used with Docker and Kubernetes, the first part is here.
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.
