Skip to content

Allow users to customize their JWT sub claim (MVC)

Specific sub claims covered under this issue:

  1. project_path
  2. ref_type
  3. ref

Updated Proposal (MVC)

The proposal outlined here is for an MVC; we will add additional capabilities in subsequent iterations. For our MVC, we are proposing:

  1. API (Backend only) implementation. There will not be a frontend option for customizing the sub claim.
  2. Customization will be at the project level. Group/instance/job level will need to be evaluated separately as these have different implication (i.e. inheritance, security).
  3. This feature requires the user to have a Maintainer or higher role.
  4. The sub claim can be customized to include any of the attributes already provided per our docs
  5. Error handling: if any part of the sub claim is not supported/has error, 400 - bad request is returned. More detailed error messaging will be part of future iteration if required.
  6. Customization means overwriting of any existing claims. For example, if branch is not required, omitting branch from the sub claim even though it is part of the GitLab default.

Out of scope:

  • group and instance level implementation, inheritance (these will be separate issues)
  • frontend option to customize sub claim
Previous proposals and additional description information

Proposal

The sub claim was recently introduced to support additional cloud providers. It currently has group, project, and ref (branch/tag) support. While the JWT token includes the environment, Vault is one of the only providers that can support any attributes passed in the jwt token.

AWS only supports a few claims(sub, iss, aud) - see comment here. I see two possible routes:

Proposal 1: Append environment onto sub (our preferred option)

(based on #360592 (comment 1219141126)) Allow users to customize their sub claim using only the available claims in the token, making the sub claim configurable via the API, this way we can ensure that there would be no option for users to inject customized values to the claim (to avoid impersonation).

Open question - which role/privilege will have the ability to customize the sub claim

Proposal 2: Append environment onto sub.

Workflow would be the following

  1. If no environment is defined, default to: project_path:mygroup/myproject:ref_type:branch:ref:main.
  2. If environment defined, append environment name: project_path:mygroup/myproject:ref_type:branch:ref:main:environment:production
  3. If environment is protected, append environment name and protected flag: ``project_path:mygroup/myproject:ref_type:branch:ref:main:environment:production:environment_protected:true`
Proposal 3: Allow input of sub variable (should not be implemented)

Proposal 2: Allow input of sub variable based on this proposal here.

job_name:
  secrets:
    CI_JOB_JWT: # or any other variable name
      id-token:
        sub: "..." # string
*This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.*
Edited by Jocelyn Eillis