Container Camp in review – Part 1

For those of you who follow me on other social media platforms, it will be of no surprise that I had the fortunate opportunity to attend Container Camp Australia this year.

Previously, I never the pleasure to experience a technical conference in my professional career. At most, I’ve been to meetups and user group events such as VMUG. Safe to say, I was pretty pumped.

Enough of that though, the real question is, what is Container Camp?

Do you eat, breathe and sleep Docker? Are you looking to abstract away your infrastructure so your developers can just focus on their application code? Like to hear war stories from the front lines of digital transformation using technologies such as Kubernetes? Or are you absolutely bamboozled by the endless technical buzzwords and jargon in the brave new world of DevOps and SRE?

This is the 2 day technical conference for you!

Over the 2 days, the wide and varying levels of talks, discussions and demonstrations afforded me to absorb a considerable amount of information, not just about Containers but Developer and Operations workflows in use by modern workplaces (and how some archaic organisations transformed themselves into modern workplaces). I’ve tried to pick out, in no particular order, a couple of key takeaways that resonated with me during the conference.

Always use User Namespaces

As part of Aleksa (@lordcyphar) from SUSE Australia’s talk that focused on securing container runtimes (and who better than a maintainer of runc and the OCI specifications).

Namespaces in the Linux world are partitions or logical fences around resources on a host. These resources range from access on the file system, time on the CPU, area of Memory etc… The are used to put barriers in place to prevent processes running away with your host and potentially taking it over.

User Namespaces focus on (you guessed it…) user partitions by mapping a user for a particular process, or in the case of this topic, a container to a user of no or less privilege on the host. This is particular important to mitigate privilege escalation attacks where by the an attacker has gained access to the root user (potentially your application within the container requires it). Once free from the container bounds, because we have mapped the user to one of less or no privilege on the host, they are dead in their tracks.

One particular humorous anecdote for me personally in this talk was when Aleksa projected this for everyone to see:

slide source: cyphar’s github

As I came to understand and become more familiar with Linux. One of the greatest pleasures of working with Linux versus my Windows daily driving is everything is represented as a file. No objects, registry etc… just plain, good ol, text file. Apparently, this is also very bad for security, specifically, how quickly an attack can spread it seems…Look at all those CVEs!

In the next three posts, we are going to dive into Service Meshes, their reason for being and which one is for you.

James Written by:

Be First to Comment

Helpful? Have a question on the above?