Table of contents
Layered security, defense in depth
7 steps to ensure the security of private deployment instances
Step 1: Turn on multi-factor authentication
Step Two: Enhance Additional Registration Checks
Step Three: Restrict Group and Project Visibility
Step Four: Harden SSH Settings
Step Five: Review Account and Limit Settings
Step 7: Protect the pipeline of all branches
Source of this article: about.gitlab.com
By Ayoub Fandi
Translator: Content Team of GitLab Marketing Department
"The security of the system depends on the weakest link of the system" is a very easy-to-understand proverb, just like the barrel effect of security protection.
If an attacker finds a way to break in, any gaps in the security configuration file will be exploited. "Hardening", the process of turning off unused features and adjusting settings that affect security, is very important in limiting the attack surface and reducing potential attack vectors.
"Hardening" ensures that applications (such as Jihu GitLab) are as secure as possible. The goal is simple: minimize risk while retaining the functionality you need to be productive.
Guidelines
The security activities listed below need to be used in combination with one or more of them. You can try to combine as many methods as possible.
Layered security, defense in depth
The logic behind layered security is simple: try to combine as many security methods as possible . For example, if there are two ways to implement security, implement both, not just one.
For example, if you want to secure access to services, you can combine complex passwords, hardware access tokens, and multi-factor authentication. This approach is also known as defense in depth .
Confidentiality ≠ Security
The idea that "something is more secure if it's hidden" doesn't work in today's information security world.
The current attacker's scanning capabilities are strong enough to break through strict security controls. It is very easy for anyone to scan the open ports of the system. For example, if port 22 of SSH is modified to other ports, network tools such as Nmap can scan them out.
Reduce attack surface
Jihu GitLab/GitLab includes many components, services and dependencies, providing powerful product functions. But the more components you have, the more entry points for an attacker . So keep in mind a rule: disable services that are not needed to run the application . If there are unused features, disabling related services will reduce the potential attack surface and be more secure.
7 steps to ensure the security of private deployment instances
Let's quickly harden a privatization deployment instance through 7 simple steps. These quick-impact measures are an important start to ensuring security. For additional details and further guidance, refer to the official documentation .
Step 1: Turn on multi-factor authentication
Admin → Settings → General → Login Restrictions
Make sure to check the Two-Factor authentication (2FA) option. The default value of the two-factor grace period is 48h, adjust it to a lower value, such as 8h.
Make sure to check Administrator Mode . Users with administrator access will require additional authentication to perform administrative tasks. After enabling 2FA, users will be required to perform additional 2FA authentication operations.
Step Two: Enhance Additional Registration Checks
Admin → Settings → General → Registration Restrictions
Make sure to check Enable Registration.
Under Email Confirmation Settings, confirm that Advanced Settings is turned on. This will require users to verify their email addresses during the registration process before allowing access to their accounts.
If other authentication techniques are enforced, the default setting of 12 characters minimum password length (number of characters) is appropriate. Available password complexity options include numbers, uppercase and lowercase letters, and special characters. Whether to enable the password complexity feature depends on your company's internal password standards.
If all user email addresses are located under a single domain name (eg example.com ), add it to the Allowed Domains section in Registration Restrictions. This will prevent mailboxes not under this domain from registering.
Step Three: Restrict Group and Project Visibility
Admin → Settings → General → Visibility and Access Control
For newly created projects and groups, the default project visibility and group visibility should both be set to private . Only users who have been granted specific access rights can access specific resources. This can be adjusted if necessary or when creating new projects or groups.
This keeps the default mode safe and prevents accidental disclosure of information.
Step Four: Harden SSH Settings
Admin → Settings → General → Visibility and Access Control
Usually, select Both SSH and HTTP(S) in Enable Git Access Protocol. If the user does not use one of the Git protocols, set it to Only SSH or Only HTTP(S).
This can limit the potential for compromise and reduce the attack surface by limiting unused protocols. For the type of SSH key, the recommended algorithms are:
-
ED25519；
-
RSA；
-
ECDSA.
Keep the above list in mind when configuring the default type and SSH key length.
Step Five: Review Account and Limit Settings
Admin→Settings→General→Accounts and Restrictions
This section allows limiting the size of attachments, pushes, exports, imports and repositories. The specific size (MB) can be set and audited according to the company's internal policy.
User session duration (minutes) and SSH key and all access token duration (days) are also configurable to ensure duration is consistent with internal company policies and meets security best practices.
Step 6: Secure the CI key
Admin → Settings → CI
Passwords, tokens, keys, and other sensitive information that requires any level of protection should never be stored in plain text. Instead, an encrypted container technology (key manager) should be implemented , such as GCP Secret Manager and HashiCorp Vault, many GitLab features of GitLab can utilize Vault.
For external communication, ensure that any external connections in the CI/CD process use encrypted channels. It is strongly recommended to use TLS 1.2 and above, and mTLS where possible.
Step 7: Protect the pipeline of all branches
Admin → Settings → CI
A pipeline is a part of a job that executes steps in stages, automating tasks on behalf of the user, and is a core component of CI/CD. By default, only the default branch will get a protected pipeline. Following these simple steps and configuring the same level of security for other branches will greatly strengthen your pipeline.
Once the pipeline is running, the code is deployed to an environment. To restrict interaction with this environment and protect it from unauthorized users, set critical environments to Protected.
This article explains how to strengthen and strengthen the privatized deployment of GitLab/GitLab instances in GitLab from different dimensions. If you want to learn more about how Jihu GitLab/GitLab ensures security, you can refer to the security documentation , hoping to help you.