-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cosign builtins #3697
Comments
(per @dlorenc's comment in slack) 👉 sigstore/cosign#437 With inline attestations, we could verify the image (cosign) signatures with golang stdlib means. That would perhaps strike a good match between being useful to many and light on dependencies and maintenance. |
This issue has been automatically marked as inactive because it has not had any activity in the last 30 days. |
kindly ping here, any updates @dlorenc @mattmoor @hectorj2f? 🙏 |
@developer-guy Wouldn't it help having all the common functions moved to sigstore/sigstore ? That is an on-going work if I am not mistaken. That would help to build a kind of SDK that will reduce the amount of dependencies. |
This issue has been automatically marked as inactive because it has not had any activity in the last 30 days. |
This issue has been automatically marked as inactive because it has not had any activity in the last 30 days. |
There is an ongoing discussion on cosign that we can track here: sigstore/cosign#1462 |
This issue has been automatically marked as inactive because it has not had any activity in the last 30 days. |
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)
The text was updated successfully, but these errors were encountered: