Support ambient credential detection

[di]

Cosign supports 'ambient credential detection' for a number of environments where OIDC identities are available by default. We should also similarly support:

• GitHub Actions (internal/oidc, test: ambient credentials, refactoring #59)
• Google Cloud: VMs, GKE clusters, Cloud Build, etc. (Google Cloud ambient credential detection #88, Support Google Cloud impersonation #91)
• GitLab (SaaS): https://docs.gitlab.com/ee/integration/openid_connect_provider.html
  • blocked on Add support for GitLab tokens fulcio#243 (Add GitLab.com OIDC to Fulcio fulcio#983)
    • blocked on https://gitlab.com/groups/gitlab-org/-/epics/7335
• CircleCI: https://circleci.com/docs/2.0/openid-connect-tokens/
  • blocked on Add support for CircleCI tokens fulcio#591
    • blocked on https://circleci.canny.io/cloud-feature-requests/p/customizable-audience-claim-in-oidc-tokens
  • implementation: sigstore, test: add CircleCI credential detection #72
• BuildKite (oidc: Buildkite support #499)
  • Fulcio: Add Buildkite OIDC to Fulcio fulcio#890

See also https://dlorenc.medium.com/a-bit-of-ambiance-comes-to-sigstore-f80d1d6b1c30

This issue is tracking support for SaaS products and not self-hosted instances, e.g. GitLab's hosted product and not their on-premise or self-hosted services. Self-hosted services are out-of-scope, pending further discussion with Fulcio.

[woodruffw]

Specifically, for GitHub action, we'll need:

1. To confirm that we're running on a GitHub Action
2. To do the Python equivalent of this curl:

   curl -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=sigstore"

3. Parse the JSON response and grab the .value key, which contains the actual JWT

[jglick]

Jenkins supports OIDC identities including customizable audience, but I am guessing this system only works from a SaaS for which you can register a specific permanent issuer? The discussion of GitLab leaves it unclear whether self-hosted would be supported, or only the SaaS. (Of course if you run an agent on GCP then you could use its service account though that seems like a lower-level identity.)

[di]

Yeah, the configurable issuer is problematic because Fulcio needs to add support for accepting tokens from each unique issuer.

This is probably worth raising as an issue on https://github.com/sigstore/fulcio instead!

[jglick]

Right. To the extent I follow the discussion, this sounds related to sigstore/fulcio#444. Sorry for any noise; I would suggest clarifying mentions of dual-mode systems like GitHub Actions or GitLab that it is the SaaS that is under discussion, whereas self-managed editions cannot be supported in the same way.

[woodruffw]

Sorry for any noise; I would suggest clarifying mentions of dual-mode systems like GitHub Actions or GitLab that it is the SaaS that is under discussion, whereas self-managed editions cannot be supported in the same way.

Not a problem at all! This is indeed an important clarification; I'll update the top-level issue body to emphasize that we're aiming to support SaaS instances of these services.

Edit: Done.

[di]

Bit of an update here: CircleCI has marked support for customizable aud claims as planned: https://circleci.canny.io/cloud-feature-requests/p/customizable-audience-claim-in-oidc-tokens

[woodruffw]

Popping this off 1.0, since we've completed the core work here and are now waiting on individual OIDC providers to unblock us.

[woodruffw]

Just for tracking purposes: looks like Fulcio might be getting BuildKite support in the near future as well: sigstore/fulcio#890

[woodruffw]

Looks like BuildKite support is now merged upstream, so it shouldn't be blocked here.

cc @sj26: in terms of obtaining an ambient OIDC credential: should we attempt to spawn buildkite-agent, or would it be okay for us to rely on the stability of the HTTP endpoint you mentioned in sigstore/fulcio#890 (comment)? If the latter is considered stable we probably have a slight preference for it, in terms of not spawning unnecessary processes in a sigstore end-user client 🙂

[sj26]

Oh, this looks great!

... should we attempt to spawn buildkite-agent, or would it be okay for us to rely on the stability of the HTTP endpoint ...

The HTTP endpoint is part of a private API for the buildkite-agent. It should remain stable, but I can't guarantee. There are some details negotiated by the agent, and the transport channel may evolve over time. So, at least for the moment, I would advise using the buildkite-agent command. That's our official public API for this stuff. It's a go binary that shouldn't take a significant time to run.

[woodruffw]

Makes sense, thanks for the explanation! In that case we'll use the binary 🙂

[woodruffw]

cc @jleightcap or @tetsuo-cpp mind taking a stab at BuildKite support here?

It looks like pretty much all we have to do is:

buildkite-agent oidc request-token --audience sigstore

...after we've confirmed that our environment is a BuildKite one (i.e., we should look for BUILDKITE=true in the environment + make sure that buildkite-agent is on the $PATH).

ref: https://buildkite.com/docs/pipelines/environment-variables

[tetsuo-cpp]

Working on this now.

[tetsuo-cpp]

Looks like GitLab OIDC is on its way too: sigstore/fulcio#983

[di]

Looks like GitLab now supports a customizable aud claim: https://docs.gitlab.com/ee/ci/secrets/id_token_authentication.html

[di]

CircleCI now supports a customizable aud claim: https://circleci.com/docs/api/v2/index.html#tag/OIDC-Token-Management

[woodruffw]

CircleCI is now unblocked, pending upgrade of id to 1.2.0: di/id#144

[woodruffw]

GitLab is also implemented upstream in id, so this is fully closed out.