Description
Cosign (recently reached 1.0 🎉 👏) is a tool to create and verify signatures of OCI artifacts (not only images?).
It avoids having to deal with the entire blob (images can be huge, obviously) by signing and verifying a detached payload containing of the name and a content hash: see its signature spec.
A proof-of-concept of some useful builtins exists in sigstore/cosign here: https://github.com/sigstore/cosign/tree/main/copasetic.
Also for GK to consume, the simplest way would be to add some cosign-related built-in functions to OPA.
I think there are a few questions to be answered before:
-
dependencies
Unless I'm mistaken, the copasetic tool above is using the cosign go modules. We're trying to keep our dependencies light, so there's the question of how much of what cosign does we can cover without depending on the whole package? For example, would this still be useful without having access to hardware signing and KMS etc?
From what I understand, it's compatible with JWS, so we could perhaps reuse the dependencies we've already gotten in for JWT and friends? 💭
-
concrete builtin design
For JWT, we've got fine-grained verifications builtins, and the kitchen-sink "decode_verify" function that takes a bunch of arguments for options. How should this look like for cosign? What's the envisioned use case, would the rego policy fetch the payload (to be signed or verified) from somewhere, or should that happen transparently...?
-
testing
Maintaining built-ins that are interacting with third parties (like sigstore services, and perhaps the OIDC PKI and the timestamping service) are notoriously difficult to test, and thus to maintain. How can we limit that effort? Volunteer maintainers maybe? Or a good integration test suite for the new builtin?
(cc: @developer-guy @Dentrax @dlorenc)