Add support for Cirrus CI tokens

[fkorotkov]

disclaimer: I'm one of engineers working on Cirrus CI.

Cirrus CI exposes an OIDC token via $CIRRUS OIDC_TOKEN and allows overriding the audience via setting $CIRRUS_OIDC_TOKEN_AUDIENCE variable.

I'm following up this comment from the NPM's RFC. I wonder what will it take to add to add support for Cirrus CI?

From a brief check it seems it will require implementing something similar to pkg/identity/github?

[feelepxyz]

There is this issue laying out some requirements for new IdPs: #397

As one of the comments on this issue, do we need to expand the list of cert's SAN OIDs as it currently only includes a bunch of extension for GitHub Actions.

[haydentherapper]

Hey! To implement, either we will need to add a new IDP type, or restructure the github-workflows type. My guess is it'll be simpler to have some code duplication now and add a new type, until we can make the CI workflows generic. You'll need to:

• Add the new type ID here -

  fulcio/pkg/config/config.go

  Line 211 in 509c789

  const (

• Add the claim where the subject challenge is -

  fulcio/pkg/config/config.go

  Line 461 in 509c789

  func issuerToChallengeClaim(issType IssuerType) string {

• Add the new type to the PrincipalToIDToken function -

  fulcio/pkg/challenges/challenges.go

  Line 52 in 35b7117

  func PrincipalFromIDToken(ctx context.Context, tok *oidc.IDToken) (identity.Principal, error) {

• Create a new principal like https://github.com/sigstore/fulcio/blob/d54330c45f9c271fdf5b9d7eebe08284a700387f/pkg/identity/github/principal.go that implements Principal

There is this issue laying out some requirements for new IdPs

We'll need to evolve the IDP requirements to also handle IDPs for CI systems, as some of the requirements aren't relevant.

do we need to expand the list of cert's SAN OIDs

My preference would be to rename the existing SANs to be platform-agnostic, rather than register new OIDs for each CI IDP. I know there was a mention in the NPM RFC on working to standardize the list of claims for CI IDPs, that would be fantastic.

[dlorenc]

My preference would be to rename the existing SANs to be platform-agnostic, rather than register new OIDs

Either works for me. Renaming is simpler, no idea if that's frowned upon though.

[fkorotkov]

It seems in case of Cirrus CI's OIDC token it will already kind of work because we set iss claim as https://oidc.cirrus-ci.com/ which will work with your uri SAN. At least it seems so from the code...

From the discussion here and #397 it seems reasonable to wait for the "standardize the list of claims for CI IDPs". Right now the GHA's one has two very specific ones: GithubWorkflowTrigger (event_name claim) and GithubWorkflowName (workflow claim). Maybe something generic like external_url/details_url with a link to the original CI thing that created the artifact will work. Right now every CI that integrates with GitHub's Checks API already provides external_id and details_url so it can be referenced back from GitHub's UI.

[dlorenc]

This sounds good! I think we should probably get a document started for these new claims. Do you want to track them here @fkorotkov? Or we could use markdown in a PR.

[fkorotkov]

@fkorotkov up to you. But I think since the goal is to have a generic set of claims it doesn't make sense to track it in this PR? You all are the most knowledgeable people here, I can only input on the CI-related stuff.

[haydentherapper]

I’ll open a new issue in Fulcio to discuss more.

[dlorenc]

Do we have enough of a set of claims that we can try to add this one?

[fkorotkov]

Here is our configuration with claims. I should note one thing that we don't have a concept of run attempts like GitHub has. In Cirrus if a task is re-ran it will generate a new task with a unique id. But I guess in case of figuring out the origin of a given artifact it's even better to have such "immutable" entities.

[haydentherapper]

A lack of run attempts shouldn't be a blocker, we don't encode that in the identity. Do you possibly have a one to one mapping between the necessary GitHub claims? In particular, is there anything like job_workflow_ref?

An example of what's required:

{
    "job_workflow_ref": "octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main"
    "sha": "example-sha",
    "event_name": "workflow_dispatch",
    "repository": "octo-org/octo-repo",
    "workflow": "example-workflow",
    "ref": "refs/heads/main",
}

[fkorotkov]

• job_workflow_ref can be constructed from other claims. In our case the config can only be defined in .cirrus.yml and/or .cirrus.star files so there is no need to provide a "workflow path". job_workflow_ref == "${owner}/${repository}@${ref}"
• sha is the same as change_in_repo
• event_name not yet supported
• repository looks like a full name so it will be equal to "${owner}/${repository}"
• workflow can be mapped to task_name.
• ref can be constructed from calims:
  • if tag is defined then "refs/tags/${tag}"
  • if pr is defined then "pull/${pr}"
  • otherwise it's `"refs/heads/${branch}"

event_name - something that we don't have concept of at the moment. You kind of can see if that was a PR, release or tag based on pr, release and tag claims respectively. If event_name is a blocker we certainly can add something like that to map it to the GitHub event that triggered it (we plan to support other platforms in the near future but they also have concept of events).

[haydentherapper]

Hi y'all, if you are interested still in adding support, check out #890 as an example PR. There's also the open PR #945 that discusses the set of claims we'd like to include in every certificate from a CI identity, although we can start with a minimum set of claims initially (audience as long as it is customizable to sigstore, issuer, and a value like job_workflow_ref)