A more general advice for hardening servers: Do not expose service ports, unless explicitly necessary (ssh, https). Do not expose database services, work locally. For monitoring purposes, a local agent that connects to the database using a unix socket can be considered more secure than a monitoring server with a service login via remote connection. As additional context, I maintained an OSS monitoring tool for 10+ years before joining GitLab.
As an attacker, a network port scan using nmap and friends immediately unveils potential attack vectors. Some environments could use default user/password settings, and boom, I am in the database, running a dump, or maybe even manipulating data.
The PostgreSQL server bundled with GitLab in the Omnibus package uses the Unix socket by default, and not a TCP socket listening on localhost. If you want to bring your own PostgreSQL server, it is advisable to use Unix sockets too, unless your database ops team provides a PostgreSQL cluster which they maintain and secure.
If you prefer to maintain your own PostgreSQL instance or cluster for hardening, and scaling, you can also do that. Configuring PostgreSQL for scaling | GitLab
I would defer here to more PostgreSQL security generic documentation for specific hardening.
Hardening can also mean that your environment blocks the usage of specific libraries or software being installed. If you encounter a blocker with GitLab Omnibus here, I’d suggest opening an issue in the project GitLab.org / omnibus-gitlab · GitLab to discuss with the engineering team.
Thanks for the context. I do not have fail2ban running with GitLab Nginx, but with defaults on my Linux VMs. The configuration looks good.
No, GitLab assumes that port 22 is being used, which is the default on a Linux distribution. If you want to use a different port, you can configure it using the gitlab_shell_ssh_port setting for the Omnibus package.
The login page requires a username and password, and does not need extra security. HTTPS is suggested, I highly recommend disabling HTTP/80 everywhere.
What you can and should do, is changing the administrative account password immediately, and add 2FA. Store the password in a password safe, and do not use the account to make administrative changes. Instead, assign user roles for administrative tasks, and use admin mode (recommended by @grove above). Sign-in restrictions | GitLab
It is also advisable to connect GitLab auth with an existing SSO/LDAP/AD instance, and ensure that permissions and groups are synced. Review the options in GitLab authentication and authorization | GitLab Disable user signup on the instance, too.
Suggest reviewing all sections in Secure your installation | GitLab