Why Running a Privileged Container is Not a Good Idea
A privileged container has all the capabilities a host can perform. And that’s a bad idea.
Containers are not, by any means, new. They have been consistently and increasingly adopted in the past few years, with security being a popular related topic. It is well-established that giving administrative powers to server users is not a good security practice. In the world of containers, we have the same paradigm. On containers, we have the same security concerns with root users on *nix systems and administrators on Windows, plus an additional privileged state. Although this may not be a new concern, bringing awareness to the topic is essential.
By default, containers do not run in a privileged mode. For a container to run as a privileged application, the user must “flag” it to enable all capabilities to the container or pod. In other words, when a container is in a privileged mode, you are giving the container all the capabilities that a host can perform.
Doesn’t that sound pretty dangerous and scary?
In basic terms, running privileged containers is like running an application as root in the host or, for more technical users, it is like running as user id (0) or (“root” or “admin”) inside the host. This way, we are granting the container direct access to the kernel and to the hardware resources inside the host that the container should be restricted to access.
Why Are People Still Using Privileged Containers?
In very few and specific cases, containers require direct hardware access or extra privileges over the regular container to perform some additional tasks. However, keep in mind that this does not apply to 90% of environments. If you choose to use privileged containers, what you must do is segregate the host with it, so that any changes won’t affect the rest of your containers running in the same host. This feature was initially created for container developers/contributors to be able to work on container engines.
Although it is fairly common to see cases of users running privileged containers to automate some CI/CD tasks, running privileged containers is not a recommended architecture, and it is not considered secure for your environment.
What Are the Risks Associated With Using a Privileged Container?
While the immutable aspect of container technology and its short lifetime in the environment brings many security benefits, they can also be an attack vector if their configurations or permissions in production environments are set up incorrectly. This could allow malicious hackers to take control or acquire access to some devices of the container host in a short amount of time.
It is important to know that privileged containers can be used as entry points for attacks and to spread malicious code or malware to compromised hosts and networks. But this is not the only issue—there are other misconfigurations in containers that can put the underlying host at risk.
When you allow the container privileged access, it can access all disks that are mounted on the host; therefore, mount it and have read-write access to the files.
Recommendation
To prevent security issues, it is recommended that you do not run privileged containers in your environment. Instead, provide granular permissions and capabilities to the container environment. Giving containers full access to the host can create security flaws in your production environment. This is the reason that, by default, containers are “unprivileged” and cannot access all the devices in the host.
Running a privileged container is different from running a container using the user root inside it, which should also be avoided. Most of the base images, in this case, would come with few users, of which the root is the only one with a valid bash. The best practice would be creating your own non-root user prior to container deployment. For example, if you are using the httpd container, you should create a user called apache and run the container using –user or -u parameter when running the container.
However, this doesn’t mean that privileged containers should not be used at all. Some projects and environments may require its usage, but organizations need to make sure that safeguards and security recommendations are set in place when running such containers.
About the Co-Author
This article was co-authored by Alfredo de Oliveira, a Senior Security Researcher at Trend Micro. He has more than 12 years of experience working in the cybersecurity field. Previously, Alfredo worked as a pentester, a threat investigator and a malware analyst, and has always kept Open Source software as a primary passion, but has recently discovered his passion working with DevSecOps. Connect with him on LinkedIn.
