The Basics of Containerization

Container Technology Architecture
Container Technology Architecture

A container image is a package created and registered by developers that contains all the files, typically organized in layers, required to run in a container. An image typically comprises layers, such as the minimum OS core (aka base layer), application frameworks, and custom code.

Even though a host could directly contact a registry for an image and deploy it into a container, orchestrators such as Kubernetes (K8S), Docker Swarm, Mesos, etc., can automate the deployment process to pull images from registries, deploy them into containers, and manage the container runtimes.

Immutability and Elasticity

As the chickens of the pets, cattle, chickens, and insects analogy, containers are deployed for elasticity, a capability to automatically “scale out and scale in” and “scale up and scale down.”

We take good care of our pets but kill and eat animals like cattle and chickens without regrets. VMs and containers are workloads that can be destroyed, replaced, and added at our discretion anytime. Immutability and stateless are two critical properties for containers to implement elasticity.

Immutability means “unchanging over time or unable to be changed.” (Google) We can think of a container as read-only; the only way to update a container is to replace it with a new one. Stateless means a container won’t retain data in its local storage; however, a remote repository is used to persist and share states across containers.

Most application container technologies implement the concept of immutability. In other words, the containers themselves should be operated as stateless entities that are deployed but not changed. When a running container needs to be upgraded or have its contents changed, it is simply destroyed and replaced with a new container that has the updates.

Source: NIST SP 800-192

Overlay Networks

Overlay networks are commonly used to isolate traffic between nodes. On the contrary, it may result in difficulties for non-container-aware defense tools to monitor traffic.

Segmenting and Grouping Containers

It’s suitable to group containers with the same purpose, sensitivity, and threat posture on a single host in some circumstances. Still, it doesn’t apply to all containers that don’t share the same security requirements.

Only group containers with the same purpose, sensitivity, and threat posture on a single host OS kernel to allow for additional defense in depth.

Segmenting containers by purpose, sensitivity, and threat posture provides additional defense in depth. This segmentation may be provided by using multiple physical servers, but modern hypervisors also provide strong enough isolation to effectively mitigate these risks.

Source: NIST SP 800-192

NIST Application Container Security Guide

NIST recommends organizations should follow these recommendations to help ensure the security of their container technology implementations and usage:

  1. Tailor the organization’s operational culture and technical processes to support the new way of developing, running, and supporting applications made possible by containers.
  2. Use container-specific host OSs instead of general-purpose ones to reduce attack surfaces.
  3. Only group containers with the same purpose, sensitivity, and threat posture on a single host OS kernel to allow for additional defense in depth.
  4. Adopt container-specific vulnerability management tools and processes for images to prevent compromises.
  5. Consider using hardware-based countermeasures to provide a basis for trusted computing.
  6. Use container-aware runtime defense tools.



My new book, The Effective CISSP: Security and Risk Management, helps CISSP aspirants build a solid conceptual security model. It is not only a tutorial for information security but also a study guide for the CISSP exam and an informative reference for security professionals.

1 thought on “The Basics of Containerization

  1. Pingback: 容器化基本概念 – Choson資安大小事

Leave a Reply