GitLab

GitLab is a DevOps platform for source code and CI/CD. This connector brings in the members of a GitLab.com group, including whether each has two-factor authentication enabled.

Beta. This connector was built from GitLab’s documentation and hasn’t been verified against a live account yet. It may return incomplete data or fail in ways we haven’t seen. If something looks wrong, contact [email protected].

At a glance

Before you start

• This connector supports GitLab.com only. Self-managed GitLab and GitLab Dedicated are not supported yet.
• Use a top-level group (a group that isn’t inside another group). Its ID is shown on the group’s overview page, or you can use its path, such as acme.
• Use an Owner token if you can. Owner access is what lets GitLab show each member’s two-factor status, and it is required to include people who belong only to a subgroup or a project. With a lower role the sync still works, but those details are missing.

Setup

Create one of these tokens, with only the read_api scope:

• A group access token (recommended): on the group, go to Settings → Access tokens, choose Add new token, pick any role, and select only read_api. On GitLab.com this needs a Premium or Ultimate subscription, and an Owner creates it.
• A personal access token: for a dedicated user who is a member of the group, go to Edit profile → Access tokens and create one with only read_api. Use this if your plan doesn’t include group access tokens.

Then in Navigator:

1. Go to Connectors → Add a Connector → GitLab.
2. Enter the group ID or path and the access token, then save. Navigator validates the credentials and enqueues a first sync immediately.

GitLab’s own guides: Group access tokens, Personal access tokens.

Tokens expire. GitLab sets a 365-day limit by default. When the token expires, the sync starts failing, so create a new one and save it here before then.

What data this connector provides

• Users: every person with access to the group, with username, name, email when GitLab shows it, whether the account is active (or blocked, deactivated or banned), and whether two-factor authentication is enabled.

Known limitations

• Email addresses are shown only for some users. GitLab reveals a member’s email to a group Owner only for enterprise users, so many users have a username and name but no email.
• Two-factor status is unknown for anyone GitLab didn’t report it for. Navigator shows those as unknown rather than as “no MFA”.
• Members of subgroups and projects only (not members of the group itself) are included only with an Owner token on a top-level group, and only as users with unknown two-factor status. Without that, the sync notes that they were left out.
• Bot users created by access tokens are not synced.
• A user’s group role (Guest, Developer, Maintainer, Owner) is not shown in Navigator yet.
• Projects, repositories, runners, dependencies and vulnerability findings are not provided. Dependency and vulnerability data needs GitLab Ultimate and isn’t covered yet.

Troubleshooting

• The sync fails with a message that the source rejected the saved credentials. The token is wrong, expired or revoked. Create a new one with the read_api scope and save it here.
• The sync fails with a message that access was denied. The token is valid but lacks permission. Make sure it has the read_api scope.
• The sync fails with a generic “internal error” message. The most likely cause is a wrong group ID or path, or a token whose user isn’t a member of that group: GitLab answers “not found” for a group it won’t show you. Check the group and the token’s membership.
• Users appear but without two-factor status or email. Use an Owner token.