Connecting GitLab to Drata allows for the automated tests and evidence collection to prove to auditors that your company follows its software development lifecycle procedures.
Prerequisite
If your GitLab instance is not publicly available, please configure your network device with the following information.
Configure your network device to add the following IP address to port
443. The configuration is based on your internal network layout.Contact your IT team to configure and add the following IP addresses based on your region.
North America
54.190.125.76
35.83.232.49
35.164.233.77
44.230.111.50
3.132.55.182
3.16.197.217
3.18.141.25
Europe
18.196.253.2
3.73.237.1
3.64.113.104
46.51.157.29
52.50.71.20
52.211.226.244
To learn more, go to the following external resources:
Make sure you have at least 'Maintainer' access to your company's GitLab account, including your in-scope Groups and Projects.
Ensure you provide an personal access token when connecting to Gitlab. OAuth is not supported currently. The necessary permissions are:
read_apiread_user
Officially supported GitLab versions are:
v17.x,v16.x(limited support forv16.x).
MFA requirement: For enabling MFA, please reference our GitLab MFA configurations article.
If a user belongs to a group without MFA enabled, that user will appear as not having MFA in Manage Connected Version Control Accounts page in Drata.
This will also cause them to fail Test 87 - MFA on Version Control System.
Enforce MFA sync:
If MFA is enforced at the parent group level and subgroups are not allowed their own MFA setting, remove the user’s direct membership from the subgroup (ensuring they remain a member through inherited membership). After the next user sync, the MFA status will update correctly.
This is because, even though the GitLab UI indicates that the subgroup MFA is inherited from the parent group, their API returns that the subgroup doesn't have MFA turned on. Even if 2-Factor Authentication (2FA) is enforced at the parent group level and subgroups are not allowed their own 2FA settings, the GitLab REST API will still incorrectly report that 2FA is not enabled for those subgroups.
If you allow subgroups to set their own MFA, users can have both direct and inherited membership, but you must ensure MFA is enabled for every subgroup. Any direct member of a subgroup without MFA will show as not having MFA, regardless of other settings or memberships.
Verify members group membership:
You can scroll through both the group members list to find direct membership, as well as performing an actual filter/search.
Drata syncs only users with direct group membership, not those who are only direct members of projects or inherited group membership. To verify a member's group membership, follow these steps:
Navigate to the relevant Project.
In the left-hand menu under Manage select Members.
Verify "direct" or "inherited" under the Source column in the group member list.
Connect GitLab self-managed
For GitLab self-managed, the process is similar to connecting to GitLab.
Go to the Connections page.
Select the Available connections tab, then search for "GitLab self-managed" and select connect.
Enter the two additional details:
Hostname: Enter the hostname for your self-managed GitLab instance. This is typically the URL of your GitLab server (for example,
https://gitlab.yourcompany.com)Personal Access Token (PAT): Generate a Personal Access Token (PAT) in your GitLab instance with the necessary permissions (listed below). Then, enter the token in the corresponding field in Drata.
Necessary permissions for PAT:
read_apiread_user
Monitoring tests covered
Test 6: Only Authorized Employees Access Version Control
Test 7: Only Authorized Employees Change Code
Test 8: Formal Code Review Process
Test 9: Production Code Changes Restricted
Test 87: MFA on Version Control System
Test 94: Version Control Accounts Removed Properly