Add Buildkite OIDC to Fulcio #890

sj26 · 2022-11-16T03:10:35Z

Add Buildkite to the OIDC connect federation configuration. Fixes #889.

Summary

I'd like to be able to use Buildkite OIDC tokens to sign containers produced by my builds. There are more details in #889.

Our OIDC token support is still under development, but it's possible to try it out now by signing up for Buildkite and running a pipeline like:

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}"

I wasn't sure about the "type", so I followed the example of "github-workflow" — our tokens represent one "buildkite-job" which is a process being run on a host somewhere as part of a build pipeline.

Release Note

Add Buildkite OIDC to Fulcio

Documentation

I couldn't find specific docs for each OIDC provider, so I don't think any updates are required.

haydentherapper · 2022-11-16T03:31:59Z

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.

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

haydentherapper · 2022-11-16T03:34:28Z

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.

Let’s continue the conversation on the issue, I’ll copy this over.

sj26 · 2022-11-16T07:13:25Z

Yeah we don't support exactly the same claims as github, but it feels like there would be common ground.

We do include a unique immutable id (job_id, a uuid) which identifies a command and where it was run, and how it fits amongst a build (made of many jobs), pipeline and organization. Other provenance can be derived from that unique identifier, even if other symbolic attributes change over time. Perhaps that's the only hard requirement — there must be a unique immutable identifier for the runtime environment, and that identifier can be mapped to full provenance by the identity provider. I think this would be the job_id on GitHub Actions, for example.

I'm sure there are other commonly useful attributes, but they get pretty usage-specific pretty quickly.

I'll chime in on the other issue.

mattmoor · 2022-11-16T15:29:32Z

Once this lands, we should talk about adding ambient authentication to cosign for this so the --identity-token flag isn't needed. That's done via the providers here: https://github.com/sigstore/cosign/tree/main/pkg/providers

codecov-commenter · 2022-11-17T03:31:19Z

Codecov Report

Merging #890 (23d0247) into main (ef874af) will decrease coverage by 1.67%.
The diff coverage is 80.48%.

@@            Coverage Diff             @@
##             main     #890      +/-   ##
==========================================
- Coverage   55.63%   53.97%   -1.67%     
==========================================
  Files          38       38              
  Lines        2333     2366      +33     
==========================================
- Hits         1298     1277      -21     
- Misses        939      996      +57     
+ Partials       96       93       -3

Impacted Files	Coverage Δ
pkg/challenges/challenges.go	`39.13% <0.00%> (-1.78%)`	⬇️
pkg/identity/buildkite/principal.go	`83.78% <83.78%> (ø)`
pkg/config/config.go	`69.48% <100.00%> (+0.22%)`	⬆️
pkg/ca/googleca/v1/googleca.go	`37.05% <0.00%> (-10.49%)`	⬇️
pkg/server/grpc_server.go	`50.00% <0.00%> (-2.18%)`	⬇️
pkg/ca/baseca/baseca.go	`54.76% <0.00%> (-1.34%)`	⬇️
cmd/app/serve.go	`18.85% <0.00%> (-0.68%)`	⬇️
pkg/server/error.go	`100.00% <0.00%> (ø)`
pkg/identity/github/principal.go	`90.47% <0.00%> (ø)`
pkg/identity/username/principal.go	`92.68% <0.00%> (ø)`
... and 2 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

haydentherapper · 2022-11-17T03:33:13Z

Sweet, I’ll take a look tomorrow or Friday!

Could you take a look at the questions in #397 and answer them? In particular, confirming the well known endpoint, configurable audiences, secure key management of signing keys, uptime/SLO?

haydentherapper · 2022-11-17T05:18:23Z

Also, what’s the best way to test this out?

sj26 · 2022-11-17T06:19:00Z

Thanks!

I'll address the specific questions you copied in here:

confirming the well known endpoint

Our issuer is https://agent.buildkite.com, which is the private API endpoint used by the Buildkite Agent (which runs jobs, and exchanges private credentials for OIDC identity tokens), and there are matching well-known endpoints here:

configurable audiences

The default audience is https://buildkite.com/<organization>, but this can be overridden when asking for a token.

In the original issue I included an example for the direct API which shows how to vary the audience:

curl -s -X POST -H "Authorization: Token $${BUILDKITE_AGENT_ACCESS_TOKEN}" \
  "$${BUILDKITE_AGENT_ENDPOINT:-https://agent.buildkite.com/v3}/jobs/$${BUILDKITE_JOB_ID}/oidc/tokens" \
  --data '{"audience":"sigstore"}'

but we expect folks to use a new subcommand of the buildkite agent (available within jobs) to ask for these tokens, which accepts an audience argument, like this:

buildkite-agent oidc request-token --audience sigstore

secure key management of signing keys

Our keys are stored with other production secrets and treated similarly — encrypted at rest, encrypted in transit, only available within the application environment used for signing, etc.

The current cert has an expiry in 2 years, but I expect we'll rotate yearly. We're still refining these details for release.

uptime/SLO?

We have a 99.95% uptime SLO.

sj26 · 2022-11-17T07:56:44Z

In terms of testing, I started a local ephemeral instance of fulcio with the buildkite provider configured using the instructions here:

https://github.com/sigstore/fulcio/blob/main/docs/setup.md

go run main.go serve --port 5555 --ca ephemeralca --ct-log-url=""

Then I ran a local buildkite agent on my mac:

https://buildkite.com/docs/agent/v3/macos

and had it run a pipeline like this:

steps:
- command: |
    docker tag sj26/test "sj26/test:$${BUILDKITE_BUILD_NUMBER}"
    docker push "sj26/test:$${BUILDKITE_BUILD_NUMBER}"

    COSIGN_EXPERIMENTAL=1 cosign sign \
      --fulcio-url http://localhost:5555 \
      --insecure-skip-verify \
      --identity-token="$$(buildkite-agent oidc request-token --audience sigstore)" \
      "sj26/test:$${BUILDKITE_BUILD_NUMBER}"

again referencing the local fulcio usage example from:

https://github.com/sigstore/fulcio/blob/main/docs/setup.md#calling-the-fulcio-api

and .. it works:

The pushed signatures are visible here:

https://hub.docker.com/r/sj26/test/tags

This is a really rough get-it-working example, but it's enough to give me confidence that it's the right direction.