QA » openQA Project » openQA Infrastructure

Motivation¶

In https://sd.suse.com/servicedesk/customer/portal/1/SD-150437 we are asked to handle "compromised root passwords in QA segments" including s390zl11…16. Because we failed to setup a firewall on hypervisors hosts directly, see #158242, we should ask SUSE-IT to REJECT – please don't DROP to not further confuse people – direct ssh access to the specific IP addresses of s390kvm VMs as managed in https://gitlab.suse.de/OPS-Service/salt/ from anything but the QE production networks like oqa.prg2.suse.org and qe.prg2.suse.org.

Acceptance criteria¶

• AC1: firewall on network level prevents direct ssh+vnc access from outside, i.e. normal office networks, to openQA test VMs, e.g. s390kvm080.oqa.prg2.suse.org…s390kvm099.oqa.prg2.suse.org
• AC2: openQA svirt jobs are still able to access ssh+vnc as necessary, e.g. from openQA workers in the same network OR openQA workers on the hypervisor hosts themselves
• AC3: Administrators can still access ssh+vnc of production machines within oqa.prg2.suse.org, e.g. openQA worker hosts and hypervisor hosts (but not test VMs)

Suggestions¶

• Take openQA svirt worker instances related to one hypervisor host, e.g. s390zl12, out of production for testing
• Create IT ticket according to https://progress.opensuse.org/projects/qa/wiki/Tools#SUSE-IT-ticket-handling and ask for the network-level firewall to block ssh+vnc to VMs running on s390zl12+13, e.g. s390kvm080.oqa.prg2.suse.org…s390kvm099.oqa.prg2.suse.org
• Allow traffic from other hosts in oqa.prg2.suse.org
• Ensure that openQA tests still work, e.g. the login to the target SUT VM in "boot_to_desktop". Use for verification
  • https://openqa.suse.de/tests/latest?machine=s390x-kvm&test=extra_tests_bootloader
  • https://openqa.suse.de/tests/latest?machine=s390x-kvm&test=default
• Ensure that the solution at least applies to s390kvm080.oqa.prg2.suse.org…s390kvm099.oqa.prg2.suse.org