openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842024-03-28T19:30:27ZopenSUSE Project Management Tool
Redmine openQA Infrastructure - action #158242 (New): Prevent ssh access to test VMs on svirt hypervisor ...https://progress.opensuse.org/issues/1582422024-03-28T19:30:27Zokurzokurz@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>In <a href="https://sd.suse.com/servicedesk/customer/portal/1/SD-150437" class="external">https://sd.suse.com/servicedesk/customer/portal/1/SD-150437</a> we are asked to handle "compromised root passwords in QA segments" including s390zl11…16</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> firewall on OSD svirt hosts prevents direct ssh+vnc access from outside, i.e. normal office networks</li>
<li><strong>AC2:</strong> 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</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Take openQA svirt worker instances related to one hypervisor host, e.g. s390zl12, out of production for testing</li>
<li>Configure a/the firewall on that host to block ssh+vnc to VMs running on that host</li>
<li>Allow traffic from other hosts in oqa.prg2.suse.org</li>
<li>Ensure that openQA tests still work</li>
<li>Ensure that the according firewall config is made boot-persistent and in salt</li>
<li>Crosscheck with at least one reboot</li>
<li>Apply the same solution to all other OSD svirt hosts</li>
</ul>
openQA Infrastructure - action #157744 (Blocked): [spike][timeboxed:10h] Use ssh key authenticati...https://progress.opensuse.org/issues/1577442024-03-22T10:34:40Zokurzokurz@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>In <a href="https://sd.suse.com/servicedesk/customer/portal/1/SD-150437" class="external">https://sd.suse.com/servicedesk/customer/portal/1/SD-150437</a> we are asked to handle "compromised root passwords in QA segments" including s390zl11…16</p>
<a name="Goals"></a>
<h2 >Goals<a href="#Goals" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>G1:</strong> Have an s390x kvm openQA installation job with ssh key authentication instead of password succeed as far as possible</li>
<li><strong>G2:</strong> Identify which follow-up steps need to be done to fully support ssh key based authentication in such scenarios</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Take a look where os-autoinst and os-autoinst-distri-opensuse use passwords and try to find a way how to pass public ssh keys to the target s390x kvm systems and use key authentication instead of password</li>
<li>Consider trying out locally with native virtualization as that feature isn't only relevant for s390x</li>
<li>After that reserve an s390x kvm system and try it out</li>
<li>Fix obvious small problems and identify bigger follow-up tasks</li>
</ul>
openQA Infrastructure - action #157555 (Blocked): [spike][timeboxed:10h] Use a different ssh root...https://progress.opensuse.org/issues/1575552024-03-19T21:34:02Zokurzokurz@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>In <a href="https://sd.suse.com/servicedesk/customer/portal/1/SD-150437" class="external">https://sd.suse.com/servicedesk/customer/portal/1/SD-150437</a> we are asked to handle "compromised root passwords in QA segments" including s390zl11…16</p>
<a name="Goals"></a>
<h2 >Goals<a href="#Goals" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>G1:</strong> Have an s390x kvm openQA installation job with non-default password succeed as far as possible</li>
<li><strong>G2:</strong> Identify which follow-up steps need to be done to fully support non-default passwords in such scenarios</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>os-autoinst-distri-opensuse in principle supports using a different password, see <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/lib/main_common.pm#L165" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/lib/main_common.pm#L165</a></li>
<li>Clone a default s390x kvm openQA installation job <a href="https://openqa.suse.de/tests/13875911" class="external">https://openqa.suse.de/tests/13875911</a> from this scenario <a href="https://openqa.suse.de/tests/latest?arch=s390x&distri=sle&flavor=Online&machine=s390x-kvm&test=default&version=15-SP6" class="external">https://openqa.suse.de/tests/latest?arch=s390x&distri=sle&flavor=Online&machine=s390x-kvm&test=default&version=15-SP6</a> but with <code>PASSWORD=<new_password></code> with <code><new_password></code> being anything you setup temporary and see how far the test can reach</li>
<li>Fix obvious small problems and identify bigger follow-up tasks</li>
<li>Actually s390x shouldn't really matter that much in this context, could also be an "svirt" job</li>
</ul>
openQA Infrastructure - action #157468 (Feedback): Handle internal test machines with compromised...https://progress.opensuse.org/issues/1574682024-03-18T12:00:21Zokurzokurz@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>In <a href="https://sd.suse.com/servicedesk/customer/portal/1/SD-150437" class="external">https://sd.suse.com/servicedesk/customer/portal/1/SD-150437</a> we are asked to handle "compromised root passwords in QA segments" including s390zl11…16</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> All steps asked in <a href="https://sd.suse.com/servicedesk/customer/portal/1/SD-150437" class="external">https://sd.suse.com/servicedesk/customer/portal/1/SD-150437</a> have been sufficiently handled</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li><em>DONE</em> Change root password for s390zl11…16 and in sync update in <a href="https://gitlab.suse.de/openqa/salt-pillars-openqa/-/blob/master/openqa/workerconf.sls" class="external">https://gitlab.suse.de/openqa/salt-pillars-openqa/-/blob/master/openqa/workerconf.sls</a></li>
<li><em>DONE</em> Ensure according tests work</li>
<li><em>DONE</em> Ask wegao about their personal machine also referenced</li>
<li><em>DONE</em> Find a working solution covering s390kvm080…099 -> see related tickets</li>
<li>Depending on response in <a href="https://sd.suse.com/servicedesk/customer/portal/1/SD-150437" class="external">https://sd.suse.com/servicedesk/customer/portal/1/SD-150437</a> either resolve this ticket or block on sibling tasks, e.g. new password for s390x openQA tests, rotating password, ssh key based authentication and/or more secured network</li>
</ul>
openQA Infrastructure - action #125750 (Resolved): In salt-states-openqa support machines requiri...https://progress.opensuse.org/issues/1257502023-03-10T07:20:47Zokurzokurz@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>openqaw5-xen requires login of root with password over ssh for openQA tests, see <a href="https://gitlab.suse.de/openqa/salt-pillars-openqa/-/blob/master/openqa/workerconf.sls#L138" class="external">https://gitlab.suse.de/openqa/salt-pillars-openqa/-/blob/master/openqa/workerconf.sls#L138</a>, hence we can not directly apply <a href="https://gitlab.suse.de/openqa/salt-states-openqa/-/blob/master/sshd/sshd_config#L44" class="external">https://gitlab.suse.de/openqa/salt-states-openqa/-/blob/master/sshd/sshd_config#L44</a></p>
<pre><code>PermitRootLogin without-password
</code></pre>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> openqaw5-xen can be controlled by salt while allowing root-ssh-password login</li>
<li><strong>AC2:</strong> By default all machines in salt still prevent password authentication in salt</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li><em>Optional:</em> We could temporarily change to allow password login over ssh</li>
<li>Find a way to allow individual machines root-ssh-password login</li>
<li><em>Optional:</em> Adapt os-autoinst backend to support ssh key login</li>
<li>Ensure by default machines still apply <code>PermitRootLogin without-password</code></li>
</ul>
<a name="Rollback-steps"></a>
<h2 >Rollback steps<a href="#Rollback-steps" class="wiki-anchor">¶</a></h2>
<ul>
<li>Add openqaw5-xen back to salt and ensure a high state can be applied while still allowing password login for root on this machine</li>
</ul>