Request a demo
Contact Us

Chapter 1

What is Docker?

Docker is a specific format of a Linux container, which provides lightweight virtualization that allows multiple isolated Linux systems running on the same host. Unlike traditional virtualization, which virtualizes the hardware, containers virtualize the operating system.  Multiple running containers that share the same host also share the same host operating system. As such, containers have a lightweight footprint, a minimal overhead, and can enable rapid application deployment.

Docker provides a runtime environment for containers, an API for container management, and a registry format for container sharing. This allows users easily deploy, update, and move workloads. Since then, Docker has become the de facto choice for those building cloud and microservice applications.

Chapter 2

Docker Security Fundamentals

To secure a Docker environment, we must understand security implications of the entire container stack.

Container images and registry: Developers often build container images from open source or third-party software, so managing vulnerabilities in these software layers is an important security consideration for containers.

In addition, you should build container images such that they encapsulate the minimum amount of code necessary to run a single service. Superfluous and risky code, such as SSH, should be eliminated before the image is finalized.

In the container world, images are published and stored in registries. A registry facilitates container content discovery (e.g. search) and distribution (e.g., pull requests). To manage vulnerability effectively, you should scan your container registries frequently to identify and remove vulnerable images.

If you are using private registries, you should harden the servers that host Docker registries. Registry hardening and other image configuration best practices can be found in the CIS Docker benchmark.

Chapter 3

Container Runtime

Aside from eliminating vulnerabilities during the build phase, protecting the container runtime is another critical step to the security of containerized applications. Unfortunately, traditional security monitoring and protection tools do not work effectively for container runtime. More specifically, containerized workloads present these challenges: 

Monitoring challenge:

The minimal and ephemeral nature of containers is a major operational advantage, however, this brings new challenges to Docker security monitoring. Not only must monitoring be done in real time, but also it must be done within the context of a distributed applications stitched together with service APIs. Traditional monitoring tools lack visibilities inside the container, at the API level, and struggle to keep up with the rapid deployment rate of container workloads.

Isolation challenge:

Containers on the same host share the underlying operating system. This means that if one of the containers is compromised, there is a distinct likelihood that the container can impact others via the shared OS. This is commonly known as the “blast radius” problem of running containers.

Response challenge:

After you detect something is wrong, correcting the behavior, or in other words, “responding to the incident,” may not be a runtime-only proposition. For instance, taking down a compromised container would require the composition and deployment of a new image. This is a dev-to-production task that necessitates the integration of CI/CD pipelines with runtime detection and response.

Despite these challenges, the use of Docker containers also brings benefits to security. Three fundamental traits of containers -- immutable, minimalistic, and declarative -- help immensely with runtime protection.


Ensures that a Docker image, once created, does not change. A running container, as an instantiation of the image, can be stopped or replaced, but rarely updated dynamically. This provides greater version control and rollback, cleaner updates and more manageable and intentional changes.


A Docker container should contain the minimal amount of code necessary to perform a single-purpose service. A minimal container allows rapid delivery, continuous integration and deployment. From a security point of view, a minimal container may allow you to quickly build a baseline profile, which you can use to perform anomaly detection and enforce security policies in runtime.


Docker forces developers to statically declare certain runtime behaviors that the container must adhere to, such as which ports should be open, which versions of the base image it should run, etc. Being declarative means that you can derive security policies automatically from the declarative profile, a capability that gives rise to manageable policies and more predictable outcomes.

Want to reference this later? Download this page as a PDF!

Chapter 4

The Orchestrator

The orchestrator is the engine that keeps all the components of a container environment working together and running smoothly. Popular container orchestrators include Kubernetes, Docker Swarm, and Openshift. Because of the orchestrator’s unique position in the operational environment, it is an important integration point for security controls. Not only can the orchestrator deploy security tools alongside the workload to be protected, but also orchestrators, like Kubernetes, come with built-in security plugins that you can configure to enforce certain security policies.  

For instance, Kubernetes provides an “Admission Control” plugin, which is used to specify granular access control policies that go beyond identities, resources, operations and namespaces. A request to the Kubernetes API server can only proceed when all the admission controllers pass it.

Another important plugin is “NetworkPolicy.” NetworkPolicy is a construct you can use to provide network isolation. By imposing restrictions on who can talk to whom, an administrator can reduce the system attack surface and improve the cluster's security posture.

For more information on Kubernetes security, the New Stack has an excellent guide on the subject.

Chapter 5

Host and Operation System

To run containers in a secure fashion, the layers underneath the container engine, namely the host (physical or the VM) and the operating system, must be properly configured and secured. This is because a compromise at the host level can disrupt Docker security controls in the higher levels of the container stack.

For the most part, the practices that you follow to harden and secure Linux hosts and Linux OS by and large apply in the container environment. There are, however, a few important considerations to keep in mind for hardening the host environment for container operations:

1. Enable relevant kernel-level security controls: Kernel level functions like SELinux or Seccomp are useful utilities that help to limit the attack surface on the node. They also provide meaningful controls to secure process groups like containers.

2. Limit direct access to host resources: Restrict accounts that have direct access to the container hosts, limiting all but essential services from the hosts. Also, wherever possible, force all access to nodes via the orchestrator. These are some of the important practices you can follow to minimize the attack surface of the host and help reduce risk for unauthorized access to host resources.

3. Secure all node-level communications: Use TLS certificates to ensure all critical API access points are secured with end-to-end TLS.

Chapter 6

Securing Docker Environments

Docker and the container movement are changing the way organizations build, maintain, and deliver services. There are also fundamental implications to the software supply chain, economics, and how we collaborate to bring software to market. In order to better manage Docker security for your environment, organizations should follow these high-level principles:

1. Automation is key: Because containers are ephemeral workloads, manual security tasks are simply ill-suited to keep up. Monitoring, detection, and response all have to be automatic, at scale, and deliver high fidelity results. 

2. Full stack visibility and detection: As we discussed above, you need to properly configure and protect each layer in the container stack. This includes the underlying hardware, the operating system, the VM, the container, and the application. It is not enough to simply focus on the “container” and ignore the other infrastructure components that support the container computing. 

3. Remember “shift left”: Protecting container workloads is well and good, but your security posture would not be complete if the application encapsulated in the container is vulnerable. The shift-left principles of designing and developing secure code apply here. In fact, one might argue that shift-left is more important in the container world as containers promote a higher degree of software reuse. 

4. Follow industry best practices: Best practice recommendations, such as CIS Docker and Kubernetes Benchmarks, should give you a good baseline to properly configure and harden the environment that run containers. 

Docker and containers bring true platform independence, agility, and flexibility to running applications. As the industry moves toward microservices, containers, and cloud-native environments, container and Docker security will be taking on an increasingly prominent position in an organization’s security posture.

About Capsule8: Capsule8 is the industry’s only real-time, zero-day attack detection platform capable of scaling to massive production deployments. Capsule8 delivers continuous security across your entire production environment — containerized, virtualized and bare metal — to detect and disrupt attacks as they happen.


Want to reference this later? Download this page as a PDF!