Change Details

This task is to tack the findings in the Security Readiness Reviews of Trusted GitLab Runners (T304514). The review has one LOW severity finding, no MEDIUM, HIGH or CRITICAL and 15 INFORMATIONAL. Informational meaning the test did not find any vulnerability. From the report: # 3.1 LOW - Scan of external networks using untrusted runners **Description:** It is possible to scan external devices using the gitlab runners. **Proof of concept:** A job is generated to be executed in an untrusted runner and we verified that it is possible to scan external devices without restrictions. We performed a scan to an external website from an untrusted runner using nikto, a known web scanner. A scan was performed to TCP ports 1 through 1000 to a server that has ports 80, 443 and 483 explicitly open. We observed the server could be scanned from the untrusted runner without restrictions. According to the test performed in 3, the outgoing bandwith from the runner is limited. This somewhat mitigates the impact of these scans. **Hosts/Affected endpoints:** GitLab: https://gitlab.devtools.wmcloud.org/ **Notes / Recommendation:** We recommend evaluating the implementation of certain measures, such as outgoing firewall rules, to prevent a job executing inside an untrusted runner from performing massive connections to devices in the Internet. ##Additional Context The review revealed that outgoing traffic from Shared/Untrusted Runners is not filtered or restricted. Docker containers in CI jobs can access arbitrary services, including (not only) port scanning. So the finding is not only about scanning external networks but also general access of external services (http, tcp, ssh ...). Limitations: Access to arbitrary services in **not** possible from the Trusted Runners, see chapter 3.14 in the report. Trusted Runners have more restrictive firewall settings (`profile::gitlab::runner::restrict_firewall`). It should be discussed if Shared Runners need more restrictive settings as well or if the should be more open by design. If we decided to also restrict Shared Runners, the firewall rules from Protected Runners could be adapted and re-used.

TBD (until I figured out Custom view/security policy for phab task)This task is to tack the findings in the Security Readiness Reviews of Trusted GitLab Runners (T304514). The review has one LOW severity finding, no MEDIUM, HIGH or CRITICAL and 15 INFORMATIONAL. Informational meaning the test did not find any vulnerability. From the report: # 3.1 LOW - Scan of external networks using untrusted runners **Description:** It is possible to scan external devices using the gitlab runners. **Proof of concept:** A job is generated to be executed in an untrusted runner and we verified that it is possible to scan external devices without restrictions. We performed a scan to an external website from an untrusted runner using nikto, a known web scanner. A scan was performed to TCP ports 1 through 1000 to a server that has ports 80, 443 and 483 explicitly open. We observed the server could be scanned from the untrusted runner without restrictions. According to the test performed in 3, the outgoing bandwith from the runner is limited. This somewhat mitigates the impact of these scans. **Hosts/Affected endpoints:** GitLab: https://gitlab.devtools.wmcloud.org/ **Notes / Recommendation:** We recommend evaluating the implementation of certain measures, such as outgoing firewall rules, to prevent a job executing inside an untrusted runner from performing massive connections to devices in the Internet. ##Additional Context The review revealed that outgoing traffic from Shared/Untrusted Runners is not filtered or restricted. Docker containers in CI jobs can access arbitrary services, including (not only) port scanning. So the finding is not only about scanning external networks but also general access of external services (http, tcp, ssh ...). Limitations: Access to arbitrary services in **not** possible from the Trusted Runners, see chapter 3.14 in the report. Trusted Runners have more restrictive firewall settings (`profile::gitlab::runner::restrict_firewall`). It should be discussed if Shared Runners need more restrictive settings as well or if the should be more open by design. If we decided to also restrict Shared Runners, the firewall rules from Protected Runners could be adapted and re-used.