If you’re involved in Information Technology in one form or another that you have at least heard of the newest trend in containerization, Docker. This excerpt, taken directly from Docker’s own docs explain it in a nutshell pretty well:
"Docker provides the ability to package and run an application in a loosely isolated environment called a container. The isolation and security allow you to run many containers simultaneously on a given host."
This notion of “containers” and “containerization” isn’t new; Docker’s approach borrows heavily from Linux’s LXC and LXD hypervisors and from BSD’s “jails” before those. Each of these softwares seek to solve a specific problem: how can more than one application be ran on a single host while disallowing access to other users’ data on disk and in memory? BSD’s “jail” solution used the *Nix native command, chroot to ensure that any jailed processes were started with access only to those folders which were subfolders of that mounted folder and allowed for mounting file systems via ZFS. Linux’s LXC was the first system to introduce the idea of kernel based user space isolation to the concept of containerization, offering arguably even more “secure” container virtualization. LXD improved upon LXC by adding features which made it easier to move containers from one host to another if so required.
Docker was the first to introduce the concept of portability as a core part of its offering in the containerization space. Docker containers are built based on instructions contained inside a Dockerfile, and can be reliably and predictably rebuilt on any computer to produce the same resulting container image. This idea of portability made it possible to decouple build processes from deploy processes and reduced the time required to update Dockerized applications to the time it takes a container to be replaced. This has lead to a rise in containerized applications, which no longer require hours of patches across multiple servers whenever package updates must be installed on each running application’s environment, as this can all be accomplished once in a single Dockerfile and deployed to multiple servers at once, in no time at all.
This rise in containerization also allowed distributed computing systems like Kubernetes to flourish. A 2019 survey from the Cloud Native Computing Foundation found that 84% of respondents were using containers for their production workloads in one way or another. First released to the open source community in 2014 by Google, Kubernetes allows users to define clusters of nodes which can scale from one to many applications with very little code changes required. Using these clusters, users can run any type of workloads they desire, from simple “Hello World” applications, up to complex sets of interdependent containers with ease. Kubernetes has become so successful as a container orchestration framework that the leading cloud infrastructure providers (Amazon Web Services, Google Cloud, and Azure) now offer managed Kubernetes as a Service products so that companies can focus on writing code to run on top of Kubernetes instead of maintaining the Kubernetes infrastructure themselves.
As containerization has changed the internet’s landscape, one would be wise to stop and ask how this changes the attack surface for these applications. As this technology has matured, numerous vulnerabilities have been found which affect Kubernetes directly and can lead to compromise of these often mission critical systems. StackRox maintains a list of five of the most well-known Kubernetes vulnerabilities discovered in in 2019, which is a great way to understand the myriad of ways such a technology can be attacked and compromised. Another great resource for learning more about Kubernetes security is the “Bust-A-Kube” series from InGuardians, which details, step by step, how to attack a Kubernetes cluster.
Kubernetes configuration is HARD. I would know; I work on an open source product called Lagoon in my day job, which helps to make the process of deploying onto Kubernetes significantly more painless for application developers. If you are interested in going down the path of containerizing your production workloads, I would highly recommend ensuring you know what you’re getting yourself into with regards to the possible security quandaries you might face along the way. Here there be dragons!
Stay safe out there!
— cdchris12