Docker, Best Practices

Docker has provided tremendous benefits over traditional hypervisors. However, most of its components are shared with the host kernel. So, if proper security measures are not taken, the host system can be at risk of being compromised and let an attacker take control of it. In this article we will be looking at some of the best practices in Docker.

Photo by Alex Knight on Unsplash

In Technology driven world , no matter what measures you take, security can be breached at any level and no one can totally remove the security risks. However, we can mitigate the risks by following some best processes to ensure that we close all the gates for an attacker to get access to our host machine in Docker.

Mounting volumes as read only

One of the best practices is to mount the host filesystem as read-only if there is no data being saved by the container. We can do that by simply using a ro flag for mounts using -v argument or readonly with the --mount argument.

docker run --mount source=volume-name,destination=<PATH_TO_CONTAINER>,readonly python:3.9

`docker run -v volume-name:<Path_to_container>:ro python:3.9;`

Limit resource usage

One of the best thing that is present in Docker is the flexibility to assign a predefined resource usage policy for a container. This is supported only in swarm mode.

We can limit the CPU usage of a container by declaring the allowed usage in the deploy section. Here is an example from the official documentation.

version: "3.8"  
services:  
  redis:  
    image: redis:alpine  
    deploy:  
      resources:  
        limits:  
          cpus: '0.50'  
          memory: 50M  
        reservations:  
          cpus: '0.25'  
          memory: 20M

This way, we will be sure that no container will use host resources above a threshold and other services will be running on the host without any harm.

No root access

A container should never be run with root-level access. A role-based access control system will reduce the possibility of accidental access to other processes running in the same namespace. Many of the organizations restrict access using the active directory/SSO/Roles and provide appropriate access based on user roles.

In general, we can use Linux’s inbuilt commands to create a temporary non-root user on the fly.

FROM python:3.5  
RUN groupadd -r myuser && useradd -r -g myuser myuser  
<HERE DO WHAT YOU HAVE TO DO AS A ROOT USER LIKE INSTALLING PACKAGES ETC.>  
USER myuser

or while running a container from the image use,

docker run -u 1947 python:3.9

This will run the container as a non-root user.

Trusted image source

Check the authenticity of every image pulled from Docker Hub. Use Docker Content Trust to check the authenticity of the Image. Docker Content Trust is a new feature incorporated into Docker 1.8. It is disabled by default, but once enabled, allows you to verify the integrity, authenticity, and publication date of all Docker images from the Docker Hub registry.

Enable Docker content trust using export DOCKER_CONTENT_TRUST=1 and try to pull this unsigned image docker pull <Not_trusted_image>.

# docker pull <Not_trusted_image>  
Using default tag: latest  
Error: remote trust data does not exist for docker.io/<Not_trusted_image>: notary.docker.io does not have trust data for docker.io/jpetazzo/clock

Docker will check whether the image is safe or not and will throw an error if it is not.

The above is an extract from my learnings in Docker world, Do share your thoughts on the same.

DSG Blog