A software container is basically a lightweight virtual machine. Rather than running an entire operating system, it runs a single application and its dependencies (processes the application depends on). The combination of the container and its application is called a container image—a standalone executable package that possesses everything it needs to run: code, runtime, system libraries and tools, and settings. Containers have been around since the early 2000s, but were not popular until applications like Docker made containers accessible for enterprise use. Unlike traditional virtual machines, containers do not rely on a separate hypervisor layer. Instead, they are directly supported by the underlying operating system, sharing the same kernel (core part of the operating system) and some binaries and code libraries as the host. This means their resource needs are minimal. The container is only a few megabytes in size and takes only seconds to start, as opposed to a few minutes as required by a virtual machine. The same amount of hardware on a host computer can support exponentially more containers than VMs. Containers are also highly transportable. They will behave the same way regardless of the platform that hosts them.

With all the conveniences containers bring to enterprise DevOps (developer/operations teams), they also introduce new security risks. Containers make it easy to package and distribute an application, but they don't provide the same level of isolation as a virtual machine. Many network and security administrators are not even aware that containers have been deployed on their network. As with any software, not all container images available on the Internet can be trusted. Lack of visibility into a container makes it harder to observe and manage. Additionally, there is no guarantee that all components included in a container are patched and up-to-date.

Common container security issues include:

  • Kernel exploits—since a container shares the OS kernel, any instability could cause a kernel panic and crash the host.
  • Denial-of-Service attacks—if a container monopolizes shared resources, it could starve out other containers or the host itself.
  • Container breakouts—if the application contains a bug that allows privilege escalation, malware could escape the container and attack other containers or the host.
  • Poisoned or malicious images—if an attacker tricks you into launching a malicious image, or can swap out your good image with a malicious one, your host and data are at risk.
  • Compromised credentials and keys—when a container needs to access a database or service, it will require a secret such as an API key or user name and password to authenticate. If an attacker can intercept the secret or extract it from the image, then they too will be able to access the service.

Note: For more information about container security, see NIST Special Publication 800-190 "Application Container Security Guide" at https://doi.org/10.6028/NIST.SP.800-190