Map GitLab OIDC token claims to Fulcio OIDs #1097
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -180,26 +180,26 @@ that Sigstore operates. | |||||
|
|
||||||
| ## Mapping OIDC token claims to Fulcio OIDs | ||||||
|
|
||||||
| | GitHub [(docs)][github-oidc-doc] | GitLab [(docs)](https://docs.gitlab.com/ee/ci/secrets/id_token_authentication.html#token-payload) | CircleCI | Buildkite | Fulcio Certificate Extension | Why / Notes / Questions | | ||||||
| |--------------------|--------|----------|-----------|------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | ||||||
| | aud | aud | aud | aud | N/A | Only used to validate the JWT. | | ||||||
| | 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 | 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. | | ||||||
| | job_workflow_sha | N/A | ?? | ?? | 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`. | | ||||||
| | runner_environment | 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 | server_url + project_path | ?? | ?? | Source Repository URI | Should include a fully qualified repository URL. | | ||||||
| | sha | 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`. | | ||||||
| | ref | ref | ?? | build_branch | Source Repository Ref | The source ref that the build run was based upon. For example: refs/head/main. | | ||||||
| | repository_id | project_id | ?? | ?? | Source Repository Identifier | Stable identifier for the owner of the source repository. | | ||||||
| | server_url + repository_owner | server_url + namespace_path | ?? | ?? | Source Repository Owner URI | Fully qualified URL for the owner of the source repository. | | ||||||
aladh marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
| | repository_owner_id | namespace_id | ?? | ?? | Source Repository Owner Identifier | Stable identifier for the owner of the source repository. | | ||||||
| | server_url + workflow_ref | pipeline_ref | ?? | ?? | Build Config URI | A reference to the initiating build instructions. | | ||||||
|
There was a problem hiding this comment. To confirm, this is fully qualified with a URL? There was a problem hiding this comment. Yes. See https://gitlab.com/gitlab-org/gitlab/-/issues/404722 for more details. |
||||||
| | workflow_sha | pipeline_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`. | | ||||||
| | event_name | pipeline_source | ?? | ?? | Build Trigger | The event or action that triggered the build. | | ||||||
| | 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 | | ||||||
|
There was a problem hiding this comment.
Suggested change
|
||||||
|
|
||||||
| [github-oidc-doc]: https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#understanding-the-oidc-token | ||||||
| [oid-link]: http://oid-info.com/get/1.3.6.1.4.1.57264 | ||||||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@aladh thinking about this a bit more. Would it make more sense to set this to the same value as
Build Config URIor 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?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.