-
Notifications
You must be signed in to change notification settings - Fork 550
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
[Cosigned] Convert functions for webhookCIP from v1alpha1 #1736
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1736 +/- ##
==========================================
- Coverage 29.52% 28.96% -0.57%
==========================================
Files 141 141
Lines 8502 8394 -108
==========================================
- Hits 2510 2431 -79
+ Misses 5718 5697 -21
+ Partials 274 266 -8
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, so far.
|
||
"github.com/sigstore/cosign/pkg/apis/cosigned/v1alpha1" | ||
"github.com/sigstore/cosign/pkg/apis/utils" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: organize the imports as groups (sigstore ones, external, golang packages).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Going to organize it as golang packages, cosign, sigstore, k8s, and then knative. Then all alphabetical within those package groups (not based on the alias of the package)
@@ -37,7 +50,7 @@ type Authority struct { | |||
// +optional | |||
Key *KeyRef `json:"key,omitempty"` | |||
// +optional | |||
Keyless *v1alpha1.KeylessRef `json:"keyless,omitempty"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion: I am considering whether we should create again all the resources again. As a consequence, we should create the type for ImagePattern, Sources and Identities here to be consistent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@vaikas wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consistency is good indeed :) So, I'd be down for recreating them here, or always use one from the CRD. I don't think I have strong feelings on one or the other. If we can import the CRD ones, seems better to only have to update one place.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I kept the other ones as imports from the CRD because we arent currently manipulating it at the moment and it is a direct 1:1 mapping.
We actually manipulate keyRefs so that is why Authorities and key[less]Refs were re-implemented as required.
When the other properties diverge, I feel that updating it then makes more sense to keep potential updates in one place as Ville mentions until that diverging.
If there are any strong feelings for one or the other, it is easy enough to replicate the structs and updating tests.
@@ -84,9 +106,103 @@ func (k *KeyRef) UnmarshalJSON(data []byte) error { | |||
return nil | |||
} | |||
|
|||
func convertKeyDataToPublicKeys(pubKey string) ([]*ecdsa.PublicKey, error) { | |||
func ConvertClusterImagePolicyV1alpha1ToWebhook(ctx context.Context, in *v1alpha1.ClusterImagePolicy, rtracker tracker.Interface, secretLister corev1listers.SecretLister) (*ClusterImagePolicy, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rather not have Tracker / SecretLister exposed here. I'm envisioning using these functions for example, from Cosign the CLI for various reasons, so having the Tracker exposed or secretlister doesn't make sense.
I would rather have this be a three pass operation from the Reconciler:
- Resolve the inline references
- Convert to Webhook.
Right now I can't do the second one from CLI (or maybe from other users of this library) because I don't have secretlisters or trackers. So, I'd rather have a Convert function that only converts to inline webhook data with no side effects.
So, I guess I'd rather have a method in Reconciler that handles the CIP->CIP-With-References-Inlined as a method that can take trackers / listers as necessary.
Then, the second step would just take the CIP-With-References-Inlined and this has no side effects at all, and is re-useable from other places as a standalone method that will then allow those places to call the ValidatePolicy.
Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we see those functions been used somewhere else, then lets keep them where they can be reused.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
, I guess I'd rather have a method in Reconciler that handles the CIP->CIP-With-References-Inlined as a method that can take trackers / listers as necessary.
I like this option.
Signed-off-by: Denny Hoang <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for cleaning up the marshal/nonmarshal stuff woot woot.
func convertKeyDataToPublicKeys(pubKey string) ([]*ecdsa.PublicKey, error) { | ||
keys := []*ecdsa.PublicKey{} | ||
func ConvertClusterImagePolicyV1alpha1ToWebhook(in *v1alpha1.ClusterImagePolicy) *ClusterImagePolicy { | ||
copyIn := in.DeepCopy() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit, I think this is not stricly necessary because we don't modify, but since we use the images from L105 as inputs, can't think right now if that will make a difference.
Signed-off-by: Denny Hoang <[email protected]>
Signed-off-by: Denny Hoang [email protected]
Summary
Continual improvement to webhookCIP
Logic for inlinedData from secretRef and KMS moved from reconciler file to theclusterimagepolicy_types
for consolidation and removing bulk in reconciler fileclusterimagepolicy_test
already had decent coverage for all the inlining data etccc: @coyote240 @hectorj2f @vaikas