What Are Containers?Before you can really begin to understand how to secure containers, you need to understand what they are and what benefits they provide. At a high level, they are lightweight, self-contained application bundles that include everything you need to run them from the code to the runtime, system tools, system libraries and settings. They’re not virtual machines, though. Unlike VMs, containers share the kernel of the Host OS that they’re running on, so the size of containers can be incredibly small. Also unlike VMs, they start up almost instantly. Finally, because of how lightweight they are, you can spin up many more containers on a Host OS than you would be able to spin up if those same containers were hosted as virtual machines. On a deeper level, containers themselves are instances (running or stopped) of container images that consist of multiple image layers. The bottom layer is usually a parent image layer that includes the OS, such as Ubuntu, CentOS, or Alpine Linux. Each subsequent layer in the image is a set of differences from the layers before it. All image layers are read-only. When you spin up a container, it creates a new writable layer on top of all the layers in the image. Any changes to the running container occur in this layer.
How Do Containers Progress Through Lifecycles at an Organization?Conceptually, the lifecycle is simple. It consists of three phases: build, distribute, and run. As a security admin, you must understand the container lifecycle at your organization and dig into each of these phases at a granular level. You need to identify what is built and how are they built. How are they distributed? How are they run? And what’s the pipeline of tools and components that your containers progress through and are managed by throughout their lifecycles? Examining all of these things will be key to determining what your current container security posture is, so that you can identify gaps and propose changes to existing tools or processes. I would recommend that you sit down and map out the lifecycle for your own organization, including the specific tools and technologies that are used to build, distribute and run them. As a part of my own lifecycle mapping exercise shown below, I’m using a pipeline-based build approach, which means that my container creation, distribution and deployment is automated from the moment the code is checked-in to when it is deployed in production. The blue lines that you see here follow the container through the pipeline. The first step in any container pipeline is going to be the initial code check-in. From there, a continuous integration tool, such as Teamcity or Jenkins, will pull a parent OS image from an image registry, build a new image by adding additional layers on top of it, and then push the image to a production image registry. Once in an image registry, a container orchestrator, such as kubernetes, can pull the image from it and deploy it onto a container host running on my particular platform, such as into an AWS EC2 instance.