Enable client/server mode for trivy by default to cache the vulnerability DB (closes #911)#1760
Conversation
J12934
left a comment
There was a problem hiding this comment.
Looks really good 👍
One major thing missing is mentioning it in the docs. How it works and how it can be disabled and why somebody would want to do that.
Also the existing caching docs should then be tweaked as the no longer make much sense now that we have this in place.
| labels: | ||
| app: trivy-database | ||
| spec: | ||
| replicas: 1 |
There was a problem hiding this comment.
Should probably be configurable to have more then one replica available to support real HA setups
There was a problem hiding this comment.
I've looked into kubernetes scaling and autoscaling but I guess it's enough to move this values so it can be configured at least?
4652c82 to
0c2ab34
Compare
|
I've tested what happens when the trivy server cannot download the database, and it just exits with an error, so the pod gets restarted and then runs into CrashLoopBackoff. Since I didn't define a dependency on the cache service (other than using the url in a parameter), would the scan even wait for the cache to be ready? |
307c8db to
6d9395b
Compare
a06927b to
b914636
Compare
This uses the trivy client/server functionality to download the vulnerability DB only once for multiple scans to avoid GitHub's rate limit. An additional container running trivy in server mode is started, and all scans connect to it. This integrates the functionality previously documented [in the SCB docs for trivy][1], now that trivy supports remote scanning for more than just container image scans. [1]: https://www.securecodebox.io/docs/scanners/trivy/#scanning-many-targets Signed-off-by: Lukas Fischer <[email protected]>
Instead of hardcoding only one replica, allow any number of replicas for the trivy download cache to be configured by using the the trivyDatabaseCache.replicas value. Signed-off-by: Lukas Fischer <[email protected]>
Trivy server provides a /healthz endpoint that always returns 200 (see aquasecurity/trivy#534), and according to the logs/stdout trivy only starts listening after downloading the database. The helm chart provided by trivy (added in aquasecurity/trivy#751) uses this endpoint for liveness and readiness checks as well. This change therefore integrates the same checks. Signed-off-by: Lukas Fischer <[email protected]>
Update the documentation to reflect that the trivy vulnerability DB is now by default served by a trivy server container. This shortens this section of the documentation quite a bit, because most of it was example code to set up what is now integrated. Signed-off-by: Lukas Fischer <[email protected]>
b914636 to
8239741
Compare
Description
This uses the trivy client/server functionality to download the vulnerability DB only once for multiple scans to avoid GitHub's rate limit. An additional container running trivy in server mode is started, and all scans connect to it. This integrates the functionality previously documented in the SCB docs for trivy, now that trivy supports remote scanning for more than just container image scans. Client/server support for other scan types was added in aquasecurity/trivy#1829 and aquasecurity/trivy#3131.
Closes #911.
Checklist