Innovate faster and cut risk with PHP experts from Zend Services.
Beginning to advanced PHP classes to learn and earn global certification.
Help me choose >
Submit support requests and browse self-service resources.
Matthew Weier O’Phinney
PHP users increasingly containerize their applications, which provides predictability and ease of deployment. Containers have a known state on initialization, and (generally) run a single service at a time, making the services they encapsulate easier to understand and compose in complex systems. That said, Docker has historically required root privileges, which can potentially expose the host system to attacks.
As a result, many container users try and run Docker rootless, with an unprivileged user, to prevent privilege escalation that leads to such attacks. So, let's explore the implications, what rootless containers are, and the challenges you might face.
Containers typically run via a user with root privileges, and that user is the same as root on the host machine. This is necessary to allow various operations like installing system packages, changing configuration files, and more within the container. However, if an attacker were to exploit a vulnerability in the container that allows breaking out of the container to the host system, they could compromise the host in a variety of ways, including:
Any one of these could compromise your customers or confidential data.
So, if containers need root privileges, what is the solution?
One way to mitigate issues is to run services inside your containers as non-privileged users. This can be done in a variety of ways:
The primary benefit to these approaches is that they limit the capabilities of an attacker to gain root privileges within the container, which will help prevent their ability to break out of the container to the host.
Another solution is to run the containers themselves with a user other than root. The popular open source Docker alternative Podman does this by default, and Docker itself introduced an opt-in rootless mode in version 19.03, with full support for the mode in version 20. In both cases, these technologies allow running your containers as an unprivileged user. This means that even if an attacker breaks out of the container, they will not have root privileges on the host, limiting the attack surface substantially.
Unfortunately, rootless mode has a number of limitations:
Each of these can present further complexity for what is already often complex orchestration.
To help you secure your PHP applications, our ZendPHP container images are all built using the aforementioned s6-overlay. The features are opt-in; you can create your own containers without knowing anything about s6-overlay, and they will behave like normal containers. However, if you opt in to the features, you can:
Try ZendPHP for FreeWant to see how our ZendPHP container images work in your environment? Get Started
Want to see how our ZendPHP container images work in your environment?
In this blog, we've discussed root user privilege, how it can impact attack surface for container-based applications, and how running in rootless mode can help to mitigate those risks. As noted above, this approach can add additional complexity to your application(s), but it's typically worth the decreased attack surface.
Be sure to read the next blog in this series, where we detail the various ways you can use ZendPHP containers to lock down your images and expand their capabilities.
Zend Product Manager, Zend by Perforce
Matthew began developing on Zend Framework (ZF) before its first public release, and led the project for Zend from 2009 through 2019. He is a founding member of the PHP Framework Interop Group (PHP-FIG), which creates and promotes standards for the PHP ecosystem — and is serving his second elected term on the PHP-FIG Core Committee.