Skip to main content
All CollectionsConnectionsProvider
Connect GitLab on-prem
Connect GitLab on-prem
Updated yesterday

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

  • 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_api

    • read_user

  • Officially supported GitLab versions are: v17.x, v16.x (limited support for v16.x).

  • MFA requirement: For GitLab, Multi-Factor Authentication (MFA) must be enabled at the group level to be shown in Drata. Please update your GitLab settings accordingly.

  • GitLab API limitation:

    • GitLab does not expose per-user MFA through their API; they only expose the group-level MFA setting.

    • 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:

  1. Navigate to the relevant Project.

  2. In the left-hand menu under Manage select Members.

  3. 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.

  1. Go to the Connections page.

  2. Select the Available connections tab, then search for "GitLab self-managed" and select connect.

  3. 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_api

        • read_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

Did this answer your question?