Small improvements and ideas

[jackalsh]

While playing with connaisseur I found some small issues, whose are not really bugs, but still should be improved at my opinion.

• Alerting mechanism produces a lot of pythonic exceptions in the logs, causes a noise. Please allow disable alerts, they should not be enabled by default.
• When I define validator with auth.secret_name it tries to create a Kubernetes volume which name include validator name. In your default values file those names use underscores, whose results in invalid volume names. Please replace them dynamically in the chart by dashes or change values inside the values.yaml to avoid this issue.
• In default chart installation you use default validator for ".". Default validator, as I think is bad practice. Explicit is better then implicit. Especially in security focused solution. Especially if same functionality can be received by adding one more line with validator reference. But this this arguable. I would use allow validator here with additional comment for users to replace it to deny when tested. In this case you dont need detectionMode feature at all.
• Default validator is unusable out of the box, because there are not default root key. It leads to this exception: denied the request: Trust root "default" not configured for validator "default".\n"}.
• Controller logs are not very informative. I would assume to get clear information if my image was approved or denied, which validator it matches and so on. Now it is not always clear from context. For example, following message is confusing: "automatic child approval for". Why it was approved? What validator approved it?
• Especially, if I use detectionMode, it produces event less logs, hard to understand if images were approved or not.
• Try to check if for each pod signature information can be added to kubectl describe events log. It will allow to track validation procedure from within the pod events.
• You define ImagePolicy CRD to set up rules. Please think on define additional Validator CRD. The idea is that adding new validator require restart of all the controllers to apply configuration, while adding new policy is dynamic.

Anyway, I believe connaisseur is a great tool, which has big potential to replace other solutions. It's biggest feature is cosign support. There are not really alternative tools making what connaisseur is doing using cosign. At my opinion, you should focus on cosign support as main feature and make it usable from a box. It took me couple of days to reverse engineer the solution to feet company's needs.

Thanks you.

[xopham]

@jackalsh thanks for the awesome feedback 🙏 Such input is very valuable to improve Connaisseur and we always try to include it in next developments!

Some notes on the points you mention:

• Point 1: I created a separate issue to drop alerting logs in case it is not configured: Drop alerting log entries when alerting is not configured #249
• Point 2: I noticed that before and if I understand you correctly, it should be covered in Normalize Validator names #180
• Point 3&4: We had longer discussions on these points and tried to find the best solution from a usability point of view while making sure that it is secure by default, i.e. no non-validated image is accepted per default. However, your feedback here is very valuable and we might re-discuss the defaults.
• Point 5&6: I created to a ticket to improve the logs: Improve logging output #250.
• Point 7: What do you mean by adding to the pod events log? Should approval/denial be added to connaisseur's event log (I am not certain if that is the right place)? Or should that be added to the events of the approved pod? Would be great if you could provide a dummy example.
• Point 8: That seems like an interesting point to tackle. It is partly covered in Fix helm upgrade / Connaisseur Update #181 . I also created Allow dynamic adjustment of policy and validator configuration #251

From a focus point of view, we will continue to support notary, but as that is unlikely to change much, I expect most future features to be focused on improving integration with cosign-based signatures. We already have a couple of tickets open in that direction and are currently trying to see what is the first topic to pick up. There is for example:

• Add rekor support for cosign #140
• Add support for keyless signatures for cosign #141
• Allow multiple potential public keys when using cosign #199
• Add support for other key types of cosign #201

Which additional features would you see? Which feature would you consider most useful to your case?

Many thanks again for taking the time to provide feedback 🙏 also, always feel free to open a PR directly in case you have built any improvement that you might want to share.

I might move this issue to our GitHub discussions within the next few days, as it cannot be directly tackled by a PR and I created concrete issues for each point you mentioned 🙂

[xopham]

@jackalsh as mentioned, I moved this into Discussions, as we extracted all actionable elements into separate issues 🙂
Maybe, we can get more feedback on the usability / default behavior questions here...

[xopham]

a discussion on the last point "dynamic configuration" and CRDs has been opened in #280 and we hope to get some community insights

[tommyreilly]

@xopham - our companies current use of cosign is to store the signatures with the images, which allows us to use connaisseur at k8s deployment time for policy/validation of the image. However our company are currently investigating using Rekor to have an audit trail/history of the images lifecycle through our CI->CD processes. If we went this way, we'd obviously be keen to see Rekor verification support added to connaisseur (#140).

https://github.com/sigstore/cosign#rekor-support

[xopham]

@tommyreilly thanks for reaching out. We are always interested in use cases. I have a few questions about this:

• how would the lifecycle be tracked via rekor?
• will it be signed multiple times?
• do you plan to use annotations and how will you verify the annotations?
• do you plan to use a private rekor instance?

Would be great if you could share some more technical details on the exact workflow 🙏

We are really keen on adding rekor support, there has just been a setbacks to implementing it right away. Rekor is still experimental (which is not a no-go in general). When last toying around with cosing using rekor, it seemed the -rekor-url flag was non-functional and there seemed no way to implement rekor w/o OIDC. The latter originally did not provide the option to specify a trust anchor (which we require and is now accessible via -cert-email) and in the latest release v1.2.1, the -cert-email flag seemed non-functional. So, we are currently hoping the next release will fix the bugs and would then see to integrate it.

[tommyreilly]

Thanks for the timely reply @xopham . We are too at early stages looking into Rekor. After our initial deployment of using cosign+connaisseur to meet the need of preventing images from being deployed if not signed as we expect, our conversations have gone deeper regarding the CI lifecycle and the various stages we might want to sign. That is why we are starting to look at Rekor. Similar to what you say, it looks like cosign + Rekor is "early". When I've tested cosign with the rekor variable/arg, it adds the signature to the image location (as per the default) as well as saying it has added it to the rekor log - the former shouldn't happen afaik, i.e. it is a binary choice to store the image signature in the container registry or the rekor log, but not both.

For us, yes I would expect multiple signatures to be uploaded using the cosgin cli with the rekor support (e.g. one for base image verification, one for vulnerability passing, one for qa passing).

Not really though about annotations at this time and we would definitely want/need to use our own private Rekor instance that we setup and maintain.