Use a non-root user for all application files/directories, use another non-root user to run the CKAN processes

[kowh-ai]

One of the things that can increase security of the CKAN images/containers is to have a non-root user own all files and directories that are part of the application. Also to have another non-root user run the CKAN processes

This will be part the work on enhancements for a more production like environment

Repo: ckan-docker-base

For CKAN 2.10, 2.11 and master images (base and dev)

User: ckan-sys (id=502)- owns the files/directories that are part of the application and supporting libraries

User: ckan (id=503) - runs the application processes, owns files and directories it needs write access to

The primary group for the ckan-sys and ckan users is ckan-sys (id=503) - this is so if more granular write access for both users is needed in the future then this group could be used to do that

The following directories/file are required to be owned by the ckan-sys and ckan user:

ckan-sys
/srv/app/*
/docker-entrypoint.d/*
/usr/local/*

ckan
/srv/app/ckan.ini
/srv/app/src/*
/var/lib/ckan/*
/srv/app/src_extensions/ (for Development)

Repo: ckan-docker

The following directories/file are required to be owned by the ckan-sys user:

ckan-sys
/docker-entrypoint.d/
/srv/app/patches/*

[kowh-ai]

I will also include instructions on how to login to the running ckan container as the ckan-sys user

[ThrawnCA]

This has broken all of our test builds that use the ckan-dev 2.11 container. We can't even run the GitHub Actions 'checkout' action successfully due to permission trouble: https://github.com/qld-gov-au/ckanext-xloader/actions/runs/11828441001/job/32958546720

GitHub Actions documentation says not to use the USER command in a Dockerfile since it will break access to the GitHub workspace: https://docs.github.com/en/actions/sharing-automations/creating-actions/dockerfile-support-for-github-actions#user

The Checkout action repository has a discussion of workarounds: actions/checkout#956

[wardi]

@ThrawnCA try adding -u root on commands that need to run as root inside the container

[ThrawnCA]

@ThrawnCA try adding -u root on commands that need to run as root inside the container

Yes, we are now doing that, and it works (https://github.com/qld-gov-au/ckanext-xloader/actions/runs/11828838118). But it shouldn't be necessary to use workarounds like that just to run a checkout.

This change makes the ckan-dev container broken out-of-the-box on GitHub Actions. That's bad.

[wardi]

Github actions aren't the primary target for these docker images, and best practice for docker image security is to use a non-root user https://www.docker.com/blog/understanding-the-docker-user-instruction/

For running tests consider using the https://github.com/ckan/ckan/tree/master/test-infrastructure docker compose config, it closely resembles the environment we use on circle ci.

[ThrawnCA]

Github actions aren't the primary target for these docker images

I mean, maybe, but even CKAN core uses GitHub Actions for its automated testing. The development of the "officially supported" XLoader plugin relies on GitHub Actions testing based on the ckan-dev container, which is broken by this change. ckanext-scheming, ckanext-spatial, ckanext-harvest, and ckanext-pages, all in the CKAN GitHub organisation, likewise use GitHub Actions with the ckan-dev container, and will likely break next time something triggers a build.

This change breaks an awful lot of your stuff. I'm not saying it should never happen, you're right that it's a security benefit, but just pushing it through as if it's a non-breaking patch release is not a good approach.

[amercader]

I agree that this change has a major impact in the extensions and should have been better planned before pushing the images to the hub. ckan-dev images are used by all CKAN extensions as containers to run the tests and in my opinion we should consider GitHub Actions as a major target.

We can discuss a better process for releasing new versions of the images separately but to address this particular issue let's see what options do we have:

• Stick with the changes on ckan-dev, make a proper release and document that existing workflows need to be updated to include the following, plus update the extension template in core and all extensions in the ckan org:

diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml
index e8bb23a..73d4d51 100644
--- a/.github/workflows/test.yml
+++ b/.github/workflows/test.yml
@@ -24,6 +24,7 @@ jobs:
     runs-on: ubuntu-latest
     container:
       image: ckan/ckan-dev:${{ matrix.ckan-version }}
+      options: --user root
     services:
       solr:
         image: ckan/ckan-solr:${{ matrix.ckan-version }}-solr9

• Revert the ownership changes in the ckan-dev images only. I'm not sure if there are wider implications for this or if its feasible at all but perhaps is not a stretch to run images meant for testing and development as root?
• Something else?

For running tests consider using the https://github.com/ckan/ckan/tree/master/test-infrastructure docker compose config, it closely resembles the environment we use on circle ci.

This setup is designed to run the CKAN core tests, after cloning the core repo. It installs all requirements and does all the initial setup. All this is already done in the ckan-dev images and you just need to install your own extension to run the tests so it's much more quick and convenient. Besides if we adapted the core test-infrastructure setup to run extensions tests we would be running them as root anyway right?

[kowh-ai]

Perhaps another option is to have a set of specific GitHub Actions images (yes I know we already have enough images!) however GitHub Actions uses a specific user github which has limited access for security reasons. The GitHub Actions images would be as vanilla as possible...

[amercader]

Let's keep the discussion in the new issue for better visibility: #86