Best practices for Docker containers’ security

Containers aren’t VMs. They’re a great lightweight deployment solution, but they’re only as secure as you make them. You need to keep them in processes with limited capabilities, granting them only what they need. A process that has unlimited power, or one that can escalate its way there, can do unlimited damage if it’s compromised. Sound security practices will reduce the consequences of security incidents.

Don’t grant absolute power

It may seem too obvious to say, but never run a container as root. If your application must have quasi-root privileges, you can place the account within a user namespace, making it the root for the container but not the host machine. Also, don’t use the –privileged flag unless there’s a compelling reason. It’s one thing if the container does direct I/O on an embedded system, but normal application software should never need it.

Containers should run under an owner that has access to its own resources but not to other accounts. If a third-party image requires the –privileged flag without an obvious reason, there’s a good chance it’s badly designed if not malicious.

Avoid running a Docker socket in a container. It gives the process access to the Docker daemon, which is a useful but dangerous power. It includes the ability to control other containers, images, and volumes. If this kind of capability is necessary, it’s better to go through a proper API.

Grant privileges as needed

Applying the principle of least privilege minimizes container risks. A good approach is to drop all capabilities using –cap-drop=all and then enabling the ones that are needed with –cap-add. Each capability expands the attack surface between the container and its environment. Many workloads don’t need any added capabilities at all.

The no-new-privileges flag under security-opt is another way to protect against privilege escalation. Dropping all capabilities does the same thing, so you don’t need both.

‍Limiting the system resources which a container guards not only against runaway processes but against container-based DoS attacks.

Beware of dubious images

When possible, use official Docker images. They’re well documented and tested for security issues, and images are available for many common situations.

Be wary of backdoored images. Someone put 17 malicious container images on Docker Hub, and they were downloaded over 5 million times before being removed. Some of them engaged in cryptomining on their hosts, wasting many processor cycles while generating $90,000 in Monero for the images’ creator. Other images may leak confidential data to an outside server. Many containerized environments are undoubtedly still running them.

You should treat Docker images with the same caution you’d treat code libraries, CMS plugins, and other supporting software, Use only code that comes from a trustworthy source and is delivered through a reputable channel.

Other considerations

It should go without saying, but you need to rebuild your images regularly. The libraries and dependencies that they use get security patches from time to time, and you need to make sure your containers have them applied.

On Linux, you can gain additional protection from security profiles such as secomp and AppArmor. These modules, used with the security-opt settings, let you set policies that will be automatically enforced.

Container security presents its distinctive challenges. Experience with traditional application security helps in many ways, but Docker requires an additional set of practices. Still, the basics apply as much as ever. Start with trusted code. Don’t give it the power to do more than it needs to do. Use the available OS and Docker features for enhancing security. Monitor your systems for anomalous behavior. If you take all these steps, you’ll ward off the large majority of threats to your Docker environment.