Certificate identity for GitHub Actions reusable workflow keyless signing

[sagikazarmark]

    Let's say I have a reusable `workflow A` that builds and signs container images on GitHub Actions using keyless signing.

When I call this from workflow B the certificate identity is going to be the workflow ref for workflow A.

It doesn't sound like a huge deal, but imagine that reusable workflow is from a third-party: the certificate identity becomes a reference to a third-party workflow instead of my release workflow (workflow B).

From a consumer perspective, it's weird the very least.

I'm somewhat convinced this isn't cosign's "fault" as it probably just uses the identity coming from the ID token.

I'd be interested to know if others find this a problem as well or not. If not, why not?

Thanks!

[haydentherapper]

You're correct that the subject of the certificate will be the same, as it's derived from the reusable workflow reference, but there are other claims in the certificate’s extensions that allow you to differentiate between workflows. See https://github.com/sigstore/fulcio/blob/main/docs/oid-info.md for more information.

The OID for workflow is Build Config URI, https://github.com/sigstore/fulcio/blob/main/docs/oid-info.md#13614157264118--build-config-uri, whereas reusable workflow is Build Signer URI (and the Subject Alt Name), https://github.com/sigstore/fulcio/blob/main/docs/oid-info.md#1361415726419--build-signer-uri. Note that these are newer OIDs that are standardized across CI platforms, and are actively being implemented for GitLab and Buildkite too. There are older OIDs we've marked as deprecated that will be present in previously issued certificates that represent workflow just for GitHub Actions, https://github.com/sigstore/fulcio/blob/main/docs/oid-info.md#1361415726414--github-workflow-name-deprecated.

[laurentsimon]

@laurentsimon Thanks for the suggestion! I'm guessing that would still use cosign under the hood somehow?

It's using Sigstore, yes; and cosign format for container's attestations. Feel free to ask question on the generator repo if you have questions.

[laurentsimon]

Any further thoughts, insights, tips would be greatly appreciated. I'm trying to bring the above mentioned and more projects implement the (current) best practices and once I understand how things are working, I'd be happy to spread the word in the community, write some blog posts, etc.

what's a good contact to chat? Happy to have a chat. I agree not everything is crystal clear today, but I can give you a sense where things are going

[sagikazarmark]

Any chance you'll be at OSS NA? I'm on CNCF Slack as "Márk Sági-Kazár".

[laurentsimon]

I will! I have issues accessing CNCF slack. I'm on the OpenSSF and Sigstore slack though. Or shoot me an email at github-username AT google dot com

re: provenance gen. For containers you would need to use https://github.com/slsa-framework/slsa-github-generator/blob/main/internal/builders/container/README.md. In general, https://github.com/slsa-framework/slsa-github-generator#generation-of-provenance has a list of builders / generators to use.

[haydentherapper]

I'll be around too, happy to chat with y'all :)