Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update Buildkite issuer to include new extensions #1074

Open
haydentherapper opened this issue Mar 21, 2023 · 1 comment · May be fixed by #1307
Open

Update Buildkite issuer to include new extensions #1074

haydentherapper opened this issue Mar 21, 2023 · 1 comment · May be fixed by #1307
Labels
enhancement New feature or request

Comments

@haydentherapper
Copy link
Contributor

Description

Following #754, we should update the Buildkite integration to include additional extensions. We should leverage #1073 and refactor to avoid duplication.
@haydentherapper haydentherapper added the enhancement New feature or request label Mar 21, 2023
@yob
Copy link

yob commented Jul 23, 2023

Hi folks,

I'm an engineer at Buildkite who has been experimenting with fulcio certificates from our OIDC tokens. Through that, I noticed our certificates aren't using the newer style extensions. One consequence that stood out is that the current certificates don't point to the specific Run Invocation (which we call a Job) the OIDC token was from, which feels like a gap in the provenance capabilities for our customers.

Adding or changing claims in our tokens is obviously possible, but will take some time. I'd love to help get our certificates using some of the newer extensions based on the claims we have so far. Is that possible? Comparing pkg/identity/{buildkite,github}/principal.go it seems the mapping logic is fairly straight forward, I'm happy to open a PR if there's some obvious improvements to be made.

The claims in our tokens are documented here, and @sj26 had some relevant words on #754 back in November 2022 that are still accurate:

We include some equivalents to these:

  • sha is build_commit, but may be a user-supplied value for manually triggered builds, or HEAD for a new build until resolved
  • ref is a combination of build_branch and build_tag

We do not include these:

  • job_workflow_ref — the closest might be a reference to the containing pipeline, like https://buildkite.com/buildkite/lifecycled, everything else is dynamic
  • event_name — no current equivalent, although we do record whether a build was started manually, by webhook, etc
  • repository, workflow — these are roughly the same thing for us, each org (account) has many pipelines which contain many builds (or "runs" in GHA parlance), e.g. https://buildkite.com/buildkite/lifecycled

We add these, which I think are important:

  • job_id - a unique id for a particular task within a build run as a concrete process somewhere, GitHub also uses job id I think.
  • agent_id - a unique id for the persistent environment in which many jobs may be run

and:

If I had to pick a set of common attributes which would be useful in sigstore right now, it'd be roughly:

  • Git Repository URI
    • Git Ref
    • Git Commit
  • Pipeline URI (container of all work across all time, like job_workflow_ref)
    • Job ID/URI (concrete description of individual piece of work)
    • Runner ID/URI (concrete environment in which work was run)

Looking at the extensions in https://github.com/sigstore/fulcio/blob/main/docs/oid-info.md#mapping-oidc-token-claims-to-fulcio-oids, here's a few comments

Run Invocation URI

The unique URL for the Buildkite Job that executed looks like this: https://buildkite.com/<claim:organization_slug>/<claim:pipelines_slug>/builds/<claim:build_number>#<claim:job_id>

Runner Environment

Buildkite does not offer hosted build environments, so 100% of our OIDCs tokens are for self hosted runner environments

Source Repository Digest

This is included in the mapping table, but not in the certificates issued by fulcio yet. The value could be pulled from the build_commit claim

Source Repository Ref

This is included in the mapping table, but not in the certificates issued by fulcio yet. The value could be pulled from the build_branch claim

Source Repository {URI, Identifier, Owner URI, Owner Identifier}

Our claims currently do not include any references to the source repository owner, name or URI

Build Config URI and Build Config Digest

Our customers typically store their build config inside their repositories and we don't have access to the repository contents, so this would be difficult (impossible?) for us to attest. We do know the git sha of course, but is that enough? 🤔

Source Repository Visibility At Signing

We currently don't track the visibility of the source code repository, and therefore don't (and can't easily) add it to our claims

yob added a commit to yob/fulcio that referenced this issue Aug 6, 2023
@yob
Update Buildkite issuer to include some of the new certificate extens…
a653caa 
…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
yob added a commit to yob/fulcio that referenced this issue Aug 6, 2023
@yob
Update Buildkite issuer to include some of the new certificate extens…
3025b65 
…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 yob linked a pull request Aug 6, 2023 that will close this issue
Draft
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Update Buildkite issuer to include some of the new certificate extensions yob/fulcio
2 participants
@yob @haydentherapper