bitnami / containers

Bitnami container images
https://bitnami.com
Other
3.05k stars 4.41k forks source link

[bitnami/wordpress-nginx] Improve docs for secure Kubernetes environments #68791

Open sc250024 opened 6 days ago

sc250024 commented 6 days ago

Name and Version

bitnami/wordpress-nginx:6.5.5-debian-12-r2

What is the problem this feature will solve?

Currently there is a dearth of documentation around how the Bitnami Wordpress / Wordpress NGINX container images work under the hood; specifically, what they are doing at runtime in order to install WordPress, and how to deal with this running in a more secure Kubernetes environment. Because of this, users like me are having a hell of a time trying to get the Bitnami Wordpress images to work in a Kubernetes environment that's more locked down.

What is the feature you are proposing to solve the problem?

I would like to use this issue to make the following improvements:

I will myself open the PR to do the documentation updates, but I am looking for a member of Bitnami to assist with technical questions.

What alternatives have you considered?

Using the official WordPress image on DockerHub (https://hub.docker.com/_/wordpress) because even though it does not contain nearly as many helpers, at least I control what's going on during runtime, and can find workarounds to security restrictions.

sc250024 commented 6 days ago

Would someone from Bitnami be willing to answer any questions here to address this issue?

bashbang commented 5 days ago

I've been digging through the code recently looking for a hook where I can run a custom script to do a post wordpress install of plugins/themes after an init. I was planning on using Composer (https://getcomposer.org/) to do this install and run some custom wp-cli commands. After much digging I'm unable to find such a hook.

A script placed inside /docker-entrypoint-initdb.d runs before the persistent install of WordPress so is unhelpful for me in this case. I'm pretty sure there's an intention to run custom post-install scripts as I do see the /post-init.d folder on the container and the code inside post-init.sh seems to indicate it's wishing to load all the .sh files from that folder and run them. However, when I place a 775 file.sh into that folder it does not execute at all.

So there's possibly a bug there, or perhaps it wasn't designed to do what I'm wishing it to do. The docs don't really speak to this area and does require some code digging to understand.

bashbang commented 5 days ago

To your point @sc250024 I to had a challenges getting it to work. I'm running on Openshift which requires a rootless container, hence the reason I generally default back to Bitnami images (which I love BTW!)

I eventually got it to work, with a great deal of trial and error to understand the inner workings of the image. I'd agree that some additional documentation would be helpful for some, depending on your use case you may have to go code digging anyway, especially if it's more of an edge case.

sc250024 commented 5 days ago

@bashbang I am currently doing something like this for my custom theme:

Dockerfile ```dockerfile # -------------------------------------------------------- # Nodejs Base # -------------------------------------------------------- ARG NODE_VERSION=20 FROM docker.io/library/node:${NODE_VERSION}-slim AS nodebase ENV NODE_VERSION="${NODE_VERSION}" WORKDIR /build # -------------------------------------------------------- # WordPress Base # -------------------------------------------------------- FROM docker.io/bitnami/wordpress-nginx:6 AS wpbase USER root # This is added in order to make it easier to debug Bitnami's init scripts # By default, the scripts have a comment that disables xtrace and give no way # to easily enable it without modifying the files themselves. This command will # enable xtrace if the BITNAMI_DEBUG environment variable is set to "true" RUN find /opt -type f -name "*.sh" -print0 | xargs -0 sed -i 's|^# set -o xtrace.*$|[[ "\$\{BITNAMI_DEBUG:-\}" == "true" ]] \&\& set -o xtrace|' # -------------------------------------------------------- # Build # -------------------------------------------------------- FROM nodebase AS nodebuild COPY package.json . COPY src ./src # Install dependencies RUN npm install # Build Mix COPY webpack.mix.js . RUN npx update-browserslist-db@latest \ && npm run build # -------------------------------------------------------- # Main App # -------------------------------------------------------- FROM wpbase AS application COPY --from=nodebuild /build/assets /opt/bitnami/wordpress/wp-content/themes/my-custom-theme/assets COPY *.php screenshot.png style.css /opt/bitnami/wordpress/wp-content/themes/my-custom-theme/ COPY acf-json /opt/bitnami/wordpress/wp-content/themes/my-custom-theme/acf-json COPY assets /opt/bitnami/wordpress/wp-content/themes/my-custom-theme/assets COPY inc /opt/bitnami/wordpress/wp-content/themes/my-custom-theme/inc COPY languages /opt/bitnami/wordpress/wp-content/themes/my-custom-theme/languages COPY template-parts /opt/bitnami/wordpress/wp-content/themes/my-custom-theme/template-parts RUN chown -R daemon:root /opt/bitnami/wordpress/wp-content/themes/my-custom-theme \ && chmod -R 775 /opt/bitnami/wordpress/wp-content/themes/my-custom-theme USER 1001 ```

I actually don't mind building the custom image and pushing it, but I think there should be some documentation around this.

carrodher commented 2 days ago

Thank you for bringing this issue to our attention. We appreciate your involvement!

The recommended way of consuming this container in Kubernetes is using the bitnami/wordpress Helm chart. There are different blog posts about how Bitnami containers and Helm charts are securitized, i.e

Having said that, if you're interested in contributing a solution to improve the docs, we welcome you to create a pull request. The Bitnami team is excited to review your submission and offer feedback. You can find the contributing guidelines here.

Your contribution will greatly benefit the community. Feel free to reach out if you have any questions or need assistance.

bashbang commented 1 day ago

@bashbang I am currently doing something like this for my custom theme:

Dockerfile I actually don't mind building the custom image and pushing it, but I think there should be some documentation around this.

@sc250024 This was very helpful thank you. I'd tried do use this method in a previous version of my Dockerfile but the content kept getting overwritten. I suspect incorrect permissions or ownership was the reason.

In any case adding the composer.json file to the /opt/bitnami/wordpress/ folder then running the "composer update" while doing the docker build places the plugins and themes into the /opt/bitnami/wordpress folder which then during the runtime init moves the files into the /bitnami/wordpress/wp-content subfolders.

So thank you for the tip....it helped and got me moving in the right direction.

sc250024 commented 1 day ago

@carrodher Hey Carlos! The Helm chart does help, but it also needs improvements. For example, if I run a simple helm template command on the latest version of the bitnami/wordpress chart, the volumeMounts section is as follows:

volumeMounts:
  - name: empty-dir
    mountPath: /opt/bitnami/apache/conf
    subPath: apache-conf-dir
  - name: empty-dir
    mountPath: /opt/bitnami/apache/logs
    subPath: apache-logs-dir
  - name: empty-dir
    mountPath: /opt/bitnami/apache/var/run
    subPath: apache-tmp-dir
  - name: empty-dir
    mountPath: /opt/bitnami/php/etc
    subPath: php-conf-dir
  - name: empty-dir
    mountPath: /opt/bitnami/php/tmp
    subPath: php-tmp-dir
  - name: empty-dir
    mountPath: /opt/bitnami/php/var
    subPath: php-var-dir
  - name: empty-dir
    mountPath: /tmp
    subPath: tmp-dir
  - name: empty-dir
    mountPath: /opt/bitnami/wordpress
    subPath: app-base-dir
  - mountPath: /bitnami/wordpress
    name: wordpress-data
    subPath: wordpress

Why are all these paths needed?

Also, this works fine if you're using Apache, but there seems to be no support for the NGINX image in that chart. Additionally, if I run a simple helm install with default settings, I noticed this in the logs of the Wordpress container:

06:06:02.74 INFO  ==> ** Starting WordPress setup **
06:06:02.74 WARN  ==> The Apache configuration file '/opt/bitnami/apache/conf/httpd.conf' is not writable. Configurations based on environment variables will not be applied.
06:06:02.75 INFO  ==> Generating sample certificates

So even with the defaults, there are still permission issues.

@carrodher Do you know the processes that the image goes through during startup?

carrodher commented 1 day ago

Bitnami containers are designed to operate as non-root by default. Consequently, any files or directories used by the application should be owned by the root group, as the random user (1001 by default) is a member of this root group. To ensure proper permissions, you'll need to adjust the ownership of your local directory accordingly.

For more comprehensive information about non-root containers and their significance for security, you can explore the following resources:

These references provide valuable insights into the best practices and considerations when working with non-root containers in Bitnami applications.

sc250024 commented 1 day ago

@carrodher I am very well versed in Kubernetes, and with running non-root containers. The links you sent, while informative, I think are too generic for this issue. I am wondering what steps / processes this particular image does to ensure that that the processes all start correctly, and that WordPress is setup for a non-root container environment.

I would ping people who have contributed to the changes on each file, but a git blame simply reveals the only code author to be the @bitnami-bot (example here)

It sounds like what you're saying is that I would need to look through all of these scripts myself to fix the problem? There's no one in your organization with this deeper level of knowledge? Is that correct?