Expose Trivy server / twirp endpoint

[danielpacak]

Currently this Scanner Adapter exposes the REST API for Harbor and uses Trivy standalone (mode) to perform scans.

We could extend it and expose also Trivy server's twirp endpoint to allow Trivy clients to connect to the harbor-scanner-trivy deployment as depicted below. We could actually rename harbor-scanner-trivy to a more generic scanner-trivy deployment suitable for integrations with Harbor and other clients.

                       　　　　　　(Twirp request)
Harbor core ---→ scanner-trivy  -----------------> trivy-server 
 　　　　　　　 (HTTP REST Endpoint)                (Twirp Endpoint)
                      ↑                                 ↑
                      ↑                                 ↑
(deployed by Helm)    ↑                                 ↑
---------------------------------------------------------------------------
(prepared by a user)  ↑                                 ↑
                      ↑ (HTTP request)                  ↑ (Twirp request)
                   SDK/CLI                              ↑    
　　　　　　　for Pluggable Scanner API               trivy-client

//cc @knqyf263 @lizrice

[vzanlnx]

hey @danielpacak , thanks for openning this RFE. I'm going to provide more details about my environment in order to give some context for this specific need.

Today, our pipeline pushes images to harbor, where they are scanned and blocked, or not, depending how critical the vulnerability found is.

And we are changing this model to scan the image BEFORE push to harbor, and block the push process if a crit vulnerability is found. This can save some net transfer time with our pipeline.

We choose Trivy because it's scan granularity is way better than Clair and it also has a up to date cmdline which is possible to scan my local images the way we want, however our pipeline process is all ephemeral, all tests and steps runs in containers (including the scanner process), so instead of having a local cache in each pipeline host, we'd like to connect all clients in a server and use the same database.

Having the possibility to use trivy this way you propose will give benefits beyond have only one dbserver for harbor and clients, but also, we will have a high availability, scalable and more secure pipeline too, which is important in a production environment.

So, this feature will fit perfectly in our needs.

Thanks in advance.

[jhonatanmorais]

It would be very useful. Excellent explanation @vzanlnx!

[knqyf263]

@vzanlnx Thank you for your explanation. It completely makes sense and sounds interesting! We're waiting for @lizrice 's thoughts. Please wait for a while.

[rsilva-rs]

Also works for my company... Nice contribution @vzanlnx

[danielpacak]

@vzanlnx Sorry for not posting this earlier but we were busy making this adapter a default scanner in Harbor 2.0 as well as implementing some other requirements.

We put more thoughts into this requirement and for similar reason why we did not accept this PR for adding RethinkDB I tend to close this one as won't do.

The main reason is that this adapter service is really a thin layer between Harbor and Trivy CLI. The only requirement for this service was RESTful API implementing Harbor Pluggable Scanner API v1.0 Specification.

Adding code to support more interfaces such as Twirp makes this codebase bigger and bigger. Beyond that we're committed to maintain it and make sure that we can release a new version in a timely manner. /cc @knqyf263 @lizrice