Update Buildkite issuer to include some of the new certificate extensions by yob · Pull Request #1307 · sigstore/fulcio

yob · 2023-08-06T14:23:48Z

Summary

The Buildkite Issuer was added in #890, prior to the efforts to standardise certificate extensions for CI providers, and #1074 calls for the Buildkite issuer to be updated to use the new extensions (where applicable).

This is an early attempt to make those changes.

I've added the extensions that make the most sense in a Buildkite context, like RunInvocationURI, RunnerEnvironment and SourceRepositoryDiget. Many of the other extensions don't apply because we're not a code host as well, or need further discussion.

I have not added tests yet. This is my first contribution to fulcio and I'm keen to confirm I'm heading in the right direction before adding tests. However, I have tested this locally with a Buildkite agent and OIDC token, and the certificate was issued as expected.

Using git cat-file commit HEAD and piping it through openssl pkcs7 -print -print_certs -text, the extensions section looks like this:

X509v3 extensions:
    X509v3 Key Usage: critical
        Digital Signature
    X509v3 Extended Key Usage:
        Code Signing
    X509v3 Subject Key Identifier:
        19:9E:E7:53:4D:F6:65:D4:23:9D:60:21:B8:F3:12:80:FD:11:30:7F
    X509v3 Authority Key Identifier:
        8A:3E:9E:34:19:F7:32:18:3D:2A:1B:F9:5F:60:29:24:0F:70:0B:B4
    X509v3 Subject Alternative Name: critical
        URI:https://buildkite.com/yob-opensource/oidc-signing-experiment
    1.3.6.1.4.1.57264.1.1:
        https://agent.buildkite.com
    1.3.6.1.4.1.57264.1.8:
        ..https://agent.buildkite.com
    1.3.6.1.4.1.57264.1.11:
        ..self-hosted
    1.3.6.1.4.1.57264.1.13:
        .(5242de9e5c2ca164cb3dfc500fb605f0b8b86763
    1.3.6.1.4.1.57264.1.21:
        .mhttps://buildkite.com/yob-opensource/oidc-signing-experiment/builds/35%230189cb29-62fa-41af-8641-62e1d6c5edfd

Fixes #1074

/cc @sj26

Release Note

NONE

Documentation

Uncertain

…ions The Buildkite Issuer was added in sigstore#890, prior to the efforts to standardise certificate extensions for CI providers, and sigstore#1074 calls for the Buildkite issuer to be updated to use the new extensions (where applicable). This is an early attempt to make those changes. I've added the extensions that make the most sense in a Buildkite context, like RunInvocationURI, RunnerEnvironment and SourceRepositoryDiget. Many of the other extensions don't apply because we're not a code host as well, or need further discussion. I have not added tests yet. This is my first contribution to fulcio and I'm keen to confirm I'm heading in the right direction before adding tests. However, I have tested this locally with a Buildkite agent and OIDC token, and the certificate was issued as expected. Using `git cat-file commit HEAD` and piping it through `openssl pkcs7 -print -print_certs -text`, the extensions section looks like this: X509v3 extensions: X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: Code Signing X509v3 Subject Key Identifier: 19:9E:E7:53:4D:F6:65:D4:23:9D:60:21:B8:F3:12:80:FD:11:30:7F X509v3 Authority Key Identifier: 8A:3E:9E:34:19:F7:32:18:3D:2A:1B:F9:5F:60:29:24:0F:70:0B:B4 X509v3 Subject Alternative Name: critical URI:https://buildkite.com/yob-opensource/oidc-signing-experiment 1.3.6.1.4.1.57264.1.1: https://agent.buildkite.com 1.3.6.1.4.1.57264.1.8: ..https://agent.buildkite.com 1.3.6.1.4.1.57264.1.11: ..self-hosted 1.3.6.1.4.1.57264.1.13: .(5242de9e5c2ca164cb3dfc500fb605f0b8b86763 1.3.6.1.4.1.57264.1.21: .mhttps://buildkite.com/yob-opensource/oidc-signing-experiment/builds/35%230189cb29-62fa-41af-8641-62e1d6c5edfd Fixes sigstore#1074 Signed-off-by: James Healy <james@buildkite.com>

yob · 2023-08-06T14:27:06Z

 	cert.ExtraExtensions, err = certificate.Extensions{
-		Issuer: p.issuer,
+		Issuer:                 p.issuer,
+		RunInvocationURI:       jobUrl.String(),


This is the one I'm most interested in - having the specific job URL in the certificate to provide provenance would be excellent

@yob I think it makes sense, we went job-specific for the GitLab provider: https://github.com/sigstore/fulcio/blob/04e4ac9b2d867d0f94e58a858f373a831d87653d/pkg/identity/gitlabcom/principal.go#L233C63-L233C63

Some related discussion in #1182. I found it confusing that this extension was named RunInvocationURI (instead of BuildInvocationURI), sort of implying it ought to be pipeline-level.

GitHub does not have job_id available in their ID tokens, so they don't have the option to align with us on that presently.

👍 job url makes sense to me. "run invocation" terminology was cribbed from the slsa spec.

Hayden-IO · 2023-08-07T16:41:51Z

cc @feelepxyz @marshall007 @wlynch for more thoughts

Thank you for starting this!

feelepxyz · 2023-08-08T08:54:25Z

+		Issuer:                 p.issuer,
+		RunInvocationURI:       jobUrl.String(),
+		RunnerEnvironment:      p.runnerEnvironment,
+		SourceRepositoryDigest: p.buildCommit,


I would love to see support for a few additional extensions so we could get richer provenance info:

Would it not be possible to also forward the repo url and ref from the originating source host to populate SourceRepositoryURI and SourceRepositoryRef? What about the repo and owner IDs?

Could you point the BuildConfigURI to pipeline.yml file that configures the build? Is there something else that configures the build? Is the sha of this always the same as p.buildCommit?

Is there not some concept of the event trigger that kicks of the job in buildkite that could be used to populate BuildTrigger?

Buildkite has no access to the source repository.

Because of this, SourceRepositoryURI and SourceRepositoryRef are resolved within the runner environment, and are not always known on the Buildkite side which generates the OIDC tokens. We have a repository url which is provided as an input to the runner, but it is not always a fully-qualified URI. We have a build branch and commit, but these often start as values like HEAD and are resolved to a concrete ref by the runner which sends back the resolve commit sha.

Similarly for BuildConfigURI. The initial steps are defined as part of the pipeline on Buildkite. But those initial steps are usually just a single "upload" step. That step runs within the runner environment, to access the source repository. It conventionally looks at buildkite.yml or .buildkite/pipeline.yml, but can choose any file in the source repository. It may not even be a file, the runner may generate content, like with a script, which is piped into an upload command to use as build config. And the build is not limited to one upload - many uploads may happen over the course of a build, from any step, sometimes in a chain.

"build config" beyond those initial steps is not an immutable input to a build for us, but an output. (There are ways to make it immutable, but it's not the default, and not something we can currently provide at platform level.)

BuildTrigger is probably something we could add. But I'd lean towards another PR for that.

(I'd love to see the contents of this PR land as an increment, and consider additional extensions later.)

feelepxyz · 2023-08-08T09:02:08Z

+	jobUrl := baseURL.JoinPath(p.organizationSlug, p.pipelineSlug, "builds", strconv.FormatInt(p.buildNumber, 10)+"#"+p.jobId)
+
+	// Set SubjectAlternativeName to the pipeline URL on the certificate
+	cert.URIs = []*url.URL{pipelineUrl}


Would this support a use case to write a verification policy to only allow builds from a particular buildkite project/pipeline/thing. Looks like this identifier would be stable across jobs but unique to the parent resource responsible for running the job. Could you have different build's from different repos running with the same org and pipeline slug?

I would also use this value to populate BuildSignerURI as these are currently mirrored for github and gitlab. If a pipeline slug is always configured from a pipeline.yml and we know the sha of the pipleline file we could also use this to populate BuildConfigDigest and BuildSignerDigest.

Hayden-IO · 2023-10-17T21:27:17Z

Hey all, just wanted to check in, has there been any progress on this?

richardfan1126 · 2024-09-06T06:59:57Z

I believe this PR is obsolete due to the change introduced in

Instead, we need to update

fulcio/config/identity/config.yaml

Lines 230 to 233 in 5237979

    
           *buildkite-type: 
        
             default-template-values: 
        
               url: "https://buildkite.com" 
        
             subject-alternative-name-template: "{{.url}}/{{.organization_slug}}/{{.pipeline_slug}}"

Hayden-IO · 2024-09-09T23:43:51Z

I agree no more work is needed on the PR - If someone could convert the changes over to configuration in the above linked file, that would be appreciated!

yob · 2025-01-02T21:31:18Z

I agree no more work is needed on the PR - If someone could convert the changes over to configuration in the above linked file, that would be appreciated!

I'm working on this at the moment, so I'll close this PR and open a new one shortly

The Buildkite Issuer was added in sigstore#890, prior to the efforts to standardise certificate extensions for CI providers, and sigstore#1074 calls for the Buildkite issuer to be updated to use the new extensions (where applicable). This is an early attempt to make those changes. I initially started these in sigstore#1307, however is is a new swing at it using the new CIProvider issuer (see sigstore#1729 and sigstore#1743). I've added the extensions that make the most sense in a Buildkite context, like RunInvocationURI, RunnerEnvironment and SourceRepositoryDigest. Many of the other extensions don't apply because we're not a code host as well, or need further discussion. I have not added tests yet. This is my first contribution to fulcio and I'm keen to confirm I'm heading in the right direction before adding tests. However, I have tested this locally with a Buildkite agent and OIDC token, and the certificate was issued as expected. I started a local fulcio like this: $ go run main.go serve --port 5555 --ca ephemeralca --ct-log-url="" --config-path config/identity/config.yaml ... and signed git commits with gitsign. The relevant bits of the certificates look like: git cat-file commit HEAD | sed -n '/-BEGIN/, /-END/p' | sed 's/^ //g' | sed 's/gpgsig //g' | sed 's/SIGNED MESSAGE/PKCS7/g' | openssl pkcs7 -print -print_certs -text ... X509v3 extensions: X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: Code Signing X509v3 Subject Key Identifier: CE:BC:6A:68:02:C1:00:E9:6E:CE:F6:1C:19:36:08:DC:4B:F0:D5:45 X509v3 Authority Key Identifier: 6C:D8:1D:E8:94:96:6F:B5:2F:D6:15:44:A2:11:B5:1B:BF:A4:A4:E9 X509v3 Subject Alternative Name: critical URI:https://buildkite.com/yob-opensource/oidc-signing-experiment 1.3.6.1.4.1.57264.1.1: https://agent.buildkite.com 1.3.6.1.4.1.57264.1.8: ..https://agent.buildkite.com 1.3.6.1.4.1.57264.1.13: .(078a6dd4a32fa40592c21a40aedaf27105503140 1.3.6.1.4.1.57264.1.21: .xhttps://buildkite.com/yob-opensource/oidc-signing-experiment/builds/%!s(float64=42)#01942921-7883-409b-81d0-3f6b20bcdabf

The Buildkite Issuer was added in sigstore#890, prior to the efforts to standardise certificate extensions for CI providers, and sigstore#1074 calls for the Buildkite issuer to be updated to use the new extensions (where applicable). This is an early attempt to make those changes. I initially started these in sigstore#1307, however is is a new swing at it using the new CIProvider issuer (see sigstore#1729 and sigstore#1743). I've added the extensions that make the most sense in a Buildkite context, like RunInvocationURI, RunnerEnvironment and SourceRepositoryDigest. Many of the other extensions don't apply because we're not a code host as well, or need further discussion. I have not added tests yet. This is my first contribution to fulcio and I'm keen to confirm I'm heading in the right direction before adding tests. However, I have tested this locally with a Buildkite agent and OIDC token, and the certificate was issued as expected. I started a local fulcio like this: $ go run main.go serve --port 5555 --ca ephemeralca --ct-log-url="" --config-path config/identity/config.yaml ... and signed git commits with gitsign. The relevant bits of the certificates look like: git cat-file commit HEAD | sed -n '/-BEGIN/, /-END/p' | sed 's/^ //g' | sed 's/gpgsig //g' | sed 's/SIGNED MESSAGE/PKCS7/g' | openssl pkcs7 -print -print_certs -text ... X509v3 extensions: X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: Code Signing X509v3 Subject Key Identifier: CE:BC:6A:68:02:C1:00:E9:6E:CE:F6:1C:19:36:08:DC:4B:F0:D5:45 X509v3 Authority Key Identifier: 6C:D8:1D:E8:94:96:6F:B5:2F:D6:15:44:A2:11:B5:1B:BF:A4:A4:E9 X509v3 Subject Alternative Name: critical URI:https://buildkite.com/yob-opensource/oidc-signing-experiment 1.3.6.1.4.1.57264.1.1: https://agent.buildkite.com 1.3.6.1.4.1.57264.1.8: ..https://agent.buildkite.com 1.3.6.1.4.1.57264.1.13: .(078a6dd4a32fa40592c21a40aedaf27105503140 1.3.6.1.4.1.57264.1.21: .xhttps://buildkite.com/yob-opensource/oidc-signing-experiment/builds/%!s(float64=42)#01942921-7883-409b-81d0-3f6b20bcdabf Signed-off-by: James Healy <james@buildkite.com>

The Buildkite Issuer was added in sigstore#890, prior to the efforts to standardise certificate extensions for CI providers, and sigstore#1074 calls for the Buildkite issuer to be updated to use the new extensions (where applicable). This is an early attempt to make those changes. I initially started these in sigstore#1307, however is is a new swing at it using the new CIProvider issuer (see sigstore#1729 and sigstore#1743). I've added the extensions that make the most sense in a Buildkite context, like RunInvocationURI, RunnerEnvironment and SourceRepositoryDigest. Many of the other extensions don't apply because we're not a code host as well, or need further discussion. I have not added tests yet. This is my first contribution to fulcio and I'm keen to confirm I'm heading in the right direction before adding tests. However, I have tested this locally with a Buildkite agent and OIDC token, and the certificate was issued as expected. I started a local fulcio like this: $ go run main.go serve --port 5555 --ca ephemeralca --ct-log-url="" --config-path config/identity/config.yaml ... and signed git commits with gitsign. The relevant bits of the certificates look like: git cat-file commit HEAD | sed -n '/-BEGIN/, /-END/p' | sed 's/^ //g' | sed 's/gpgsig //g' | sed 's/SIGNED MESSAGE/PKCS7/g' | openssl pkcs7 -print -print_certs -text ... X509v3 extensions: X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: Code Signing X509v3 Subject Key Identifier: 36:D2:99:B9:BA:98:4B:3A:77:51:DC:08:05:83:12:9A:F4:EE:41:E5 X509v3 Authority Key Identifier: D2:41:21:29:23:AD:E9:27:69:6F:DB:85:6D:1B:3F:7E:A9:55:F3:02 X509v3 Subject Alternative Name: critical URI:https://buildkite.com/yob-opensource/oidc-signing-experiment 1.3.6.1.4.1.57264.1.1: https://agent.buildkite.com 1.3.6.1.4.1.57264.1.8: ..https://agent.buildkite.com 1.3.6.1.4.1.57264.1.11: ..self-hosted 1.3.6.1.4.1.57264.1.13: .(078a6dd4a32fa40592c21a40aedaf27105503140 1.3.6.1.4.1.57264.1.20: ..ui 1.3.6.1.4.1.57264.1.21: .khttps://buildkite.com/yob-opensource/oidc-signing-experiment/builds/52#01943a38-f93e-4355-abe8-90a30369c270 Signed-off-by: James Healy <james@buildkite.com>

* ciprovider: support claim values that are not strings The default behaviour of %v is fine in most cases: > bool: %t > int, int8 etc.: %d > uint, uint8 etc.: %d, %#x if printed with %#v > float32, complex64, etc: %g > string: %s > chan: %p > pointer: %p However Buildkite's build_number claim is an int in the JSON, but comes through as a Float64 and we need to render it into a string value as a regular int. Claim values that are floats with a fractional part will also be converted to a string, but their fractional part will be retained. This isn't required for Buildkite OIDC tokens, but feels like the least-surprising behaviour for future travelers. Signed-off-by: James Healy <james@buildkite.com> * Configure additional certificate extensions for Buildkite The Buildkite Issuer was added in #890, prior to the efforts to standardise certificate extensions for CI providers, and #1074 calls for the Buildkite issuer to be updated to use the new extensions (where applicable). This is an early attempt to make those changes. I initially started these in #1307, however is is a new swing at it using the new CIProvider issuer (see #1729 and #1743). I've added the extensions that make the most sense in a Buildkite context, like RunInvocationURI, RunnerEnvironment and SourceRepositoryDigest. Many of the other extensions don't apply because we're not a code host as well, or need further discussion. I have not added tests yet. This is my first contribution to fulcio and I'm keen to confirm I'm heading in the right direction before adding tests. However, I have tested this locally with a Buildkite agent and OIDC token, and the certificate was issued as expected. I started a local fulcio like this: $ go run main.go serve --port 5555 --ca ephemeralca --ct-log-url="" --config-path config/identity/config.yaml ... and signed git commits with gitsign. The relevant bits of the certificates look like: git cat-file commit HEAD | sed -n '/-BEGIN/, /-END/p' | sed 's/^ //g' | sed 's/gpgsig //g' | sed 's/SIGNED MESSAGE/PKCS7/g' | openssl pkcs7 -print -print_certs -text ... X509v3 extensions: X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: Code Signing X509v3 Subject Key Identifier: 36:D2:99:B9:BA:98:4B:3A:77:51:DC:08:05:83:12:9A:F4:EE:41:E5 X509v3 Authority Key Identifier: D2:41:21:29:23:AD:E9:27:69:6F:DB:85:6D:1B:3F:7E:A9:55:F3:02 X509v3 Subject Alternative Name: critical URI:https://buildkite.com/yob-opensource/oidc-signing-experiment 1.3.6.1.4.1.57264.1.1: https://agent.buildkite.com 1.3.6.1.4.1.57264.1.8: ..https://agent.buildkite.com 1.3.6.1.4.1.57264.1.11: ..self-hosted 1.3.6.1.4.1.57264.1.13: .(078a6dd4a32fa40592c21a40aedaf27105503140 1.3.6.1.4.1.57264.1.20: ..ui 1.3.6.1.4.1.57264.1.21: .khttps://buildkite.com/yob-opensource/oidc-signing-experiment/builds/52#01943a38-f93e-4355-abe8-90a30369c270 Signed-off-by: James Healy <james@buildkite.com> --------- Signed-off-by: James Healy <james@buildkite.com>

yob marked this pull request as draft August 6, 2023 14:23

yob commented Aug 6, 2023

View reviewed changes

feelepxyz reviewed Aug 8, 2023

View reviewed changes

richardfan1126 mentioned this pull request Sep 10, 2024

Update OIDC claim mapping table to reflect the current state #1801

Merged

wip

38b03aa

yob closed this Jan 2, 2025

yob mentioned this pull request Jan 2, 2025

Configure additional certificate extensions for Buildkite #1903

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update Buildkite issuer to include some of the new certificate extensions#1307

Update Buildkite issuer to include some of the new certificate extensions#1307
yob wants to merge 2 commits into
sigstore:mainfrom
yob:buildkite-extensions

yob commented Aug 6, 2023

Uh oh!

yob Aug 6, 2023

Uh oh!

marshall007 Aug 7, 2023

Uh oh!

feelepxyz Aug 8, 2023

Uh oh!

Hayden-IO commented Aug 7, 2023

Uh oh!

feelepxyz Aug 8, 2023

Uh oh!

sj26 Oct 19, 2023 •

edited

Loading

Uh oh!

sj26 Oct 19, 2023

Uh oh!

feelepxyz Aug 8, 2023

Uh oh!

Hayden-IO commented Oct 17, 2023

Uh oh!

richardfan1126 commented Sep 6, 2024 •

edited

Loading

Uh oh!

Hayden-IO commented Sep 9, 2024

Uh oh!

yob commented Jan 2, 2025 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Conversation

yob commented Aug 6, 2023

Summary

Release Note

Documentation

Uh oh!

yob Aug 6, 2023

Choose a reason for hiding this comment

Uh oh!

marshall007 Aug 7, 2023

Choose a reason for hiding this comment

Uh oh!

feelepxyz Aug 8, 2023

Choose a reason for hiding this comment

Uh oh!

Hayden-IO commented Aug 7, 2023

Uh oh!

feelepxyz Aug 8, 2023

Choose a reason for hiding this comment

Uh oh!

sj26 Oct 19, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sj26 Oct 19, 2023

Choose a reason for hiding this comment

Uh oh!

feelepxyz Aug 8, 2023

Choose a reason for hiding this comment

Uh oh!

Hayden-IO commented Oct 17, 2023

Uh oh!

richardfan1126 commented Sep 6, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Hayden-IO commented Sep 9, 2024

Uh oh!

yob commented Jan 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

sj26 Oct 19, 2023 •

edited

Loading

richardfan1126 commented Sep 6, 2024 •

edited

Loading

yob commented Jan 2, 2025 •

edited

Loading