## Problem to Solve - Currently, we do not have a reliable way to identify inside which project a CI job ran, purely from the ID Token JWT - Refer to [this long thread](https://gitlab.com/gitlab-org/gitlab/-/issues/561735#note_2694941153) to get the background context - Refer to [this issue](https://gitlab.com/gitlab-org/security/gitlab/-/issues/1384) to understand the security vulnerability that existed related to CI ID Tokens from MR pipelines originating from forked projects but running inside target project ### If TLDR above - In [this commit](https://gitlab.com/gitlab-org/gitlab/-/commit/7e9f329e8f6a33ffe3a63f8f64016d9b35b06a09) we patched a security vulnerability related to CI ID tokens for Merge Request Pipelines originating from forked projects but running inside target project - Before the security patch was made, we had `project_` related claims like `project_id:`, `project_path:`, `namespace_id:`, `namespace_path:` which ALWAYS returned the project inside which the build and it's pipeline is running. - The security vulnerability was patched by updating the value of these `project_` related claims to refer to the forked project and NOT the target project, if the pipeline is of a Merge Request originating from forked projects EVEN it's pipeline is running inside target project. - Because of the change above, now we have a situation wherein there is no reliable way from the JWT payload to tell inside which project the pipeline and job ran. In the specific case of Merge Request Pipelines originating from forked projects but running inside target project, the `project_` related claims DO NOT refer to the actual project inside which the pipeline ran, but rather it refers to the source project of the Merge Request. This inconsistency is causing the problem mentioned in this point. i.e. `there is no reliable way from the JWT payload to tell inside which project the pipeline and job ran` - To solve this, we need to add a new set of claims called `job_project_` claims - `job_project_id:`, `job_project_path:`, `job_namespace_id:`, `job_namespace_path:`. These 4 additional claims will always reliably have the values corresponding to the project in which the pipeline is created WITHOUT any exception. - Only for the specific case of Merge Request Pipelines originating from forked projects but running inside target project, the values of `job_project_` claims differ from the corresponding values of `project_` claims. For all other cases, the `project` (Read as source_project) and `job_project` are one and the same - Also, need to update the [existing doc on ID token payload](https://docs.gitlab.com/ci/secrets/id_token_authentication/#token-payload) ## Implementation plan - Update [JWT class](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/jwt.rb) to add 4 new claims `job_project_id:`, `job_project_path:`, `job_namespace_id:`, `job_namespace_path:` - Update the [docs](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/ci/secrets/id_token_authentication.md) to add docs on new claims - For the docs on existing claims, make changes so that they make sense with the addition of new claims - Add missing information on the `ref` related claims and also `ci_config_ref` related claims for cross project MRs.