action #170380
open[spike][timeboxed:10h] Prevent unauthorized openQA asset download size:S
0%
Description
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. 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
Updated by okurz 7 days ago
- Copied to action #170383: [spike][timeboxed:10h] Concept for full RBAC implementation size:S added
Updated by szarate 5 days ago · Edited
- Disable directory listing on nginx or
echo "" >> /var/lib/openqa/share/factory/*/index.html - Not authenticated requests, shall not give more information than it should.
- Authenticated requests that fail, shall have the least ammount of information required.
e.g, consider implementing error pages for different http status
For this task, it is not needed to go over the implementation details, only 1 and 2 from the list above have to be implemented.
# not authenticated
foursixnine@pakhet gitlab-suse-de-workspace-test % curl -I https://openqa.suse.de/asset/hdd/SLES-15-SP7-aarch64-Build43.1@aarch64-unregistered_functional.qcow2
HTTP/2 403
server: nginx/1.21.5
date: Thu, 28 Nov 2024 10:38:57 GMT
content-type: text/html;charset=UTF-8
content-length: 87
strict-transport-security: max-age=31536000; includeSubDomains
# authenticated and authorized, but no job (or asset is marked as on a need to use basis)
foursixnine@pakhet gitlab-suse-de-workspace-test % curl -I https://openqa.suse.de/hdd/SLES-15-SP7-aarch64-Build43.1@aarch64-unregistered_functional.qcow2
HTTP/2 418
server: nginx/1.21.5
date: Thu, 28 Nov 2024 10:44:47 GMT
content-type: text/html;charset=UTF-8
content-length: 72030
strict-transport-security: max-age=31536000; includeSubDomains
vary: Accept-Encoding
# authenticated and authorized, permitted to access asset
foursixnine@pakhet gitlab-suse-de-workspace-test % curl -I https://openqa.suse.de/tests/16031623/asset/hdd/SLES-15-SP7-aarch64-Build43.1@aarch64-unregistered_functional.qcow2
HTTP/2 302
server: nginx/1.21.5
date: Thu, 28 Nov 2024 10:45:22 GMT
content-length: 0
location: /assets/hdd/SLES-15-SP7-aarch64-Build43.1@aarch64-unregistered_functional.qcow2
strict-transport-security: max-age=31536000; includeSubDomains
# authenticated and authorized, permitted to download
foursixnine@pakhet gitlab-suse-de-workspace-test % curl -I https://openqa.suse.de/hdd/SLES-15-SP7-aarch64-Build43.1@aarch64-unregistered_functional.qcow2
HTTP/2 200
server: nginx/1.21.5
date: Thu, 28 Nov 2024 10:44:47 GMT
content-type: text/html;charset=UTF-8
content-length: 72030
strict-transport-security: max-age=31536000; includeSubDomains
vary: Accept-Encoding
Updated by mkittler 5 days ago
Maybe native mojo is not the bad,
I remember we had assets downloads via Mojo accidentally for a while on o3 when switching there to NGINX and it was not good enough.
maybe we can redirect to nginx
I think that's already happening but then we still need authentication in NGINX.
maybe we use traefik
I'll have to look into it.
whatever, all possible
One thing that came to mind when talking with @szarate was to create an NGINX module.
However, maybe there's already something we can use. Or we can simply configure HTTP auth in-line with what we also do in Mojolicious and only rely on that¹. Not sure whether that would be flexible enough to also restrict workers so they can only access assets of their current job (which would be part of the use case of #170383).
¹ Note that basic HTTP auth can be configured via auth_basic_user_file in NGINX and we could probably generate/update those files from the Mojolicious app when new API keys are created or API keys are removed.