feat: fixes for release 1.0

[vishal-chdhry]

Explanation

Closes #54
Closes #56
Closes #57

This PR adds an option called imageReferences that can be used to specify which images to verify

[JimBugwadia]

@vishal-chdhry - I am not sure why this is necessary. We should be able to support images signed with notation and AWS signer but stored in registries other than ECR.

[vishal-chdhry]

@JimBugwadia It is possible that someone is using an image like busybox/nginx for init containers, notation will try to verify those and fail

Besides, verification of images outside of ECR + AWS Signer context can be done using kyverno and I dont think it will be any helpful to try to verify them here as this focusses on AWS signer and ECR

[JimBugwadia]

@vishal-chdhry the question is on images signed by notation and the signer binary, but stored in registries other than ECR. Those cannot be verified without the extension.

[vishal-chdhry]

@JimBugwadia , we can add a field for matching image references like to filter images instead of making it strict

[JimBugwadia]

@vishal-chdhry - that sounds good.

Should we add a imageReferences and skipImageReferences fields as variables in the policy that are passed to the extension?

Or can we get this from the configured TrustPolicy CR?

[vishal-chdhry]

Yes we can configure trust policies to skip images that don't match.

And if the goal is to only mutate digests for verified image ( since Kyverno covers the other scenarios) then this change is not needed.

[JimBugwadia]

And if the goal is to only mutate digests for verified image ( since Kyverno covers the other scenarios) then this change is not needed.

So, the user would use 2 policies? Something like this:

1. first policy: configure the TrustPolicy to only match images signed by notation & signer and mutate their digests
2. second policy: match everything else and use required, verifyDigests, mutateDigests, and skipImageReferences to cover the rest of the images

Can you create samples for how to achieve this for the use case mentioned in #57? We can add that to the docs, as it seems to be a fairly common use case.

Reading the description in #57 - seems like we may still meed to change the response to indicate which images have been skipped, so we do not create a patch for those.

[vishal-chdhry]

So, the user would use 2 policies? Something like this:

1. For the first policy they will match and verify images based notation trust policy. The images that are skipped during verification will not be mutated.
2. A kyverno policy that fetches and mutates digests.

Can you create samples for how to achieve this for the use case mentioned in #57? We can add that to the docs, as it seems to be a fairly common use case.

Sure

seems like we may still meed to change the response to indicate which images have been skipped, so we do not create a patch for those.

Adding a change where patch is not created if the image is skipped.

[vishal-chdhry]

@JimBugwadia Even if the trust policy filters image, we will still need to filter images since artifact reference must contain a digest, therefore we have have to resolve the digest before passing it to notation.

Because of this we will try to resolve digest of every image and we will fail for those images that cannot be accessed by kyverno-notation-aws, so trust policy filtering is not enough.

(Notation has a function to check images skipped by the trust policy but I could not use it with an image with tag.)