Add Buildkite to federation

[sj26]

Description

Hi! I'm Sam, I'm an engineer at Buildkite. We've been working on providing OIDC tokens within Buildkite pipelines, for CI/CD workloads. I'd like to be able to use Buildkite OIDC tokens to sign containers produced by my builds.

We have a command which can be run within a build to provision an OIDC token with a custom audience, asserting the current job and agent identity:

buildkite/agent#1827

Combining this with cosign should theoretically allow OIDC signing. But a pipeline like this:

steps:
- command: |
    docker build -t sj26/test:$BUILDKITE_BUILD_NUMBER .
    COSIGN_EXPERIMENTAL=1 cosign sign --identity-token="$(buildkite-agent oidc request-token --audience sigstore)" sj26/test:$BUILDKITE_BUILD_NUMBER

currently produces this error:

COSIGN_EXPERIMENTAL=1 cosign sign --identity-token="$(...)" sj26/test:16
Generating ephemeral keys...
Retrieving signed certificate...
 
        Note that there may be personally identifiable information associated with this signed artifact.
        This may include the email address associated with the account with which you authenticate.
        This information will be used for signing this artifact and will be stored in public transparency logs and cannot be removed later.
Error: signing [sj26/test:161]: getting signer: getting key from Fulcio: retrieving cert: POST https://fulcio.sigstore.dev/api/v1/signingCert returned 401 Unauthorized: "{\"code\":16,\"message\":\"There was an error processing the credentials for this request\",\"details\":[]}"
main.go:62: error during command execution: signing [sj26/test:161]: getting signer: getting key from Fulcio: retrieving cert: POST https://fulcio.sigstore.dev/api/v1/signingCert returned 401 Unauthorized: "{\"code\":16,\"message\":\"There was an error processing the credentials for this request\",\"details\":[]}"

I believe that means we need to be added to the federation config here:

https://github.com/sigstore/fulcio/tree/main/federation

I'm currently opening a PR, but required an issue open first. So, here it is! 🙏

[haydentherapper]

Copying over my response:

There’s a few options for onboarding. One is to conform to one of the existing types. Given you’re a CI platform, it’s likely the “GitHub” type is the closest. This would require just configuration change, but unless you support the same claims as GitHub Actions, we would need code changes.
We’ve been thinking about how to standardize claims from CI platforms in #754.
The other option is to implement a new type specific to your platform, but we will need to also add custom OIDs too. I’d prefer to not do this for each CI platform though due to needing to update all clients to be aware of the OIDs that hold custom metadata.

I’m curious what your thoughts are on the attached issue.

We’d also want to run through the list of requirements for providers, #397. This is a WIP list, so some might not be applicable to CI.

Given you said that your OIDC support is a work in progress, this is likely not something we would be including in the production instance yet, until your feature is stable. If you’d like to test locally, I can give some pointers to code that would need to be updated.

Edit: Code pointers here #748 (comment)