What is a container?

A container is a unit of software that holds the necessary components — code, runtime, system tools, system libraries, and software dependencies, among others — for an application to run easily across different computing environments, i.e., any computer hardware, infrastructure, or cloud environment. By using a container, the amount of IT labor and resources required for application infrastructure management is drastically reduced.

Typically, getting software to run from one computing environment to another can be problematic. For example, challenges arise when the supporting software environments are not the same. Containers solve this by bundling all components into one package. Now, the differences in operating system distributions and underlying infrastructure are more a matter of detail than a practical hindrance due to the containerization of the application platform and its dependencies.

What is a container image?

A container image is an unalterable and static file that includes executable code to allow the running of an isolated process on IT infrastructure. An image consists of system libraries, system tools, and other platform settings that are requisites for a software program to run on a containerization platform and shares the OS kernel of its host machine. In essence, an image is needed to build a running container.

A container image is compiled from file system layers built onto a modified or a completely new image. An image can be built from scratch using the build command of a container platform and can be updated over time to fix bugs, introduce more functionalities, or change the product completely. It can also be modified and be used as basis for a new container.

How to secure containers

Secure containers by identifying flaws in its components

Containers use images to spin or run applications. A vulnerable image means a container at risk of malware infection or hacking, and in turn, the application can also be at risk. Identifying security flaws pre-runtime and fixing them before the image is scheduled in an orchestration environment can significantly save time and effort in terms of reworking builds. It can also reduce overhead and disruptions in the application’s lifecycle. Here are some conditions for ensuring a secure container:

  • The container images should be signed, authenticated, and drawn from a trusted registry. When scanning images, scanning the registries should be considered as well since registries can also become susceptible to compromise and their images can be tampered with.
  • The daemon should be secured. Access to it should be restricted. In addition, encrypted communication protocols should be employed when exposing it in the network.
  • The principle of least privilege should be enforced. Any user, service, or application with access to the container’s root account can get into other containers sharing the kernel. Minimizing access minimizes unauthorized risk.
  • Resources should be isolated. Properly configure control groups and namespaces, that is, what resources and how much a container is allowed to use.
  • To further reduce the need for extra builds, security should be baked in. For example, Docker has documentation on the built-in security features of its container engine.