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:
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.
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.
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.