andrewwebber / kate

Because Clair needs a friend
Apache License 2.0
31 stars 1 forks source link

Unnecessary Rescanning #1

Open jzelinskie opened 7 years ago

jzelinskie commented 7 years ago

Hey there. I'm a Clair maintainer and just found this project. It's a really awesome idea to integrate Clair closer with Kubernetes. There were a couple things I noticed from a quick glance that I think you should be aware of.

Kate will also rescan all the images every couple of hours just to let you know if the CVE situation has changed.

Notifications are built into Clair and Clair is designed to not require rescans, unless the Clair has been upgraded to support detecting new features. As per the Clair README:

Vulnerability data is continuously imported from a known set of sources and correlated with the indexed contents of container images in order to produce lists of vulnerabilities that threaten a container. When vulnerability data changes upstream, the previous state and new state of the vulnerability along with the images they affect can be sent via webhook to a configured endpoint.

I also recommend using the Clair API rather than shelling out to the analyze-local-images binary. This binary is for local testing, was written extremely quickly, and is likely to be removed at some point.

PS: I really like the name.

Quentin-M commented 7 years ago

Howdy,

Clair's dad here. I couldn't be happier to see our beloved Clair getting her very first friend. The potential that Kate has to bring security awareness to Kubernetes users is outstanding. This is indeed a fantastic idea and it really feels like an extremely valuable use-case for Clair - probably as important than its original integration to container registries.

I'd like to back @jzelinskie up regarding to the usage of analyze-local-images and re-scans. I am available for any questions you may have, or help you want.

andrewwebber commented 7 years ago

@jzelinskie @Quentin-M A great honor to have the Clair folks take an interest here. I dont pretend to know anything about the inner workings of Clair and this is nothing more than a spare time proof of concept. Having said that, looking at Clair, it was easiest to get up and running shelling out to bash analyze-local-images. I wasn't able to understand how to use the Clair API without the bash analyze-local-images example as a reference. Also the bash analyze-local-images example, as I understand it, is Docker based and I would like to get this also working for RKT. Presumably a solid bash analyze-local-images implementation is still useful as in this case my understanding is that an image still needs to be sent to the Clair service?

I am now aware of the concept of notifications and the need, or lack of, of re-scanning the images. Having said that I guess there still needs to be a way for Kate to pick up the notifications and service them via the REST endpoint and or push them to Prometheous. Kate could be this broker however this could also be supported in Clair natively.

From an architectural point of view one could put these feature requests into Clair and grow it. From a microservices point of view one might argue towards a strategy of seperation, hence the case for Kate or maybe 'Penelope' (moving notifications from Clair to Prometheus).

andrewwebber commented 5 years ago

@Quentin-M @jzelinskie I have migrated the scanner to use https://github.com/arminc/clair-scanner Hope that is an improvement