action #176241
closed[spike][timeboxed:10h] Only allow unauthorized asset access on OSD based on network interface size:S
0%
Description
Motivation¶
As discussed in #175902 there are certain use cases where unauthorized, unencrypted asset access is necessary, e.g.
- http://openqa.suse.de/assets/iso/agama-installer.s390x-11.0.0-SLE-Build3.7.iso
- http://openqa.suse.de/assets/repo/SLE-15-SP7-Product-SLES-POOL-x86_64-Build56.1-Media1/
- http://openqa.suse.de/assets/repo/SLE-15-SP7-Product-SLES-POOL-x86_64-Build56.1-Media1/
- (http,10.145.10.207)/assets/repo/SLE-15-SP7-Online-ppc64le-Build56.1-Media1/boot/ppc64le/linux
if it turns out we can't or mustn't allow complete unauthenticated access to /iso/ or /repo/ then we could look into the approach to use a dedicated network interface for zone-cc traffic and other traffic, e.g. OSD openQA workers from NUE2. Then we can have separate nginx instances listening on the corresponding server IP addresses of separate interfaces with differing config, i.e. allow unauthenticated traffic within zone-cc but only authenticated traffic from and to other zones
Acceptance Criteria¶
- AC1: We know how to configure NGINX to allow/disallow unauthorized assets downloads by network interface.
Suggestions¶
Updated by okurz 4 months ago
- Copied from action #175902: Enable prevention of unauthorized asset downloads on OSD size:S added
Updated by okurz 4 months ago
- Related to action #176670: Allow-list for OSD asset download added
Updated by mkittler about 1 month ago · Edited
This would actually be easy to do. I tested it with my local NGINX service:
server {
listen 192.168.2.28:80 default_server backlog=4096;
server_name openqa.suse.de openqa.oqa.prg2.suse.org;
…
# on this interface we allow unauthenticated access to repo, iso and hdd assets
location ~ ^/assets/((repo|iso|hdd)(/.*)?)$ {
alias /hdd/openqa-devel/openqa/share/factory/$1; # in this test setup I had asset under /hdd/…
#alias /var/lib/openqa/share/factory/$2; # in production it would be under /var/…
include conf.d/openqa-asset-config.inc;
}
…
}
server {
listen 192.168.2.8:80 default_server backlog=4096;
server_name openqa.suse.de openqa.oqa.prg2.suse.org;
# just the usual config here so access to assets may be restricted
…
}
When I now try to access this from my server I get the expected behavior:
The access via 192.168.2.8 is blocked:
curl 'http://192.168.2.8/assets/hdd/opensuse-Tumbleweed-x86_64-20221106-kde@64bit.qcow2'
<html>
<head><title>403 Forbidden</title></head>
<body>
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx/1.27.4</center>
</body>
</html>
The access via 192.168.2.28 works:
curl 'http://192.168.2.28/assets/hdd/opensuse-Tumbleweed-x86_64-20221106-kde@64bit.qcow2'
Warning: Binary output can mess up your terminal. Use "--output -" to tell curl to output it to your terminal anyway, or consider "--output <FILE>" to save to a file.
The only problematic thing is that one has to put the IP addresses of the interfaces into the NGINX config. It would be much nicer if one could put interface names there. So I'll check whether that's possible. In our case it is probably not a big deal because we configure DHCP so that OSD is always getting the same IP address. It seems like one can really not put interface name in the NGINX config. However, to avoid hard-coding IP addresses like in my example above one can use the domain names of those IP addresses. This worked in my local tests.
Updated by mkittler about 1 month ago · Edited
- Status changed from Workable to Feedback
So if it would be required we could do the following:
- Ask Infra to add a 2nd network interface to the OSD-VM so we have one interface within the CC-zone and one outside.
- Create a MR in the OPS repo to configure an IP and domain for the 2nd network interface.
- Configure NGINX as mentioned in #176241#note-7.
- Ensure tests use the domain associated with the 2nd network interface when unauthorized access is needed.
- Such tests need to run on workers within the CC-zone (or use Wireguard).
- The configuration could be done using variables in the worker config using variable expansion on the worker (see #169159) as needed.
For me this explanation fulfills AC1 so I would resolve this ticket.