QA (public) » openQA Project (public)

Motivation¶

Right now to be CC-compliant we need to prevent complete network access to openQA from non-CC locations as openQA might provide access to potentially sensitive data, e.g. openQA assets linked on openQA test results. For example https://openqa.opensuse.org/tests/4668726#downloads from https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensuse&flavor=DVD&machine=64bit&test=create_hdd_textmode&version=Tumbleweed has link https://openqa.opensuse.org/tests/4668726/asset/hdd/opensuse-Tumbleweed-x86_64-20241126-textmode@64bit.qcow2 pointing to https://openqa.opensuse.org/assets/hdd/opensuse-Tumbleweed-x86_64-20241126-textmode@64bit.qcow2 which is reachable unauthenticated. In this example this is of course not a problem but the same applies for openqa.suse.de which can potentially provide qcow files with sensitive data included for which we want to provide a solution to prevent unauthenticated access based on a configuration feature switch. Any openQA jobs that need this asset should still be able to do so, at least when they are part of the same dependency tree and such.

Acceptance criteria¶

• A1: Based on configuration feature switch prevent unauthorized access to any or selected openQA assets
• A2: By default openQA assets are still accessible unauthenticated
• A3: Asset downloads are still handled in an efficient way by NGINX (and not in an inefficient way via Mojolicious).
• A4: Asset downloads via the web UI still work when logged-in
• A5: The cache service can still download assets
• A6: openqa-clone-job still works when client.conf contains correct credentials for the source host
• A7: No relevant credentials like the "job token" are leaked to places that don't require authorization.

Suggestions¶

1. Block relevant routes on Mojolicious level. This has already been implemented by the first commit of https://github.com/os-autoinst/openQA/pull/6076.
2. Consider alternatives explored by #170380 / https://github.com/os-autoinst/openQA/pull/6076 to block/authenticate access to assets via NGINX.
   1. Relying on basic-auth only we could maintain a htpasswd file for API key/secret pairs, see https://github.com/Martchus/openQA/tree/asset-auth-nginx-basic-auth. This is probably the worst option.
   2. Commit https://github.com/Martchus/openQA/commit/b5950273aa4168b20a4c31f03ecc451465d466c9 shows the use of https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-subrequest-authentication. This would in theory allow to use any kind of auth mechanism that openQA supports.
      1. In practice I was only able to make it work with basic-auth despite fully following the NGINX guide (including all the config mentioned in step 5. - even though I haven't added that to the PR).
         1. So e.g. curl -u Demo:…:… http://localhost/assets/other/openSUSE-Tumbleweed-DVD-x86_64-Snapshot20230109-Media.iso.sha256 works.
         2. But MOJO_CLIENT_DEBUG=1 openqa-cli api http://localhost/assets/other/openSUSE-Tumbleweed-DVD-x86_64-Snapshot20230109-Media.iso.sha256 does not work even though API headers are sent.
            1. I am getting a 403 response and Mojolicious logs [debug] Rejecting authentication for user "Demo" with ip "::1", valid key "…", secret "…", unknown error (wrong secret?) for the auth sub request where both, key and secret, are correct.
         3. Being logged-in via a web browser also doesn't work yet.
3. Consider a different approach if subrequest authentication is not working.
   1. One idea that came up was to symlink assets on the side of the openQA instance to a temporary location and point the web reverse proxy to that and then remove the link to the temporary location again after the job finishes. This would be possible to do for assets that belong to a job being executed but it would probably be problematic for providing random access to arbitrary assets (e.g. to clone a job).
4. Take care of asset downloads via the web UI. This might work if 1.2.3 would work. Otherwise it might help to remove the redirection and just render the already resolved link.
5. Take care of asset downloads by the cache service. Commit https://github.com/Martchus/openQA/commit/32e1b30434f09ff71d242d5f8f51b68e0090d05a already shows that the openQA user agent could be used but it doesn't work due to 1.2.2.
   1. In addition to 1.2.2 there is another problem: The asset cache is always redirected to the index page so all that is downloaded is the index page and not the assets themselves. I could workaround this by commenting out the redirection code but this still needs to be taken care of appropriately.
6. Take care of asset downloads via openqa-clone-job. It uses LWP::UserAgent so we need to make sure it still works using any of the methods mentioned under 2. Note that openqa-clone-job is so far only concerned with authentication when it comes to creating jobs on the destination host. Now we need to consider authentication as well for getting assets from the source host and must not mix up the different credentials.
7. Remove/replace/improve "job token authentication", e.g. avoid the job token from showing up in logs and the web UI or remove this kind of authentication completely.

Out of scope¶

• Restricting access to test details or needles