Permissions & security - GitLab

For data security, encryption, and credential storage information that applies across all connectors, see Data & Security - Enterprise Search Connectors.

Our approach to permissions

• The connector uses a Personal Access Token (PAT) with the minimum read scopes GitLab allows for indexing merge requests, issues, wikis, and project membership data.

• Content indexed is limited to projects accessible to the Personal Access Token account.

• The connector never writes to or modifies data in GitLab.

• Credentials are stored encrypted and are never exposed in logs, search results, or the Simpplr UI after initial entry.

Credential scope

Auth type: Personal Access Token (PAT)

The GitLab user account that generates the token must be granted all of the following read-only scopes:

The GitLab account associated with the token must have access to every project and group you intend to index. Content outside that account's visibility is not indexed.

Understanding the credential scope

The connector requires all three read-only scopes above. Together they provide the minimum access GitLab allows for listing and retrieving projects, merge requests, issues, wiki pages, project members, and user profiles — without granting write, update, or delete permissions.

read_api

Why it's required: Grants read-only access to GitLab REST API endpoints used to list and retrieve projects, merge requests, issues, wikis, and project memberships.

What the connector actually does with it: Read-only API calls only. The connector performs no write, update, or delete operations in GitLab.

Guardrails: The connector's sync pipeline only reads data. All connector activity is visible in the sync dashboard at Enterprise Search → GitLab → Status.

If not granted: The connector cannot list or retrieve most GitLab content.

read_repository

Why it's required: Grants read access to repository metadata required for wiki page retrieval and related project content.

What the connector actually does with it: Read-only access to repository and wiki metadata. No commits, branches, or file contents are indexed.

Guardrails: The connector's sync pipeline only reads data. All connector activity is visible in the sync dashboard at Enterprise Search → GitLab → Status.

If not granted: Wiki pages and related repository metadata cannot be indexed.

read_user

Why it's required: Grants read access to user profile information, including email addresses, used to resolve GitLab identities.

What the connector actually does with it: Reads user profile fields (including email) needed to map GitLab users to enterprise identities. No user data is modified.

Guardrails: The connector's sync pipeline only reads data. All connector activity is visible in the sync dashboard at Enterprise Search → GitLab → Status.

If not granted: Connector cannot resolve user identities; access control enforcement may be incomplete.

For setup steps, see Setup - GitLab.

Versions and editions supported

• Supported: GitLab Enterprise accounts only — GitLab.com (SaaS) or self-managed GitLab Enterprise instances with REST API access. Enterprise is required because user email addresses, used for permission sync identity matching, are only available through the GitLab API on Enterprise accounts.

• Not supported: Non-Enterprise GitLab editions (user emails are not available via the API), or GitLab instances where API access is blocked by network policy or where the token account cannot reach target projects

Permission design

How permissions work

GitLab permissions are project-based. Merge requests, issues, and wikis inherit access from their parent project. The connector reads project visibility and effective project memberships, then enforces them in Simpplr Enterprise Search at query time. Users only see content they already have access to in GitLab.

• User and group sync: GitLab user identities (matched by email from the GitLab API) and effective project memberships (including memberships inherited from groups and subgroups) are synced. When a user is added to or removed from a project or group in GitLab, the change is reflected in Simpplr after the next sync.

• Item permission changes: When a project's visibility or membership changes in GitLab, the change is picked up by the next incremental sync for merge requests and issues, and by the next full sync for wikis.

• Public and internal projects: Public projects are searchable by anyone with connector access. Internal projects are searchable by authenticated GitLab users on the instance. Private projects are searchable only by project members.

• Access removal: When a user loses access to a project in GitLab, that project's content stops appearing in their Simpplr search results after the next sync completes.