-
Notifications
You must be signed in to change notification settings - Fork 509
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
support verification of the signature with multiple public keys #950
Comments
Yes, this scenario makes sense and we are planning to donate that implementation to cosigned. |
As briefly detailed here #594 (comment), it will support multiple keys. |
Regarding AND or OR question, we are today following an OR approach. However I am more inclined towards an AND that follows an airport security checking approach. |
So, can we start working on the implementation of it with an AND approach, or what are the other concerns should we consider first? |
I'd like to hear @dlorenc thoughts about which approach would fit better. |
I think either one is fine, it worries me that it might not actually be clear though :( AND is safer since it would "fail closed". |
I wonder if it would make sense to move this up to the policy level rather than in flags. What if you could pass in a simple cue file with public keys, that could contain more complex and/or logic:
etc. |
Also: I think there are at least three places we can handle this (maybe differently!):
|
AND is safer but OR is a valid use case. "admit the pod if the image was signed by this system/team or that system/team or this vendor" etc. probably more common than the AND use case. my position is that the user should have the choice to configure AND or OR, or 3 of 5, or at least 2, or whatever. |
For the CLI, would it be fair to have flags specifying the policy (i.e., |
Yep... in the CLI where it's implicit I'd feel safer with AND. I'd rather figure out a way to be explicit about it though. |
Just asking out of curiosity, sorry if i am off topic. |
Yes probably! I wrote this up with some other ideas on custom polices: https://gist.github.com/dlorenc/a9681f6c0ed08a7710ba52a7f76887f6 I'd love some early feedback! |
Currently Something like this: type Verifier interface {
VerifySignatures(signatures []oci.Signature, opts ...signature.VerifyOption) error
}
type MultiKeyVerifier struct {
// the number of verifiers that must be applied (defaults to 1)
// - all: min = len(verifiers)
// - any: min = 1
// - count (e.g. 2/5): min = count
min int
// the list of keys to attempt
verifiers []Verifier
}
func (mv *MultiKeyVerifier) VerifySignatures(signatures []oci.Signature, opts ...signature.VerifyOption) error {
// todo - verify signatures based on signature sets
return nil
}
type CueVerifier struct {
// todo - declare or construct a Cue policy
}
func (mv *CueVerifier ) VerifySignatures(signatures []oci.Signature, opts ...signature.VerifyOption) error {
// todo - verify signatures based on Cue policy
return nil
} We can then support different verifiers e.g. CueVerifier, MultiKeyVerifier, SingleKeyVerifier, etc. that perform the necessary checks and pass or fail the entire signature set or attestation set. |
Kind ping here 🙏 |
Issue/PR may be relevant. |
Hi @houdini91 @Dentrax - is the plan to use the |
Hi @JimBugwadia, IMHO, there are things that we have to decide what we should do first like:
am I right @dlorenc @hectorj2f ? |
Yes, you are right in my opinion.
For our use cases, we need to answer this question ☝🏻 which is more important at this moment. It should be configurable because it sounds like a realistic situation at many customers.
I am not sure this is necessary if we decide on using cue to define the AND/OR policy for the keys, as proposed from @dlorenc . |
I am down with what ever the community leader think is best.
|
We have a use case for the OR multiple public keys. On testing we can see only AND support currently, has the support for OR based multi-keys stalled over the last 2 years or has it been taken elsewhere? |
Description
The idea is actually came from here1. We can support verification of the signature with multiple public keys, I couldn't think over the design much yet but, at the end of the day it might look like the following:
cc: @Dentrax @dlorenc @JimBugwadia @hectorj2f
Footnotes
https://github.com/kyverno/kyverno/issues/2583 ↩
The text was updated successfully, but these errors were encountered: