Actions
action #157555
closedopenQA Project (public) - coordination #105624: [saga][epic] Reconsider how openQA handles secrets
openQA Project (public) - coordination #157537: [epic] Secure setup of openQA test machines with secure network+secure authentication
[spike][timeboxed:10h][qe-core] Use a different ssh root password for any svirt (s390, x86, etc) installation openQA jobs size:S
Status:
Rejected
Priority:
Normal
Assignee:
Category:
Infrastructure
Target version:
Start date:
Due date:
% Done:
0%
Estimated time:
Difficulty:
Sprint:
QE-Core: May Sprint 24 (May 07 - Jun 04)
Description
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
Goals¶
- G1: Have an s390x kvm (or any other svirt backend) openQA installation job with non-default password succeed as far as possible
- G2: Identify which follow-up steps need to be done to fully support non-default passwords in such scenarios
Suggestions¶
- os-autoinst-distri-opensuse in principle supports using a different password, see https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/lib/main_common.pm#L165
- Clone a default s390x kvm openQA installation job https://openqa.suse.de/tests/13875911 from this scenario https://openqa.suse.de/tests/latest?arch=s390x&distri=sle&flavor=Online&machine=s390x-kvm&test=default&version=15-SP6 but with
PASSWORD=<new_password>
with<new_password>
being anything you setup temporary and see how far the test can reach - Fix obvious small problems and identify bigger follow-up tasks
- Actually s390x shouldn't really matter that much in this context, could also be an "svirt" job
Actions