Update Buildkite issuer to include new extensions

[haydentherapper]

Description

Following #754, we should update the Buildkite integration to include additional extensions. We should leverage https://github.com/sigstore/fulcio/pull/1073 and refactor to avoid duplication.

[yob]

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