doc/security/hardening_general_concepts.md
General hardening guidelines are outlined in the main hardening documentation.
The following documentation summarises some of the underlying philosophies for GitLab instance hardening. In many cases they can actually apply to all computer systems.
If there are two ways to implement security, both ways should be implemented instead of just one. A quick example is account security:
Instead of using only one or two items on the list, use as many as possible. This philosophy can apply to other areas besides account security - it should be applied to every area possible.
Security through obscurity means that one does not discuss certain elements of a system, service, or process because of a fear that a potential attacker might use those details to formulate an attack. Instead, the system should be secured to the point that details about its configuration could be public and the system would still be as secure as it could be. In essence, if an attacker learned about the details of the configuration of a computer system it would not give them an advantage. One of the downsides of security through obscurity is that it can lead to a potential false sense of security by the administrator of the system who thinks the system is more secure than it actually is.
An example of this is running a service on a non-standard TCP port. For example the default SSH daemon port on servers is TCP port 22, but it is possible to configure the SSH daemon to run on another port such as TCP port 2222. The administrator who configured this might think it increases the security of the system, however it is quite common for an attacker to port scan a system to discover all open ports, allowing for quick discovery of the SSH service, and eliminating any perceived security advantage.
As GitLab is an open-core system and all of the configuration options are well documented and public information, the idea of security through obscurity goes against a GitLab core value - transparency. These hardening recommendations are intended to be public, to help eliminate any security through obscurity.
GitLab is a large system with many components. As a general rule for security, it helps if unused systems are disabled. This eliminates the available "attack surface" a potential attacker can use to strike. This can also have the added advantage of increasing available system resources as well.
As an example, there is a process on a system that fires up and checks queues for input every five minutes, querying multiple sub-processes while performing its checks. If you are not using that process, there is no reason to have it configured and it should be disabled. If an attacker has figured out an attack vector that uses this process, the attacker might exploit it despite your organization not using it. As a general rule, you should disable any service not being used.
In larger but still hardened deployments, multiple nodes are often used to handle the load your GitLab deployment requires. In those cases, use a combination of external, operating system, and configuration options for firewall rules. Any option that uses restrictions should only be opened up enough to allow the subsystem to function. Whenever possible use TLS encryption for network traffic.