There are two useful features of the Docker platform to restrict what applications can do inside containers. Currently, they only work with Linux containers, but they are worth understanding if you need to deal with mixed workloads, and support for Windows may be coming in future versions.

Linux containers can be run with the read-only flag, which creates the container with a read-only filesystem. This option can be used with any image, and it will start a container with the same entry process as usual. The difference is that the container does not have a writeable filesystem layer, so no files can be added or changed—the container cannot modify the contents of the image.

This is a useful security feature. A web application could have a vulnerability that allows attackers to execute code on the server, but a read-only container severely limits what the attacker can do. They cannot change application configuration files, alter access permissions, download new malware, or replace application binaries.

Read-only containers can be combined with Docker volumes, so applications can write to known locations for logging or caching data. If you have an application that writes to the filesystem, that's how you can run it in a read-only container without changing functionality. You need to be aware that if you write logs to a file in a volume and an attacker has gained access to the filesystem, they could read historical logs, which they can't do if logs are written to standard output and consumed by the Docker platform.

When you run Linux containers, you can also explicitly add or drop the system capabilities that are available to the container. As an example, you can start a container without the chown capability, so no process inside the container can change file access permissions. Similarly, you can restrict binding to network ports or write access to kernel logs.

The read-only, cap-add, and cap-drop options have no effect on Windows containers, but support may come in future versions of Docker on Windows.