cosign
cosign copied to clipboard
sigstore
Using Cosign with GitHub Container Registry impacts pull metrics
Description
We've been happy to be using Cosign with KEDA!
We have noticed, though, that when storing signed container images on GitHub Container Registry the pull metrics in GitHub are going through the roof because of all the signature pulls.
Example: https://github.com/kedacore/keda/pkgs/container/keda
I'm currently checking with GitHub if this can be improved but wanted to open this as FYI.
Relates to https://github.com/kedacore/governance/issues/57
I don't really know if there's anything we can do here. I've noticed it too and the Github pull metrics seem inflated way beyond even what I would expect for just signature pulls. Thanks for raising it with them, if there's anything we can do on this side I'm happy to try!
@dlorenc Does cosign use local caching like docker cli does for signatures or are those pulled from the source of truth with each cosign verify?
No local cacheing right now. That's an interesting idea!
It would be very doable to resolve the tag <image digest>.sig to a signature digest and use a content-addressed cache in ~/.sigstore (or $XDG_CACHE_HOME/.sigstore).
The question is whether it's worth the increased complexity from doing so (it seems simple, but you have to worry about cache expiration, using too much disk space, etc.). You don't gain a whole lot in download bandwidth savings (signatures are pretty small, probably not much bigger than the response to "resolve this digest"). So it'd really just be to avoid impacting download metrics.
Do we know whether other OCI registries do anything about statistics for signatures?
@dlorenc @znewman01 I checked in docker hub and that also increments pull count on the repository when cosign verify is done (it just takes a while to update its pull counter)
I think there's nothing to be done on the Cosign end here. Maybe add an FAQ?
If GHCR had an option to annotate a signature object with "don't count pulls against download metrics" we could use it but I don't think realistically we're going to go through the trouble to get that added to OCI.
I think there's nothing to be done on the Cosign end here
IMO local caching can alleviate some of this concerns but yeah, we are planning to improve our detection of oci types based on layer media types