Add support for GitLab tokens

[dlorenc]

It looks like GitLab offers JWT tokens as well to CI jobs:

https://docs.gitlab.com/ee/ci/examples/authenticating-with-hashicorp-vault/#how-it-works

They're available as the CI_JOB_JWT environment variable, and the endpoint is https://gitlab.example.com/-/jwks.

It sounds like they don't support the audience field, which isn't great but should still be workable.

[dlorenc]

cc @colek42

[colek42]

It looks like this is a premium feature for GitLab as well.

[dlorenc]

Hmm, over here it says it might be in all job tiers: https://docs.gitlab.com/ee/ci/secrets/

[mattmoor]

curl https://gitlab.com/.well-known/openid-configuration

{
  "issuer": "https://gitlab.com",
  "authorization_endpoint": "https://gitlab.com/oauth/authorize",
  "token_endpoint": "https://gitlab.com/oauth/token",
  "revocation_endpoint": "https://gitlab.com/oauth/revoke",
  "introspection_endpoint": "https://gitlab.com/oauth/introspect",
  "userinfo_endpoint": "https://gitlab.com/oauth/userinfo",
  "jwks_uri": "https://gitlab.com/oauth/discovery/keys",
  "scopes_supported": [
    "api",
    "read_user",
    "read_api",
    "read_repository",
    "write_repository",
    "read_registry",
    "write_registry",
    "sudo",
    "openid",
    "profile",
    "email"
  ],
  "response_types_supported": [
    "code",
    "token"
  ],
  "response_modes_supported": [
    "query",
    "fragment"
  ],
  "grant_types_supported": [
    "authorization_code",
    "implicit",
    "password",
    "client_credentials",
    "refresh_token"
  ],
  "token_endpoint_auth_methods_supported": [
    "client_secret_basic",
    "client_secret_post"
  ],
  "subject_types_supported": [
    "public"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256"
  ],
  "claim_types_supported": [
    "normal"
  ],
  "claims_supported": [
    "iss",
    "sub",
    "aud",
    "exp",
    "iat",
    "sub_legacy",
    "name",
    "nickname",
    "email",
    "email_verified",
    "website",
    "profile",
    "picture",
    "groups",
    "groups_direct"
  ]
}

[mattmoor]

It looks like it doesn't support configuring aud (e.g. to sigstore)

[dlorenc]

It looks like it doesn't support configuring aud (e.g. to sigstore)

Yep, I think it's up to us to decide if that's too problematic to add support. We can use the gitlab audience here if we want to.

[mattmoor]

That feels like a slippery slope. Once we allow it, it's hard to take back and ~every other piece of Vault OIDC documentation I've seen uses aud: vault. Github as precedent might help here.

[valdisrigdon]

GitLab 14.6 looks to be shipping with an updated token -- CI_JOB_JWT_V2. See https://gitlab.com/gitlab-org/gitlab/-/merge_requests/72555. It doesn't look like aud is configurable though.

[haydentherapper]

Following along, it looks like customizable audiences isn't coming in 15.0 - https://gitlab.com/groups/gitlab-org/-/epics/7335

[Brcrwilliams]

Hi 👋 GitLab team member here. We're working on making the aud claim configurable via https://gitlab.com/gitlab-org/gitlab/-/issues/356986. Currently, this is scheduled for 15.2 which releases on June 22, but this is subject to change. I recommend following the issue for updates on progress.

[dlorenc]

Amazing news!

[olearycrew]

@dlorenc another GitLab team member here - this is a really exciting project so I'll be tracking as well as I'd love to get this working and show it off to the community. :smile:

[nsmith5]

@Brcrwilliams and @olearycrew do you have some initial ideas for which claims from your OIDC token you might want to map into certificate extensions? You can see the claims that are mapped from Github Actions tokens here: https://github.com/sigstore/fulcio/blob/main/docs/oid-info.md

Mapping these OIDC claims to x509 extensions allows folks to write meaningful policy like

only run containers signed by the Fulcio with the Gitlab issuer and from project "foo/*"

Once we have that solidified, setting up Fulcio support for Gitlab tokens will be super straight forward and we'll all be doing keyless signing in Gitlab in no time :D

[Brcrwilliams]

@nsmith5 Currently we provide several claims in this JWT which are documented under Connect to Cloud Services. I think these ones would be useful for policies:

• namespace_id
• namespace_path
• project_id
• project_path

These would allow you to assert that the image was signed by a specific project or organization (A namespace is a group).

[haydentherapper]

To be in sync with GitHub Actions-bound certificates, we'd also want to include information about the CI workflow that was run. I believe that's pipeline_id or pipeline_source.