action #159066
Updated by okurz 7 months ago
## 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 networks
* **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
Back