Following on from the last post in this series lets setup a rather more ambitious set of reverse shells when attacking a Kubernetes cluster.
A handy technique for any pentester is the ability to create a reverse shell. This allows for a variety of cases where you want to get access to restricted environments or want to extract information from a remote system.
I’ve been looking for a way to explain an demonstrate the “no-new-privileges” option in Docker for a little while for my training course and recently came up with a way that should work, so thought it was worth a blog post.
Coming up for 4 years ago (a lifetime in Container land) Ian Miell wrote about “The most pointless Docker Command Ever”. This was a docker command that you could run and it would return you back as root on your host.
One of the common tasks in a containerized environment, where you could be running multiple applications in containers on a single host, is “what’s the best way to route traffic to my web applications”?
One of the great things about the Kubernetes ecosystem is all the new projects that come out on a regular basis to help do various things (keeping up with them can be a challenge, of course).
After a little delay Docker 18.09 got it’s final release this week. This is a release I’ve been looking forward to for a while now, as it’s got a couple of cool new features, which should help in day-to-day usage of Docker.
I came across a very interesting post this morning on using Play With Docker (PWD) to let people try out applications directly from your GitHub repository. If you’ve not tried out Play With Docker before (or it’s companion site, Play with Kubernetes), they’re very useful resources which let you try things out in disposable Docker and Kubernetes environments. Handy for training courses amongst other things.
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 :-
