Trusted publishing: support for GitLab CI

[woodruffw]

Per #12465 (comment): GitLab now supports a customizable aud for their CI-issued identity tokens, meaning that it should be possible to integrate them as a provider of trusted publishers!

Some initial tasks:

• Extract some GitLab OIDC tokens and inspect their claim set
• Determine the appropriate set of fields/claim constraints to expose to users

From there, the actual development tasks on this should look similar to the tasks enumerated in #13551.

[facutuesca]

I'm taking a look at this

[woodruffw]

Thanks @facutuesca! I've assigned you.

[facutuesca]

Extract some GitLab OIDC tokens and inspect their claim set

Here's one:

{
  "namespace_id": "12885807",
  "namespace_path": "user",
  "project_id": "53804090",
  "project_path": "user/oidc_test",
  "user_id": "9420787",
  "user_login": "user",
  "user_email": "user@example.com",
  "pipeline_id": "1136338956",
  "pipeline_source": "push",
  "job_id": "5919171663",
  "ref": "main",
  "ref_type": "branch",
  "ref_path": "refs/heads/main",
  "ref_protected": "true",
  "runner_id": 12270807,
  "runner_environment": "gitlab-hosted",
  "sha": "0a037033c5d88a5e5fd4d0658740c7a952b4f317",
  "project_visibility": "private",
  "ci_config_ref_uri": "gitlab.com/user/oidc_test//.gitlab-ci.yml@refs/heads/main",
  "ci_config_sha": "0a037033c5d88a5e5fd4d0658740c7a952b4f317",
  "jti": "1a78bc43-842b-42bc-994c-25c12124af5e",
  "iss": "https://gitlab.com",
  "iat": 1705066514,
  "nbf": 1705066509,
  "exp": 1705070114,
  "sub": "project_path:user/oidc_test:ref_type:branch:ref:main",
  "aud": "pypi"
}

The fields are documented in https://docs.gitlab.com/ee/ci/secrets/id_token_authentication.html#token-payload.

Since the iss will be whatever the URL of the GitLab instance is, I'm assuming that for this provider we're not supporting self-hosted instances, right? That is, for now only "iss": "https://gitlab.com" will be supported

As for which claims we want to expose to the user to configure the publisher, these would be the ones that best match the existing GitHub publisher:

{
  "project_path": "user/oidc_test",
  "ci_config_ref_uri": "gitlab.com/user/oidc_test//.gitlab-ci.yml@refs/heads/main",
  "environment": "myenvironment",
}

(environment is optional, and similar to GitHub's environments). Any thoughts on this? @woodruffw @di

[woodruffw]

That is, for now only "iss": "https://gitlab.com" will be supported

Correct, similar to GitHub with GHE (which we don't support for now) 🙂

As for which claims we want to expose to the user to configure the publisher, these would be the ones that best match the existing GitHub publisher:

Yeah, these look good to me -- we'll also want to think about binding user_id, similar to what we do for GitHub (the user gives us their name, and we use the GitHub API to retrieve the backing ID).

Looks like this is probably the relevant endpoint: https://docs.gitlab.com/ee/api/users.html#list-users -- I confirmed that https://gitlab.com/api/v4/users?username=yossarian retrieves the ID we want.

[facutuesca]

Yeah, these look good to me -- we'll also want to think about binding user_id, similar to what we do for GitHub (the user gives us their name, and we use the GitHub API to retrieve the backing ID).

@woodruffw There is an issue with this. On GitHub, the owner of a repository (either a user or an organization) is always public, so you can get the ID through their API. On GitLab though, groups (the equivalent of GH organizations) can be set to private, in which case you cannot get their ID through the API.

So, for example, if I want to configure a repo located at gitlab.com/my_group/my_repo and my_group is set to private, we cannot determine its ID to later verify against an OIDC token.

The same issue happens with project_path and project_id: if a project is set to private, we cannot determine its ID based on its owner and the project name.

As a side note, the user_id field in GitLab's token refers to the user that triggered the workflow, not the owner of the repo.