Open fkorotkov opened 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.
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:
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.
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.
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.
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 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.
I’ll open a new issue in Fulcio to discuss more.
Do we have enough of a set of claims that we can try to add this one?
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.
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",
}
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 supportedrepository
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:
tag
is defined then "refs/tags/${tag}"
pr
is defined then "pull/${pr}"
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).
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)
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
?