Run the Docker container safely in a production environment

  • 2020-06-01 11:22:40
  • OfStack

One way to strengthen Docker containers in a production environment is to make them immutable, that is, read-only. Other ways to run containers safely include minimizing the attack surface and applying Linux security procedures, both the standard Linux security procedures and specific procedures for the container environment.

Pass in the -- read-only flag when you start the container to run it in read-only mode. This prevents any process from writing to the file system. Any attempt to write will result in an error. Running this immutable infrastructure also dovetailed with best practices for other software deployment pipelines.

Although immutability can prevent the execution of any malicious scripts, it can prevent changes caused by vulnerabilities exposed by other software running in the container. But does this pattern apply to applications in real-world production environments? For example, the log files to be generated and the applications to use the database require writability.

One possible solution to logging could be to use a centralized logging system, such as Elasticsearch/Logstash/Kibana (ELK), so that all logs are collected on a central node, possibly in another container, and are not directly accessible to the user. Another alternative is to export the logs out of the container using the -- log-driver flag when the container is started. For applications that require write access to temporary directories such as /tmp, one solution is to load a temporary file system in the container for these directories.

The end user does not have direct access to the database, so the risk is low. However, this does not rule out attacks unless the user-facing application is enhanced.

In cases where a writable file system is inevitable, Docker provides the ability to audit and roll back changes. The file systems in the Docker container are stacked as series 1 layers. When a new container is created, a new layer is added at the top, which can be written. The Docker storage driver hides these details and delivers it to the user as a normal file system. A write to the running container will be written to this new layer. This is often referred to as write-time copy (Copy-On-Write, COW).

Configuration drift or expected configuration changes are easily detected in the Docker container. The "docker diff" command displays changes to the file system -- whether the change operation is file addition, deletion, or modification.

In addition to running a read-only container where possible, we make the following recommendations to ensure container security in a production environment:

Running a minimal image like Alpine Linux, Alpine Linux is designed with security in mind. Its kernel was patched with an unofficial port of grsecurity. Grsecurity is a set of security enhancements to the Linux kernel. It includes permission control and the possibility of bug-based memory crashes by minimizing those methods that make the system vulnerable to attack. Limit the use of CPU, RAM, and other resources to prevent DoS attacks. Configure thread and process restrictions in the operating system. Linux kernel enhancers using standards such as sysctl. Only one application is running in each container. This is recommended because it reduces the attack surface, meaning that the number of possible vulnerabilities for a given container depends only on the application running on that container.

Related articles: