Running WordPress on Containers

Powering more than 40% of the top 10 million websites on the Internet today according to WikiPedia, WordPress continues to be one of the most popular content management systems in the world. Though its core components remain primarily PHP and MySQL/MariaDB, a lot has changed in the past 20 years in terms of infrastructure and hosting options.

Containers offer several significant benefits for WordPress environments. They provide isolation, ensuring that each WordPress instance operates independently without interfering with others. This enhances security and prevents conflicts. Additionally, containers enable scalability, allowing easy horizontal scaling of WordPress applications to meet increased demand. This is particularly useful for handling traffic spikes or seasonal fluctuations. Furthermore, containers offer portability, making it simple to move WordPress environments between different hosting providers or infrastructure. This flexibility can be valuable for disaster recovery and migration purposes. It also facilitates the use (and reuse) of disposable environments that can be shared across different stages, from build and development to test and production.

In this post, we'll discuss some considerations around running WordPress on containers, and how to better choose a base image for your specific WordPress needs.

Migrating to Container-Based Environments

If you are a long-time WordPress administrator, you may have experience in setting up LAMP or LEMP systems (Linux / PHP / MySQL or MariaDB, and either Apache or Nginx as web server). Understanding how these services communicate between each other is helpful in order to create a suitable environment based on containers.

You can create a container-based LEMP environment to run locally on your machine using Docker Compose. This is a great starting point for anyone migrating from bare metal servers or VPSs to containerized environments.

This post has a nice overview of Docker development environments for beginners. The Docker Compose documentation has guidance on how to set up a Docker Compose file to orchestrate multiple container-based services.

Choosing a WordPress Base Image

Using containers is a good starting point to create safer WordPress runtime environments, but it is important to choose your base image carefully. There are a few important factors you need to take into consideration when choosing a base container image for your WordPress environments:

Image Provider
Make sure you're using images from a reliable provider, and avoid using images from unknown sources. When using images from Docker Hub, always give preference to providers that are verified Docker publishers, since those go through a vetting process and comprise high-quality images from commercial publishers verified by Docker.

Features and Ease of Use
Naturally, you want an image that has the features necessary for creating (or re-creating) your own WordPress setup, which might include custom plugins and themes. In addition to what's required to run WordPress, look for an image that has features to facilitate customization and migration.

Update Frequency and Patching
Ensure the image is frequently updated to address security vulnerabilities and incorporate the latest WordPress features.
Look for providers with a clear patching policy and commitment to timely updates.

Size and Attack Surface
Size sometimes matter. For containers, size might be an indication of the amount of packages included in the image. From a vulnerability standpoint, less is better, because it means there is less surface for a potential attack. Make sure the image has what is needed to run WordPress, without bloat from unnecessary software.

Number of Vulnerabilities
Last but not least, be on the lookout for container images with less vulnerabilities. Although this might sound like a no-brainer, many people don't take into consideration that containers can be exploited almost in the same way as a VPS or bare metal server. In the next section, we'll have a better look at what CVEs are and how to scan your container images for known CVEs.

CVEs Explained

CVEs, or Common Vulnerabilities and Exposures, are publicly known security flaws in software or hardware. These vulnerabilities can be exploited by malicious actors to gain unauthorized access, steal data, or disrupt systems. The severity of a CVE can range from minor inconveniences to catastrophic breaches. Unpatched CVEs pose significant risks to organizations of all sizes, making it imperative to stay informed and address them promptly.

We'll now see how to use Grype to scan container images for CVEs, which will help you make an informed choice when deciding on which base image to use for your WordPress environments.

Scanning WordPress Images for CVEs with Grype

Grype is a popular open source CVE scanner that scans for known vulnerabilities in container images and filesystems. At the time of this writing, the latest release is 0.80.1 and you can find packages for most operating systems in their releases page.

Before running the Grype scanner on container images, use docker pull to get the latest version available for that image. We'll run comparisons between the following base images available on Docker Hub:

• wordpress:latest
• wordpress:php8.3-fpm⁠-alpine
• bitnami/wordpress
• chainguard/wordpress

To scan an image, run grype followed by the image registry address. For example:

grype wordpress

And this will scan the default latest WordPress image on Docker Hub. You'll get output including the following contents:

• A summary of what was detected in the image, including number of packages, files, and executables
• The total amount of vulnerabilities found, which is calculated as total not-fixed - total ignored + total fixed
• Total vulnerabilities grouped by severity and by status
• The full list of detected CVEs including number and severity

The following chart contains a summary of scan results for the images previously listed as of September 18, 2024. You can run grype against each of the listed images and check the data for yourself as well. This includes only CVEs marked as low, medium, high, and critical scores.

Results Summary:

• wordpress:latest: low: 9, medium: 175, high: 63, critical: 8
• wordpress:php8.3-fpm⁠-alpine: low: 7, medium: 144, high: 106, critical: 30
• bitnami/wordpress: low: 8, medium: 46, high: 27, critical: 8
• chainguard/wordpress: medium: 1

Yes, that's what you read. Run the scans on your own machine and you'll get the same numbers.

Why does the Chainguard WordPress image has only 1 CVE? That's a very good question. I know a couple things about this subject, since I have built that image ;)

I will explain everything you need to know about Chainguard's 1-CVE WordPress image at my upcoming Learning Lab. This is a free online event happening on the 24th of September, and you can register here to participate.

Resources to Learn More

If you are curious about Chainguard Images and Wolfi, check out Chainguard Academy, where me and my colleagues at the Developer Enablement team from Chainguard share documentation and tutorials about software supply chain security, container image security, Wolfi and Chaiguard Images.

Our WordPress getting started guide has detailed information on how to get started with Chainguard's WordPress image. This content is also available in video format here:

Conclusion

Running WordPress on containerized environments has many advantages, but it's important to choose your base container images wisely, since some popular options are riddled with vulnerabilities. We've seen some important things to take into account when choosing an image, and how to use the grype CVE scanner to verify how vulnerable an image might be to known CVEs.

From here, you can make your own evaluation and decide what to use. If you would like to learn more about the Chainguard WordPress image, you can attend our upcoming Learning Lab here.