Containers are a Dev-ops dream come true, but they could become a nightmare if not properly secured as from a security perspective they are another potential exposure with some unique risks. That said, the job of security is to minimize risks while enabling the business. So let’s look briefly into what to be concerned with when securing containers.

Let’s start at the basics; what is a container? A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another. A container image is a lightweight, standalone, executable package of software that includes everything needed to run an application (code, runtime, system tools, system libraries and settings).

What are the major areas we need to be concerned with when securing containers? There are basically three phases or processes that are of concern:

  1. The build process
  2. The container contents.
  3. The runtime process. Each of these processes or states could be a whole article in and of itself but let’s hit the highlights of each.

The build process:  This has become the area where attackers see the most value. If they can get into this process and insert their own malicious code it gets the most bang for their buck. It’s critical to secure the perimeter of this area, which is highly likely to be a cloud environment. Then the code itself should be subject to static and dynamic code review before it is pushed to production. This is highly undesirable to developers who will argue that one of the values of containers is rapid deployment. It’s up to us to provide the ability to only be a speed bump not a road closure, because this review is critical to secure operations.

The container contents: Once deployed, we need to make sure the container is free of vulnerabilities and things such as unneeded libraries. Most of us from the infrastructure world understand the concept of hardening. The act of configuring an OS securely, updating it, creating rules and policies to help govern the system in a secure manner, and removing unnecessary applications and services. This is done to minimize a computer OS’s exposure to threats and to mitigate possible risk. We must harden our containers for the very same reasons. Many container vendors give us some tools to do this, and there are third parties with tools that go even further but of course, we must utilize these things to be effective. Finally digitally signing a container, creating a cryptographic digest of all image contents, and then tracking them though your container lifecycle ensures that no unapproved images run in your environment.

The runtime process:  This includes making sure the environment where the container runs is hardened. Also, much like infrastructure, the more you can segregate your workloads the harder it will be for any one compromise to be a full compromise. Resource isolation is critical. Limit container access to underlying operating system resources, particularly to prevent a container from stealing data from other containers.

This post demonstrates just a few high-level challenges of container security. As with anything within your it ecosystem, containers are great, but risks need to be managed. Your comprehensive  security plan should include specific container security processes in order to make the best and most secure use of containers.