Map GitLab OIDC token claims to Fulcio OIDs #1097

aladh · 2023-04-05T04:45:25Z

Summary

GitLab issue: https://gitlab.com/gitlab-org/gitlab/-/issues/388517

Related to #243 and #983

Note that some of the GitLab claims added in this PR do not exist in the GitLab token yet.

Release Note

Documentation

docs/oid-info.md

haydentherapper · 2023-04-05T16:55:23Z

Thanks for working on this! If you can fill in the MUST extensions in particular, that would be very helpful!

docs/oid-info.md

aladh · 2023-04-05T19:06:31Z

docs/oid-info.md

 | iss                | iss     | iss       | iss        | Issuer                       | This already exists. For example: https://token.actions.githubusercontent.com                                                                                                          |
 | exp                | exp     | exp       | exp        | N/A                          | Only used to validate the JWT.                                                                                                                                                         |
 | nbf                | nbf     | nbf       | nbf        | N/A                          | Only used to validate the JWT.                                                                                                                                                         |
 | iat                | iat     | iat       | iat        | N/A                          | Only used to validate the JWT.                                                                                                                                                         |
-| server_url + job_workflow_ref   | ??     | ??       | ??        | Build Signer URI             | Reference to specific build instructions that are responsible for signing. Can be the same as Build Config URI. For example a reusable workflow in GitHub Actions or a Circle CI Orbs. |
+| server_url + job_workflow_ref   | server_url + project_path + /-/blob/ + ci_commit_sha + / + ci_config_path | ??       | ??        | Build Signer URI             | Reference to specific build instructions that are responsible for signing. Can be the same as Build Config URI. For example a reusable workflow in GitHub Actions or a Circle CI Orbs. |


Example URL: https://gitlab.com/gitlab-org/gitlab/-/blob/d33e88e2d80b97b0c15e5c11aaf90e17d0916fda/.gitlab-ci.yml

Should this be the same as Build Config URI?

GitHub Actions uses the job_workflow_ref, which is a ref to the workflow being used. I think the closest approximation for GitLab would be a ref for the include for the job if applicable, otherwise if it's just in the base .gitlab-ci.yml this would be the same as the build config uri.

So, the existence of include complicates this a lot. A single job may have elements of its configuration altered in multiple different places. For example, this is valid behavior:

include: '/templates/build.gitlab-ci.yml' # This job originates from build.gitlab-ci.yml build: # This script keyword overrides the one from `build.gitlab-ci.yml` script: ./my-build.sh

Additionally, include is not versioned and it could change between multiple different CI pipeline runs. The only solution I can really think of here is to persist the merged CI yaml that was used to create the pipeline, and allow that to be viewed. Ex: https://gitlab.com/:project/-/pipelines/:id/merged_yaml

Additionally, include is not versioned and it could change between multiple different CI pipeline runs.

@Brcrwilliams the immutability problem is not unique to us and it can't be solved in this context anyway. A workflow ref in GitHub Actions has no immutability guarantee either. Folks should be version pinning their include references by SHA if they want such guarantees. For local include references (like in your example) it doesn't even matter because the ref is the same as the root .gitlab-ci.yml pipeline definition.

We do need to account for custom CI/CD config file locations which can be set to anything including arbitrary remote HTTP endpoints. As such we may need to normalize this claim value to a fully qualified URI in all cases for consistency. We may need to manually checksum references to files that are not stored in git.

cc @wlynch

I think we should name the new claims pipeline_ref and pipeline_sha. For the reasons noted above, ci_config_path is not always going to be .gitlab-ci.yml and the checksum is not necessarily based on ci_commit_sha.

Also note, we will be making some pretty significant changes to pipeline definitions in the future (https://gitlab.com/gitlab-org/gitlab/-/issues/398129#note_1323114974) and may wish to change the URI format of pipeline_ref to align with the syntax of CI pipeline components. Keeping that logic for constructing that on our side is another good reason to include fully qualified URIs in the claim.

The Build Signer URI (in GitLab's case our plan is to use Job ID) would still be useful for asserting identity since it is considered a unique immutable identifier for the service - though it places trust on GitLab to do the right thing and limits a client's ability to detect if the CI service misbehaves.

I agree that having a digest that can be verified independently by clients is something that CI providers should do - but I think having this requirement as MUST is a high bar that not all CI providers may be able to do right away.

Im not opposed to changing it to SHOULD, but I’d like to get some more input from GH, given we have discussed this as a requirement.

I think we are fine to lower this to SHOULD. Even for GitHub supporting the Build Signer Digest is a recent addition. By lowering this to SHOULD we still allow policy makers to REQUIRE this value, which I think is a good tradeoff.

@wlynch Can you create a separate PR to update this?

Of course! Will do.

docs/oid-info.md

aladh · 2023-04-05T19:14:30Z

docs/oid-info.md

 | event_name         | pipeline_source | ??       | ??        | Build Trigger                | The event or action that triggered the build.                                                                                                                                          |
-| server_url + repository + "/actions/runs/" + run_id + "/attempts/" + run_attempt | ??     | ??       | ??        | Run Invocation URI           | An immutable identifier that can uniquely identify the build execution     |
+| server_url + repository + "/actions/runs/" + run_id + "/attempts/" + run_attempt | server_url + project_path + /-/jobs/ + job_id    | ??       | ??        | Run Invocation URI           | An immutable identifier that can uniquely identify the build execution     |


Example URL: https://gitlab.com/gitlab-org/gitlab/-/jobs/4068841111

aladh · 2023-04-05T19:25:42Z

@Brcrwilliams @cpanato @marshall007 @wlynch could you please take a look and add any thoughts?

wlynch · 2023-04-05T19:36:54Z

docs/oid-info.md

 | iss                | iss     | iss       | iss        | Issuer                       | This already exists. For example: https://token.actions.githubusercontent.com                                                                                                          |
 | exp                | exp     | exp       | exp        | N/A                          | Only used to validate the JWT.                                                                                                                                                         |
 | nbf                | nbf     | nbf       | nbf        | N/A                          | Only used to validate the JWT.                                                                                                                                                         |
 | iat                | iat     | iat       | iat        | N/A                          | Only used to validate the JWT.                                                                                                                                                         |
-| server_url + job_workflow_ref   | ??     | ??       | ??        | Build Signer URI             | Reference to specific build instructions that are responsible for signing. Can be the same as Build Config URI. For example a reusable workflow in GitHub Actions or a Circle CI Orbs. |
+| server_url + job_workflow_ref   | server_url + project_path + /-/blob/ + ci_commit_sha + / + ci_config_path | ??       | ??        | Build Signer URI             | Reference to specific build instructions that are responsible for signing. Can be the same as Build Config URI. For example a reusable workflow in GitHub Actions or a Circle CI Orbs. |


GitHub Actions uses the job_workflow_ref, which is a ref to the workflow being used. I think the closest approximation for GitLab would be a ref for the include for the job if applicable, otherwise if it's just in the base .gitlab-ci.yml this would be the same as the build config uri.

wlynch · 2023-04-05T19:39:05Z

docs/oid-info.md

 | iss                | iss     | iss       | iss        | Issuer                       | This already exists. For example: https://token.actions.githubusercontent.com                                                                                                          |
 | exp                | exp     | exp       | exp        | N/A                          | Only used to validate the JWT.                                                                                                                                                         |
 | nbf                | nbf     | nbf       | nbf        | N/A                          | Only used to validate the JWT.                                                                                                                                                         |
 | iat                | iat     | iat       | iat        | N/A                          | Only used to validate the JWT.                                                                                                                                                         |
-| server_url + job_workflow_ref   | ??     | ??       | ??        | Build Signer URI             | Reference to specific build instructions that are responsible for signing. Can be the same as Build Config URI. For example a reusable workflow in GitHub Actions or a Circle CI Orbs. |
-| job_workflow_sha   | ??     | ??       | ??        | Build Signer Digest          | An immutable reference to the specific version of the build instructions that is responsible for signing. Should include the digest type followed by the digest, e.g. `sha1:abc123`.   |
+| server_url + job_workflow_ref   | server_url + project_path + /-/blob/ + ci_commit_sha + / + ci_config_path | ??       | ??        | Build Signer URI             | Reference to specific build instructions that are responsible for signing. Can be the same as Build Config URI. For example a reusable workflow in GitHub Actions or a Circle CI Orbs. |


General comment for these fields - we will want these values to be authenticated, so we'll need to make sure they're included in the JWT GitLab is producing (we can't pull them from the environment).

Based on https://gitlab.com/gitlab-org/gitlab/-/issues/388517#note_1342881271 there's commitment to make this happen, but not sure how we want to handling ordering here if some of these claims don't yet exist.

We can leave this PR open until https://gitlab.com/gitlab-org/gitlab/-/merge_requests/116867 is merged.

docs/oid-info.md

Brcrwilliams · 2023-04-05T22:10:22Z

docs/oid-info.md

 | iss                | iss     | iss       | iss        | Issuer                       | This already exists. For example: https://token.actions.githubusercontent.com                                                                                                          |
 | exp                | exp     | exp       | exp        | N/A                          | Only used to validate the JWT.                                                                                                                                                         |
 | nbf                | nbf     | nbf       | nbf        | N/A                          | Only used to validate the JWT.                                                                                                                                                         |
 | iat                | iat     | iat       | iat        | N/A                          | Only used to validate the JWT.                                                                                                                                                         |
-| server_url + job_workflow_ref   | ??     | ??       | ??        | Build Signer URI             | Reference to specific build instructions that are responsible for signing. Can be the same as Build Config URI. For example a reusable workflow in GitHub Actions or a Circle CI Orbs. |
+| server_url + job_workflow_ref   | server_url + project_path + /-/blob/ + ci_commit_sha + / + ci_config_path | ??       | ??        | Build Signer URI             | Reference to specific build instructions that are responsible for signing. Can be the same as Build Config URI. For example a reusable workflow in GitHub Actions or a Circle CI Orbs. |


So, the existence of include complicates this a lot. A single job may have elements of its configuration altered in multiple different places. For example, this is valid behavior:

include: '/templates/build.gitlab-ci.yml' # This job originates from build.gitlab-ci.yml build: # This script keyword overrides the one from `build.gitlab-ci.yml` script: ./my-build.sh

Additionally, include is not versioned and it could change between multiple different CI pipeline runs. The only solution I can really think of here is to persist the merged CI yaml that was used to create the pipeline, and allow that to be viewed. Ex: https://gitlab.com/:project/-/pipelines/:id/merged_yaml

docs/oid-info.md

codecov · 2023-04-06T00:42:14Z

Codecov Report

Merging #1097 (bd50cd7) into main (af14408) will decrease coverage by 0.18%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #1097      +/-   ##
==========================================
- Coverage   55.91%   55.73%   -0.18%     
==========================================
  Files          48       48              
  Lines        2783     2783              
==========================================
- Hits         1556     1551       -5     
- Misses       1097     1101       +4     
- Partials      130      131       +1

see 1 file with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

docs/oid-info.md

Signed-off-by: Alishan Ladhani <aladhani@gitlab.com>

feelepxyz

This looks great and very excited to see this! 😍 I was OOO for the last couple weeks so just coming around to this now.

wlynch

LGTM!

haydentherapper

Fantastic work on this! Just a few nits

haydentherapper · 2023-04-19T18:08:33Z

docs/oid-info.md

-| runner_environment | ??     | ??       | ??        | Runner Environment           | For platforms to specify whether the build took place in platform-hosted cloud infrastructure or customer-hosted infrastructure. For example: `platform-hosted` and `self-hosted`.     |
-| server_url + repository         | project_path     | ??       | ??        | Source Repository URI                   | Should include a fully qualified repository URL.                                                                                                                                       |
-| sha                | ??     | ??       | build_commit | Source Repository Digest                | An immutable reference to a specific version of the source code. Should include the digest type followed by the digest, e.g. `sha1:abc123`.                                            |
+| server_url + job_workflow_ref   | server_url + project_path + /-/jobs/ + job_id | ??       | ??        | Build Signer URI             | Reference to specific build instructions that are responsible for signing. Can be the same as Build Config URI. For example a reusable workflow in GitHub Actions or a Circle CI Orbs. |


Suggested change

| server_url + job_workflow_ref | server_url + project_path + /-/jobs/ + job_id | ?? | ?? | Build Signer URI | Reference to specific build instructions that are responsible for signing. Can be the same as Build Config URI. For example a reusable workflow in GitHub Actions or a Circle CI Orbs. |

| server_url + job_workflow_ref | server_url + project_path + "/-/jobs/" + job_id | ?? | ?? | Build Signer URI | Reference to specific build instructions that are responsible for signing. Can be the same as Build Config URI. For example a reusable workflow in GitHub Actions or a Circle CI Orbs. |

To confirm, you would like to include -? This differs from the GHA example, not sure if that's more in line for a GitLab URI.

@aladh thinking about this a bit more. Would it make more sense to set this to the same value as Build Config URI or what you'll set the SAN uri to (essentially project path I believe)? For github actions, the signer is either the custom workflow in a repo or, if using reusable workflows, the ref to the reusable workflow.

Attempting to capture some kind of signing identity that you can could write policies against, trusting certain ones for example.

How does this work in GitLab? When running a pipeline step that eventually runs npm publish --provenance, what resource or entity ends up wrapping that step in an isolated job/run? Can it be executed by entities different to the project or is it always 1:1?

@haydentherapper - yeah the /-/ is part of GitLab's URI spec.

@feelepxyz some related discussion up above - #1097 (comment)

I don't think we want to do that because the Build Config can point to a different repo or even a remote URL. The Job ID we're including here is still useful information to encode in the cert to differentiate jobs in a pipeline, since that's what's doing the signing. However, the Job ID is far to granular to be a useful SAN since it relies on a UID.

I think ideally we would use a named CI config + named job, but that's not a concept that exists in GitLab today (though @marshall007 mentioned that there are discussions happening that may lead to this in the future).

Today there's only 1 CI config per repo, which is why for the SAN we're planning to use is the repo+ref (which also covers merge requests from forks since the identity in that case would be the forked repo).
When GitLab supports multiple CI configs per repo, we can iterate on this and take that into account.

If there's plans to support multiple CI configs per repo in the near future, should we handle that now? Otherwise unless we proactively account for that, there will be a period where there are multiple configs and the SAN remains the same as now

@marshall007 can confirm, but I don't think there's a solid timeline / commitment at the moment, so I wouldn't design around it for now.

haydentherapper · 2023-04-19T18:09:54Z

docs/oid-info.md

 | event_name         | pipeline_source | ??       | ??        | Build Trigger                | The event or action that triggered the build.                                                                                                                                          |
-| server_url + repository + "/actions/runs/" + run_id + "/attempts/" + run_attempt | ??     | ??       | ??        | Run Invocation URI           | An immutable identifier that can uniquely identify the build execution     |
+| server_url + repository + "/actions/runs/" + run_id + "/attempts/" + run_attempt | server_url + project_path + /-/pipelines/ + pipeline_id | ??       | ??        | Run Invocation URI           | An immutable identifier that can uniquely identify the build execution     |


haydentherapper · 2023-04-19T18:11:33Z

docs/oid-info.md

 | repository_owner_id         | namespace_id     | ??       | ??        | Source Repository Owner Identifier     | Stable identifier for the owner of the source repository.                                                                                                                                   |
-| server_url + workflow_ref       | ??     | ??       | ??        | Build Config URI             | A reference to the initiating build instructions.                                                                                                                                      |
-| workflow_sha       | ??     | ??       | ??        | Build Config Digest          | An immutable reference to the specific version of the top-level build instructions. Should include the digest type followed by the digest, e.g. `sha1:abc123`.                         |
+| server_url + workflow_ref       |  pipeline_ref | ??       | ??        | Build Config URI             | A reference to the initiating build instructions.                                                                                                                                      |


To confirm, this is fully qualified with a URL?

Yes. See https://gitlab.com/gitlab-org/gitlab/-/issues/404722 for more details.

haydentherapper

Going to approve - There's just two open nits to change to ", but that's very small. Any more comments @wlynch @priyawadhwa @aladh?

Thanks so much for working on this!!

priyawadhwa · 2023-04-25T00:41:28Z

This LGTM, I'll go ahead and merge. @aladh thank you for your work on this! would you mind addressing the nits in a follow-up PR? Thank you!

aladh commented Apr 5, 2023

View reviewed changes

docs/oid-info.md Outdated Show resolved Hide resolved

aladh commented Apr 5, 2023

View reviewed changes

docs/oid-info.md Outdated Show resolved Hide resolved

aladh commented Apr 5, 2023

View reviewed changes

docs/oid-info.md Outdated Show resolved Hide resolved

aladh commented Apr 5, 2023

View reviewed changes

docs/oid-info.md Outdated Show resolved Hide resolved

aladh commented Apr 5, 2023

View reviewed changes

docs/oid-info.md Outdated Show resolved Hide resolved

aladh commented Apr 5, 2023

View reviewed changes

docs/oid-info.md Outdated Show resolved Hide resolved

aladh commented Apr 5, 2023

View reviewed changes

docs/oid-info.md Outdated Show resolved Hide resolved

aladh commented Apr 5, 2023

View reviewed changes

docs/oid-info.md Outdated Show resolved Hide resolved

aladh commented Apr 5, 2023

View reviewed changes

docs/oid-info.md Outdated Show resolved Hide resolved

aladh commented Apr 5, 2023

View reviewed changes

docs/oid-info.md Outdated Show resolved Hide resolved

aladh commented Apr 5, 2023

View reviewed changes

aladh marked this pull request as ready for review April 5, 2023 19:19

haydentherapper requested review from wlynch and feelepxyz April 5, 2023 19:34

wlynch reviewed Apr 5, 2023

View reviewed changes

Brcrwilliams reviewed Apr 5, 2023

View reviewed changes

aladh commented Apr 12, 2023

View reviewed changes

docs/oid-info.md Outdated Show resolved Hide resolved

aladh commented Apr 12, 2023

View reviewed changes

docs/oid-info.md Outdated Show resolved Hide resolved

wlynch mentioned this pull request Apr 13, 2023

Support for non-keyless mode for non-interactive git commit signing (e.g., CI/CD jobs that sign git commits) sigstore/gitsign#288

Open

Map GitLab OIDC token claims to Fulcio OIDs

bd50cd7

Signed-off-by: Alishan Ladhani <aladhani@gitlab.com>

feelepxyz approved these changes Apr 18, 2023

View reviewed changes

wlynch approved these changes Apr 19, 2023

View reviewed changes

haydentherapper reviewed Apr 19, 2023

View reviewed changes

haydentherapper approved these changes Apr 24, 2023

View reviewed changes

priyawadhwa approved these changes Apr 24, 2023

View reviewed changes

priyawadhwa merged commit 438cd83 into sigstore:main Apr 25, 2023

wlynch mentioned this pull request Apr 25, 2023

Add GitLab.com OIDC to Fulcio #983

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Map GitLab OIDC token claims to Fulcio OIDs #1097

Map GitLab OIDC token claims to Fulcio OIDs #1097

aladh commented Apr 5, 2023 •

edited

Loading

haydentherapper commented Apr 5, 2023

aladh Apr 5, 2023

wlynch Apr 5, 2023

Brcrwilliams Apr 5, 2023

marshall007 Apr 6, 2023

marshall007 Apr 6, 2023

wlynch Apr 13, 2023

haydentherapper Apr 13, 2023

kommendorkapten Apr 14, 2023

haydentherapper Apr 14, 2023

wlynch Apr 14, 2023

aladh Apr 5, 2023

aladh commented Apr 5, 2023 •

edited

Loading

wlynch Apr 5, 2023

wlynch Apr 5, 2023

aladh Apr 12, 2023

Brcrwilliams Apr 5, 2023

codecov bot commented Apr 6, 2023 •

edited

Loading

feelepxyz left a comment

wlynch left a comment

haydentherapper left a comment

haydentherapper Apr 19, 2023

haydentherapper Apr 19, 2023

feelepxyz Apr 21, 2023

wlynch Apr 21, 2023

haydentherapper Apr 21, 2023

wlynch Apr 21, 2023

haydentherapper Apr 19, 2023

haydentherapper Apr 19, 2023

wlynch Apr 24, 2023

haydentherapper left a comment

priyawadhwa commented Apr 25, 2023

	\| server_url + job_workflow_ref \| server_url + project_path + /-/jobs/ + job_id \| ?? \| ?? \| Build Signer URI \| Reference to specific build instructions that are responsible for signing. Can be the same as Build Config URI. For example a reusable workflow in GitHub Actions or a Circle CI Orbs. \|
	\| server_url + job_workflow_ref \| server_url + project_path + "/-/jobs/" + job_id \| ?? \| ?? \| Build Signer URI \| Reference to specific build instructions that are responsible for signing. Can be the same as Build Config URI. For example a reusable workflow in GitHub Actions or a Circle CI Orbs. \|

	\| server_url + repository + "/actions/runs/" + run_id + "/attempts/" + run_attempt \| server_url + project_path + /-/pipelines/ + pipeline_id \| ?? \| ?? \| Run Invocation URI \| An immutable identifier that can uniquely identify the build execution \|
	\| server_url + repository + "/actions/runs/" + run_id + "/attempts/" + run_attempt \| server_url + project_path + "/-/pipelines/" + pipeline_id \| ?? \| ?? \| Run Invocation URI \| An immutable identifier that can uniquely identify the build execution \|

Map GitLab OIDC token claims to Fulcio OIDs #1097

Map GitLab OIDC token claims to Fulcio OIDs #1097

Conversation

aladh commented Apr 5, 2023 • edited Loading

Summary

Release Note

Documentation

haydentherapper commented Apr 5, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aladh commented Apr 5, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

codecov bot commented Apr 6, 2023 • edited Loading

Codecov Report

feelepxyz left a comment

Choose a reason for hiding this comment

wlynch left a comment

Choose a reason for hiding this comment

haydentherapper left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

haydentherapper left a comment

Choose a reason for hiding this comment

priyawadhwa commented Apr 25, 2023

aladh commented Apr 5, 2023 •

edited

Loading

aladh commented Apr 5, 2023 •

edited

Loading

codecov bot commented Apr 6, 2023 •

edited

Loading