cosign builtins

[srenatus]

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:

1. 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? 💭

2. 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...?

3. 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)

[srenatus]

(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.

[srenatus]

👉 sigstore/cosign#532

[stale]

This issue has been automatically marked as inactive because it has not had any activity in the last 30 days.

[developer-guy]

kindly ping here, any updates @dlorenc @mattmoor @hectorj2f? 🙏

[developer-guy]

https://github.com/bhoriuchi/opa-plugin-functions

[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.

[stale]

This issue has been automatically marked as inactive because it has not had any activity in the last 30 days.

[stale]

This issue has been automatically marked as inactive because it has not had any activity in the last 30 days.

[Dentrax]

@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.

There is an ongoing discussion on cosign that we can track here: sigstore/cosign#1462

[stale]

This issue has been automatically marked as inactive because it has not had any activity in the last 30 days.