# Gitlab Trust Provider

> This page outlines the steps required to configure the Gitlab Trust Provider.

The Gitlab Trust Provider supports attestation of Client Workloads identities in a [Gitlab Jobs](https://docs.gitlab.com/ee/ci/jobs/) environment.

> **Enterprise Support**
>
> Aembit supports GitLab Cloud but doesn’t support self-hosted GitLab instances.

The GitLab Trust Provider relies OIDC (OpenID Connect) tokens issued by GitLab. These tokens contain verifiable information about the job, its origin within the project, and the associated pipeline.

## Match rules

The following match rules are available for this Trust Provider type:

| Data            | Description                                                                                                                                                                                                                                                           | Example                                                                                                                                |
| --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| namespace\_path | The group or user namespace (by path) where the repository resides.                                                                                                                                                                                                   | my-group                                                                                                                               |
| project\_path   | The repository from where the workflow is running, using the format `{group}/{project}`                                                                                                                                                                               | my-group/my-project                                                                                                                    |
| ref\_path       | The fully qualified reference (branch or tag) that triggered the job. ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/119075) in GitLab 16.0.)                                                                                                    | * refs/heads/feature-branch-1
* refs/tags/v1.2.0                                                                                       |
| subject         | The repository and Git reference from where the workflow is running. The format is `project_path:{group}/{project}:ref_type:{type}:ref:{branch_name}`, where `type` can be either `branch` (for a branch-triggered workflow) or `tag` (for a tag-triggered workflow). | - project\_path:my-group/my-project:ref\_type:branch:ref:feature-branch-1
- project\_path:my-group/my-project:ref\_type:tag:ref:v2.0.1 |

For additional information about GitLab ID Token claims, please refer to [GitLab Token Payload](https://docs.gitlab.com/ee/ci/secrets/id_token_authentication.html#token-payload).

> **Note**
>
> When using GitLab Dedicated, ensure the OIDC Endpoint is properly configured; otherwise use `https://gitlab.com`.