Docker containers have become very important tools in developers’ toolboxes, and the technology has become very well accepted. To date, Docker has been downloaded more than 2 billion times, a jump from 300 million downloads in April 2015. Organizations that are just beginning to use this technology, and companies that have been working on it for some time, are the source of this rapidly growing deployment.
Containers allow you to build complex applications from smaller structural units, each of which performs a single function. This architecture, also known as microservices, is ideal for continuous deployment of systems, where components of a microservice can be upgraded online without affecting other services.
But this growing tide has many enterprise security experts worried, and Dan Walsh from Red Hat has written some very good articles about why containers don’t hold. Although containers provide the isolation of system resources such as memory and CPU, all containers running on the same host share an operating system, and security problems in one container are likely to affect other containers through the shared kernel.
While these concerns are legitimate, they are manageable. Let’s take a look at how the Docker container’s inherent structure can be used to protect containerized applications.
Docker containers are built from static images, which are composed of different layers. These layers can be reused by different images. For example, the base layer of Ubuntu can appear in the NGNIX container as well as in the Mongo DB container.
When a container image is instantiated, it becomes a container. In a Docker container, these layers form a unified container file system. Each layer is instantiated as read-only, and there is a read-write layer on it to keep track of changes made to the file system while the container is running.
When a container exits, if the user does not perform “Docker Commit”, the read-write layer disappears, no state changes are recorded, and the image remains unchanged. If the user executes “Docker Commit”, the read/write layer will be added to the original image and a new image will be created. With this approach, each “Docker-commit” records successive changes and changes in container state in a controlled incremental manner. Not only can you easily fall back to a previous state, but this is also useful for traceability, manageability, and authentication.
This explicit restriction of state changes to the read-write layer is a very useful feature for security. First, this ensures that most of the code runs in read-only mode, which means that any bad conditions during the run won’t persist unless you explicitly commit the changes. Second, it gives you a chance to focus on monitoring the read-write layer.
However, one of the most important aspects of stateless containers is that it is easier for users to get a baseline behavior model of the container, and if the observed runtime behavior differs from the baseline, you know that there is a potential problem.
This solves the biggest problem in risk and anomaly detection, which is developing a useful baseline to identify “normal.” Once you have such a baseline and can detect exceptions properly, you can make your container capable of controlling and defending against potential attacks.
The Docker container provides the ability to run most applications in read-only mode and isolate state changes into a manageable module. This opens up opportunities for security innovation, but it requires you to delve deeper and take advantage of the inherent characteristics of the container architecture.
One digital-media company did just that, running many of its services in the cloud for consumers and business users. The development team started using Docker a year ago, and the company now runs most of its services inside Docker.
The security team conducted security checks on all container images and successfully removed poorly constructed images that violated company policy. Next, they made a rule that the container should run read-only. Only exceptional applications can commit runtime changes, and these applications are carefully documented and traced.
The company is on a journey to transform its application into a microservice and container, and their experience so far, in addition to being a more efficient application architecture, has convinced the security team that this new architecture will prepare them for future changes and make problems easier to detect and deal with.
This article is a translated version of the original article.
View pictures View pictures
