By default, containers run in unprivileged mode, that is, we cannot run Docker daemon inside a Docker container.
However, a privileged Docker container is allowed to access to all the devices on the host woth the same privileges of the process running on the host.

Among the possibilities of the “privileged” mode, you can run Docker within Docker itself.
This feature was introduced for the development of Docker itself, but currently there are various use cases of automating continuous integration and delivery tasks in the open-source automation server Jenkins that uses Docker-in-docker.

In an interesting post on Security Intelligence Blog [1], David Fiser and Alfredo Oliveira explores how running a privileged (and unsecure) container may allow cybercriminals to gain a backdoor in a system:

Running a container with privileged flag allows internal teams to have critical access to the host’s resources — but by abusing a privileged container, cybercriminals can gain access to them as well. When an attacker abuses a privileged container for an attack, it does not necessarily entail remote code execution. But when they do execute code, the potential attack surface is wide. . As the privileged container is spawned because of the need for enhanced permissions, there is a large chance that an attacker will be able to run code as root. This implies that an attacker will be able to run full host root with all of the available capabilities, including  CAP_SYS_ADMIN. It’s notable to mention that other isolation techniques such as cgroups, AppArmor, and SECcomp  are renounced or disabled.

For malicious actors who gain access to exposed privileged containers, the possibilities for abuse are seemingly endless. Attackers can identify software running on the host to find and exploit vulnerabilities. They can also exploit container software vulnerabilities or misconfigurations, such as containers with weak credentials or no authentication. Because an attacker has root access, malicious code or coin miners can be executed and effectively hidden.

Some security recommendations for using privileged containers

Researchers suggests:

  1. Implement the principle of least privilege. Access to critical components like the daemon service that helps run containers should be restricted. Network connections should also be encrypted.
  2. Containers should be configured so that access is granted only to trusted sources, which includes the internal network. This includes implementing proper authentication procedures for the containers themselves.
  3. Follow recommended best practices. Docker provides a comprehensive list of best practices [2] and has built-in security features professionals can take advantage of, such as configuring Linux hosts to work better with Docker via post-installation [3].
  4. Carefully assess needs. Does the use case absolutely have to run in Docker? Are there other container engines that do not run with root access and can do the job as effectively? Can it be done differently? Do you accept the risks associated with this need?
  5. Security audits should be performed at regular intervals to check for any suspicious containers and images.


  1. Why Running a Privileged Container in Docker Is a Bad Idea
  2. Docker security
  3. Post-installation steps for Linux