Is Syft and Grype usable with this?

[perezjasonr]

Were going for a more lightweight approach with our cluster, we are using Syft and Grype which I am told anchore engine uses under the hood. Is it possible for the admission controller to leverage these instead, even as a feature request/future possibility, or does it have to be engine dependency?

Thank you.

[zhill]

Hi @perezjasonr , great question! Currently, no, the controller interacts with the engine/Enterprise APIs to make admission decisions. We've been thinking about syft/grype-based controllers distinct from this implementation, potentially with some slightly different features, but I'm interested in your thoughts as well.

What are the admission decisions you'd like to see for Syft? And for Grype?

[perezjasonr]

thank you for your interest and glad to know my idea wasn't totally "out there".
so i hope this isn't oversimplified but, at first we were likely thinking something along the lines of the core functionality most would look to get from anchore engine, meaning, scan, and based on severity level, allowance or rejection, registry whitelisting (or blacklisting i suppose), package/binary/rpm based rejection. Or I guess what I'm really saying is, as close as possible to engine features. Even if its not possible id be curious to know what all is feasible, and how close we could get.
But I admit I'm not 100% sure the ramifications of losing engine vs syft/grype.

although you might have to enlighten me a bit on where the gap might be between engine, and syft/grype, i realize it could be absurd me ignorantly saying "as much functionality as engine had possible", im sure there are things to overcome to accomplish that.

[zhill]

Great update, thanks! The main issue with using just Syft/Grype is performance of the scan since it needs access to the image itself and since both tools are stateless. In most cases you wouldn't want an admission decision blocking on executing a Grype scan that may need to update its vulnerability DB and pull a 500MB image from the registry (or multiple if the pod has many images). But, if performance isn't a concern, then a controller that orchestrates Syft/Grype directly is workable since Grype doesn't strictly require Docker anymore so it can easily run within a container itself.

Is this something you'd be interested in working on with us?

[perezjasonr]

i like the idea of having the option, perhaps it can be configurable and be told to use syft/grype as long as user is aware of said performance ramifications, i wonder if it could be the case that this only happens once and then the admission can remember the image digest so that it only happens the first time, or some thing to that effect. Perhaps you can also provide it in advance a list of images/digests as a conf option so it can start the process early?? just throwing ideas out there.

Yes I would be interested.