🛠 Non-trivial Reco for networking and repository management

Today I want to continue the previous topic and share with you materials on segmentation and repository management.

We will look at the control of repositories at the access level later together, and yes, we will look at the roles from the information security side. We'll take what we can get out of the box at CE. You can always make a custom one 🙃

Segmentation and connectivity

1 - GitLab CE:

— bastion nodes: admin access (Web, SSH for root/maintenance) only from jump hosts

— Inbound: HTTPS (443)/SSH (22) from working subnets, runner segment

— Outbound: only to corporate SMTP, monitoring/logs, internal Nexus/registry, external Internet via proxy if necessary, dependencies, with explicit egress‑ACL

2 - GitLab Runner (infrastructure runners, not shared in DMZ):

— Placement in a separate segment “CI‑runner zone” with Outbound access to GitLab via HTTPS/SSH (API for registration, receiving jobs, push artifacts)

— Placement in a separate segment “CI‑runner zone” with Outbound access to Nexus/other artifact repository only on the necessary ports (for example, 8081/8082 for HTTP(S))

— Prohibition of direct access of runners to combat databases and internal business services, except for stands that are clearly necessary for testing

— Outbound to the Internet — through a proxy and only for downloading dependencies/vulnerability databases; use mirrors in Nexus if possible

— Inbound to runners: closed (only initiative from the runner to GitLab/Nexus); control connection runner → GitLab over HTTPS

3 - Nexus/artifact repository:

— Inbound: access only from the runners segment and, if necessary, from the assembly servers/release orchestrators segment

— Outbound: to external central repositories (Maven Central, PyPI, npm, etc.) through a controlled proxy; to the Internet - only through egress filtering and inspection

Repository Management Practices

- When building ACLs, use the principle of white lists: everything that is not explicitly allowed is prohibited

- Network traffic between all VLAN segments should be denied by default

- Administrative access (SSH, RDP, DB access, etc.) to all nodes in all segments should be allowed only from a specially designated Management VLAN management segment

- A clear classification of all projects must be observed in accordance with the level of data confidentiality: Private (confidential data), Internal (internal information), Public (open data)

- Project visibility cannot be less strict than the parent group's visibility

- Non-privileged users should be able to create only Private repositories

- Force push should be prohibited in protected branches

- A merge request should only be executed if all checks have been successfully passed

- It is recommended to include a commit signature verification step in the CI/CD pipeline

- CI/CD artifacts should be stored in corporate encrypted storage with a lifetime limit (Example S3)

- Access to changing the CI/CD configuration should be strictly limited, and the changes themselves should be monitored

- Tag protection must be used to control deployment and release of versions

- Jobs that work with secrets or build for production must run on dedicated runners with strict access control

- Visibility of secrets stored in CI/CD variables should be “masked and hidden”

- It is recommended to centrally store all build stage logs and pipeline event logs for subsequent audit and analysis

Total: we continue to give examples so that you can apply them and see in practice how usable it will be for you.

#appsec #devsecops #reco #pmcases #toolchain