action #170380
Updated by mkittler 5 months ago
## 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. ## Goals * **G1:** Based on configuration feature switch prevent unauthorized access to any or selected openQA assets * **G2:** By default openQA assets are still accessible unauthenticated * **G3:** Asset downloads are still handled in an efficient way by NGINX (and not in an inefficient way via Mojolicious). ## Suggestions * Look into https://github.com/os-autoinst/openQA/blob/master/lib/OpenQA/WebAPI.pm and move relevant routes below the "authenticated_only" root based on configuration variable * Ensure that openQA tests can still work properly with that * Implement this in openqa-cli to make it easy to download assets * Consider tests that currently re-use job assets directly * Consider how a (temporary) password (e.g. the job token) might be revealed in logs or needles, and how to address that * Only allow downloading asset from whitelisted IP address (of the worker/SUT) * Research how we can integrate/combine the authentication done via the Mojolicious app in NGINX. * The Mojolicious app already provides basic [HTTP auth](https://open.qa/docs/#_personal_access_token). Maybe we can configure NGINX in line with that and use it in relevant places instead of the custom authentication. * File follow-up tickets as necessary ## Out of scope * Restricting access to test details or needles