sigstore / fulcio

Sigstore OIDC PKI
Apache License 2.0
651 stars 137 forks source link

Add support for Cirrus CI tokens #748

Open fkorotkov opened 2 years ago

fkorotkov commented 2 years ago

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 commented 2 years ago

There is this issue laying out some requirements for new IdPs: https://github.com/sigstore/fulcio/issues/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 commented 2 years ago

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:

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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

dlorenc commented 2 years ago

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

fkorotkov commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

Hi y'all, if you are interested still in adding support, check out https://github.com/sigstore/fulcio/pull/890 as an example PR. There's also the open PR https://github.com/sigstore/fulcio/pull/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)