Docker security: Risks and Best Practices

Abdullah Siddique on 2022-09-18

A container platform called Docker enables users to develop, test, and deploy programs. With more than 5 million users and 6 million repositories on Docker Hub, Docker is used on roughly one out of every five hosts.

Given their rapid acceptance, it is advisable to handle these systems with security as a top priority. Knowing how to harden these deployments is crucial whether you are creating containers for your business or deploying containers made by other teams

The fact is that containers lack a security dimension by default. Their supporting infrastructure (OS and platform), l embedded software components and runtime configuration are entirely responsible for their security.

In this article I am going to go over 7 scenarios in which Docker installation could become vulnerable and I’ll be discussing ways to minimize the threat.

  1. Binding daemon to network interface

What’s the risk?

The Docker daemon generates and manages your Docker objects, such as images, containers, networks, and volumes, as well as listens for Docker API requests. It is owned by the root user by default and has higher privileges than just root. By connecting the daemon to a network interface, you can also make your Docker container accessible from a distance but making it vulnerable to attack from enemies.

How to lessen the threats?

When connecting the daemon to the network interface, take caution. Use Docker’s encrypted HTTP Socket, which enables authentication, if you must, make it accessible. Another thing that needs to be kept in mind is to never make the UNIX socket public that Docker is listening to


This the main entry point of Docker API. Giving someone access to it is the same as giving your host full root access. Never put it in contact with other containers

-v /var/run/docker.sock://var/run/docker.sock

2. Information leakage

What’s the risk?

Leaking Sensitive information is one of the main worries. To function normally Docker needs things like SSH keys, credentials, and TLS certificates. Exposing them in the Docker file itself is like giving your house keys to your enemy.

How to lessen the threats?

Disclosing sensitive information through Docker files can lead to the attacker having rapid access to your container. Container orchestrators like Docker Swarm have secret management capabilities that can address the issue of using Docker files to leak sensitive information.

3. Open source images

What’s the risk?

Installing open-source libraries that are vulnerable. The Docker Hub registry has more than 100,000 open-source container repositories, some of which contain modified and unofficial versions of popular images. When you deploy a new repo to Docker Hub, you should make sure you trust the publisher because it is accessible to everyone.

How to lessen the threats?

Utilize base images with the minimum components. Even if some of the components are already installed, it’s necessary that you understand them. Because doing so will undoubtedly increase the attack surface. To prevent the introduction of vulnerabilities and malicious code, keep away from untested or untrusted builds. Using Docker certified and Docker Store packages is a secure choice. A reputable third-party registry with integrated scanning is another option.

4. System commands

What’s the risk?

Allowing users to run system commands. On a freshly set up Docker container, you let users run system commands. The user may employ allowing system calls to increase their level of privilege.

How to lessen the threats?

You can decide whether to accept or reject system calls. Additionally, you may check the system command running in the same way that you can in Linux by looking at the bash history file.

5. Verify Docker image authenticity

What’s the risk?

Docker images that are downloaded from unidentified repositories might be dangerous. In any combined DevOps workflow, putting security first sets the tone for reducing possible dangers.

How to lessen the threats?

Updating base image to the “slim” or Alpine Linux container image is Docker image hardening process. Apps are less vulnerable to hacking attempts when there are fewer system files or applications in the container image. This limits an attacker’s possibilities for horizontal network movement. You should always prefer using a trusted image, preferably from the Docker Official Images, to reduce supply chain attacks. Alpine Linux is suggested as a base distro if you need one because it is one of the lightest ones available, guaranteeing that the attack surface is minimized.

6 . Use least privilege access

What’s the risk?

Least privilege access should be at the top of any security best practice list, and the same is true for Docker security. Gaining access to sensitive system data and implementing malicious code are two options available to cyber criminals. Never grant a container more authority than is necessary to do a given task.

How to lessen the threats?

The usage of least privilege/unprivileged access should also be applied by administrators to the development process to prevent programmers from being released into production with security flaws.

By default, the process inside a container is run as root (id=0).

To enforce the principle of least privilege, you should set a default user. For this you have two options:

  1. Either specify an arbitrary user ID that won’t exist in the running container, with the -u option:

docker run -u 4000 <image>

2. l Alternatively, prepare by adding a default user to your Dockerfile. We are aware that running Docker with privileged access can be risky. A “rootless mode” is provided by Docker.

docker context use rootless
docker run –d –p 8080:80 nginx

To check if container is running in privilege mode:

docker inspect –format = ‘ ‘ [container_id]

If it returns true it is running in the privileged mode. If it throws an error, it is not.

7. Breaking out of containers:

What’s the risk?

Although container breakouts are uncommon, they are not impossible. From a compromised container, attackers shouldn’t be able to access the host or other containers. Users are not name spaced by default, thus whenever a process breakout a container, it keeps the privileges granted to the container host. Root access in the container will become root access on the host — enabling privilege escalation

How to lessen the threats?

Testing should be a part of every development project that considers security. A tool called Docker Bench scans containers for flaws using the Center for Internet Security (CIS) Docker Benchmarks. To guard against host-level assaults, CIS advises admins to use security technologies to harden their container software. A free PDF version of CIS’s benchmarks, which include in-depth security testing for both Docker and common OSes, is available.

Now these were some of the most common security risks faced in the world of Dockers. But these were the scenarios that popped up during the runtime. What if we took measures before deploying the containers to avoid any sorts of inconvenience. Let’s talk about some Best Practices that are used my professional developers all over the world.

Docker Container Security Best Practices:


The logging level is set to INFO by default, however you can choose another one using the option:

— log-level=”debug”|”info”|”warn”|”error”|”fatal”

If your containerized app produces event logs, you can redirect STDERR and STDOUT streams to an external logging service for decoupling using the option:

— log-driver=<logging_driver>

To maintain Docker access to logs while utilizing an external service, you can also setup dual logging. You can still reroute these streams if your application makes use of any dedicated files (often stored under /var/log).

Runtime Protection

It’s crucial to have visibility into the container and worker nodes in order to secure application data on a running container. Real-time activity and meta data from both containers and worker nodes should be recorded and corroborated by a container security solution. With increased visibility, criminal activity can be prevented and container incidents can be investigated more quickly. You should never include sensitive information in plaintext in an ENV directive. They just aren’t a secure place to keep any data that you don’t want to appear in the final layer.

RUN unset $VAR

To prevent runtime read access, use a single RUN command to set and unset the variable in a single layer.

RUN export ADMIN_USER="admin" \
&& ... \
&& unset ADMIN_USER

Utilize the ARG directive (once the image is built, ARG values are not available)

Ensure Proper Configuration Management

Developers need to be fully aware of a container’s contents, including any potential security holes. In the event, effective Docker image configuration management helps in keeping track of containers and their contents. Developers need to eliminate unknown container sources.

Only allow read access to the root file system

Containers should be primarily stateless and ephemeral. That’s why you can frequently restrict the mounted file system to read-only. If you make use of Kubernetes and want to add another layer to your docker security, you can even prevent containers from starting as root, and you can make this explicit. This approach will work even if the admin tries to lach the container manually. All you have to do is add a directive in the pod security policy MustRunAsNonRoot and voila, your container will never with root access.

Use a temporary file system for non-persistent data

Let’s say if you are using a non persistent environment; e.g. your application allows access as guest but after the session is ended all that data is to be discarded, set up temporary file system for such data, to avoid data logging, space shortage, data redundancy etc. To set up temporary storage you can use the command

docker run — read-only — tmpfs /tmp:rw ,noexec,nosuid <image>

Restrict Network Port Accessibility

For the sake of troubleshooting or debugging, a developer may grant access to additional network ports while creating a container. This method works, but once the image is used in situations that are open to the public internet or in production, close access to those extra network ports.

When using the Docker command-line interface (CLI), the -p parameter can be used to set rigid restrictions on host-to-container port mappings. Any ports not specified in this command will be inaccessible.

Log files are frequently created during the Dockerfile construction process. To exclude these files from being added to the build context, use the .dockerignorecommand to specifically exclude specific files or directories from the build process. This prevents unintentional disclosure of any confidential information or credentials.


Docker security is no small task. Even the professionals are always on the lookout for security breaches and patching them up. The best solution is to think smart, keep as many scenarios in mind as you can and aim to build a secure container environment. There is no pitch perfect Docker security layout or plan. You always have to keep in touch with the new emerging threats, find the antidote for that and keep adding layers of security for your Docker container.

That’s all folks. May the force be with you.