QA

Motivation¶

The SUSE Cybersecurity team plans to provide better network segmentation to improve security. Proposals exist e.g. on https://confluence.suse.com/pages/viewpage.action?pageId=952173193 and https://confluence.suse.com/pages/viewpage.action?pageId=1006108843 .
mgriessmeier and nsinger and okurz had a meeting with Lazaros Haleplidis on 2022-09-15. We should now plan which systems and services need which security rules, e.g. which ports accessible, etc.

Acceptance criteria¶

• AC1: All Nbg based QA/QAM machines are within the new security zones (including OSD machines, excluding O3 machines)
• AC2: All QA provided services continue to be operational

Suggestions¶

• Read existing materials and proposals, e.g. above mentioned confluence pages
• okurz suggests to make sure racktables Nuremberg&QA&QAM is the complete list for all the machines we need to care about
• Come up with a proposal for what network security zones we need and what security rules should apply for thos
• Provide a list of all machines with FQDN, MAC, VLAN, IPv4, IPv6 for machines as well as BMCs as required by Lazaros Haleplidis, at best readable directly from Racktables

Out of scope¶

Currently the dedicated openqa.opensuse.org network is not covered by this change. According to Lazaros Haleplidis no public facing machines which is including https://openqa.opensuse.org are touched by this.

Further details¶

1. What are your requirements that need to be fulfilled?
   All inbound traffic needs to be well defined.

2. Do we have any benefits from this change?
   Better separation within SUSE networks

3. How can the security rules be controlled?
   Creating a ticket. Automation, e.g. using terraform, etc., is evaluated

4. Do we need two networks, one for openQA and QA?
   Right now we use machines within the Eng-Infra network. We can specify requirements

5. We need HTTP communication to various hosts within the .suse.de domain. download.suse.de, gitlab.suse.de, etc.
   All of these need to be specifically specified

BMCs are planned to be accessible over jump hosts. It is planned to migrate IP access to machines first and keep IPMI till the end. Jump hosts is planned to be a Linux VM accessible over SSH from where we can access BMCs of the systems.

It is possible to have dedicated "test networks" so equivalent to our QA network where we have machines+BMCs within the same network. It might not be the suggested setup but is possible.

We meet again on 2022-09-22, 1500 CEST. Lazaros Haleplidis will invite us for 2022-09-22.