Skip to content
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

Open
srenatus opened this issue Aug 3, 2021 · 10 comments
Open

cosign builtins #3697

srenatus opened this issue Aug 3, 2021 · 10 comments

Comments

@srenatus
Copy link
Contributor

srenatus commented Aug 3, 2021

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
Copy link
Contributor Author

srenatus commented Aug 4, 2021

(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
Copy link
Contributor Author

👉 sigstore/cosign#532

@stale
Copy link

stale bot commented Nov 22, 2021

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

@stale stale bot added the inactive label Nov 22, 2021
@developer-guy
Copy link
Contributor

developer-guy commented Nov 23, 2021

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

@stale stale bot removed the inactive label Nov 23, 2021
@developer-guy
Copy link
Contributor

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

@hectorj2f
Copy link

@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
Copy link

stale bot commented Jan 19, 2022

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

@stale
Copy link

stale bot commented May 26, 2022

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

@stale stale bot added the inactive label May 26, 2022
@Dentrax
Copy link
Contributor

Dentrax commented Jun 17, 2022

@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 stale bot removed the inactive label Jun 17, 2022
@stale
Copy link

stale bot commented Jul 17, 2022

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

@stale stale bot added the inactive label Jul 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants