Every customers' deployment and configuration of GitLab is unique. The security settings that you configure will vary greatly depending on your use case, risk assessment, and your environment.
How does one get started? GitLab has you covered! We have a lot of information on security settings for both GitLab SaaS and GitLab Self-Managed instances in our Docs pages. Our Docs pages also offer a wealth of hardening recommendations for self-managed instances, and many of these settings apply to GitLab SaaS instances as well.
Looking for a consolidated list of hardening recommendations? Use the links below to view our quick-access hardening guides for GitLab Self-Managed and GitLab SaaS instances.
Admin > Settings > General > Sign-in restrictions
Admin > Settings > General > Sign-up restrictions
Admin > Settings > General > Visibility and access control
Admin > Settings > General > Visibility and access control
Typically, under Enabled Git access protocols it will be set to Both SSH and HTTP(S). If one of the Git protocols is not in use by your users, set it to either Only SSH or Only HTTP(S) accordingly. This will reduce the attack surface by limiting possibilities of compromise through an unused protocol. For SSH key types, the most recommended algorithms to use are, in order:
Admin > Settings > General > Account and limit settings
Admin > Settings > CI
Admin > Settings > CI
Many security-related settings can be set on the top-level group and will cascade down into all subgroups and projects. They are the easiest and most important in securing your GitLab.com instance.
In the top-level group, the following settings should be applied to provide the best security for the code within that group:
This is likely the most important setting among general settings. By marking the group “private", anyone who is not explicitly a member of the group will not be able to access it. Additionally, by making the top-level group private, all subgroups and projects will also be private and cannot be exposed.
Under permissions:
Merge request approvals help prevent injection of malicious code into the repository by having people other than the author review them. Enable merge request approvals for all projects in your group to:
To more tightly control who can access your code in GitLab.com, set up SAML SSO. This will ensure that everyone who accesses it is approved by someone in authority.
Regularly and periodically review the compliance reports to verify who is approving merge requests and what MRs are getting approved.
Set up streaming group audit events to your corporate security information and event management (SIEM) system and monitor them for unusual activity. This needs to be repeated for each group and project in the hierarchy to get the maximum number of audit events.
Setting restrictive push rules at the group level will help ensure malicious code is not injected into the repository:
The following settings can help insure the integrity of CI/CD pipelines and reduce the opportunities for abuse and malice:
Some settings do not cascade down from the group or are not available at the group level and must be set on individual projects instead. These include some repo-specific settings.
Set up protected branches and protected tags to go along with the protected runners and protected variables defined above.
Use protected environments and tightly limit who can deploy and require approvals for deploying.
Restrict access to this project’s CI_JOB_TOKEN to only individual projects to ensure malicious projects to not retrieve the token and use it to access the API.
Store keystores, provisioning profiles and signing certificates in the Secure Files storage rather than the repository.
As an alternative to the security testing section above, you may choose to enable scan execution policies. Enable test scan result policies to prevent merging code with critical vulnerabilities.
Following these best practices will help ensure that your code hosted on GitLab.com is safe from tampering and public exposure and that your software supply chain is secure and only authorized users are accessing your software assets.
When you visit any website, it may store or retrieve information on your browser, mostly in the form of cookies. This information might be about you, your preferences or your device and is mostly used to make the site work as you expect it to. The information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies. Click on the different category headings to find out more and change our default settings. However, blocking some types of cookies may impact your experience of the site and the services we are able to offer.
Cookie Policy
These cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, enabling you to securely log into the site, filling in forms, or using the customer checkout. GitLab processes any personal data collected through these cookies on the basis of our legitimate interest.
These cookies enable helpful but non-essential website functions that improve your website experience. By recognizing you when you return to our website, they may, for example, allow us to personalize our content for you or remember your preferences. If you do not allow these cookies then some or all of these services may not function properly. GitLab processes any personal data collected through these cookies on the basis of your consent
These cookies allow us and our third-party service providers to recognize and count the number of visitors on our websites and to see how visitors move around our websites when they are using it. This helps us improve our products and ensures that users can easily find what they need on our websites. These cookies usually generate aggregate statistics that are not associated with an individual. To the extent any personal data is collected through these cookies, GitLab processes that data on the basis of your consent.
These cookies enable different advertising related functions. They may allow us to record information about your visit to our websites, such as pages visited, links followed, and videos viewed so we can make our websites and the advertising displayed on it more relevant to your interests. They may be set through our website by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant advertisements on other websites. GitLab processes any personal data collected through these cookies on the basis of your consent.