Extract additional claims from github-workflow token

[ckotzbauer]

With reusable github-workflows the "job_workflow_ref" will reference the shared workflow instead the actual calling workflow.

Summary

This adds the additional infos repository, workflow and ref from the Github-Workflow OIDC token as described in #305. According to the Github-Docs I added the repository field instead of the repo.

Ticket Link

Fixes #305

Release Note

job_workflow_ref info was insufficient when using with shared github-workflows

[nsmith5]

I believe this additional information also needs to be embedded into the x509 code signing certificate to fix #305. You can see here where the trigger and SHA are added. I believe you'd need to create new extensions for this new data and additionally document them here like the existing ones.

[ckotzbauer]

Thanks for your comment @nsmith5, I will add the extensions and the docs.

[ckotzbauer]

@nsmith5 I added the new claims to the signing-cert and the docs now.

[nsmith5]

Nice, great work! I'm not a maintainer so can't approve the workflow / merge, but this looks good to me

[nsmith5]

cc @mattmoor for 👀

[mattmoor]

cc @dlorenc to merge/deploy once CI passes.

[bobcallaway]

The code looks good to me; one thought though: should we consider using a separate child OID for GitHub-specific fields rather than keeping them all at the same depth? If we add information from other CI/CD systems it might make sense to separate them, but I'm curious to hear what others think.

[dlorenc]

The code looks good to me; one thought though: should we consider using a separate child OID for GitHub-specific fields rather than keeping them all at the same depth? If we add information from other CI/CD systems it might make sense to separate them, but I'm curious to hear what others think.

I'd be fine with that. I think we can nest them arbitrarily long.

[ckotzbauer]

@dlorenc @bobcallaway Should the nesting be part of this PR? If yes, how is it supposed to look like?

[dlorenc]

I'm fine either way since we already have some un-nested Github OIDs. We could start nesting other providers going forward.

Wdyt @bobcallaway?

[bobcallaway]

this PR is fine as is, we can nest them in a separate one.