Can Trivy download be disabled?

[ctrahey]

I'm using Zot to test some code that interacts with OCI registries, so my test harness comes with pre-baked images etc. I am bundling up the data directory for easy re-creation of the known state of the registry for use in automated testing. It's easy to remove the trivy directory before bundling, but I wonder if it is possible to configure Zot to never even download it...

[andaaron]

Hi, you can disable Trivy altogether using the config file, if that is what you are looking for.

[polarathene]

disable Trivy altogether using the config file

I am wondering if that's documented well though?

I did start at the admin configs page, but browsed the sidenav on the right looking over the "Security and Hardening" section for where I thought the relevant setting would be documented, only to find at the end of that section a link to another page which spoke of vulnerability scanning but no reference to related config.

Scanning through the docs, when looking for this specific feature to disable, you may land across different sections like these (via navigation or different keywords to try narrow it down):

• https://zotregistry.dev/v2.1.10/admin-guide/admin-configuration/#additional-security-features
• https://zotregistry.dev/v2.1.10/general/architecture/#security-scanning
• https://zotregistry.dev/v2.1.10/articles/security-posture/#vulnerability-scans
• https://zotregistry.dev/v2.1.10/articles/scaleout/#cve-repository-in-a-zot-cluster-environment

At some point you may get a hint from landing at the search extension description (which mentions vulnerabilities) that you should be interested in viewing the search extension config section which has cve (and no mention of Trivy like other earlier links).

After finally finding the actual setting you want to disable, it's not exactly obvious how to do that until you go to the top of the document where that is explained as disabled by default. One might argue that users should have read that at an earlier point, but often configs have defaults with features enabled even if the config snippets were removed 😓

When you use the container image, the instinct to look at the config contents may not have been the first thought vs first looking up the setting and how to disable it 🤔 Otherwise it may have been a bit more obvious (apart from the bundling of it in the search extension which may spur further verification for a hidden default setting):

zot/build/stacker.yaml

Lines 30 to 36 in aaba362

	"extensions": {
	"search": {
	"enable": true,
	"cve": {
	"updateInterval": "2h"
	}
	},

---

Just thought I'd chime in that while it's straight-forward when you're more familiar, there's a variety of ways to approach discovering the relevant information as an unfamiliar user, for which the docs are rather heavy on noise (even when attempting to use the docs search with keywords).

Might be worthwhile in this case to link to the extension setting from some of those references I provided, along with the actual config description mentioning Trivy (my initial keyword for searching for an unknown config name).

[andaaron]

I understand your point of view, we can improve on this.

The search is optional and disabled unless someone explicitly adds it in the configuration. The "cve" key under search is also optional (and Trivy is currently the only implementation for CVE scanning). None of these are enabled by default. If they are, we have a bug we need to fix.

So our rationale was: if the user added the search and cve configurations, he knows they exist, and why he added them.

[andaaron]

There is also https://zotregistry.dev/v2.1.10/admin-guide/admin-configuration/?h=cve#scheduling-background-tasks.
We should review the whole documentation and come up with clear instructions about CVE scanning.

[andaaron]

Actually we were tracking this project-zot/project-zot.github.io#138, completely forgot about it.

[polarathene]

Thanks for the link, that has plenty of useful information!

Given the lack of resources to address it in a timely manner, perhaps an interim solution is to include a link in the docs to that Dec 2023 comment? It's been 2 years almost since that was made, so some visibility/discovery is probably better than none due to lack of time to revise into polished docs?

So our rationale was: if the user added the search and cve configurations, he knows they exist, and why he added them.

That would be sound, except the official image is shipping the config enabled by default as my reference above shows.

The docs you link point out the extra cost to storage usage and memory/CPU overhead from image scanning, it may make sense to prefer offering that as an implicit default for production deployment if custom configs are that unlikely, but informing image users upfront can help identify that more quickly and how to go about disabling it.

For my personal usage so far, I haven't yet adopted a self-hosted registry and only spin it up temporarily for some troubleshooting locally or reproduction examples. That's been helpful when trying other tooling with registries that don't document support for certain features (or lack of them, such as referrer API with ghcr.io IIRC last I checked), or when iterating on an image and CI pipeline where it's a faster feedback loop to run entirely locally.

I don't know how common that is, but in cases like that the CVE scanning is completely unnecessary and brings in overhead I don't want. I know there's a more minimal image, but when wanting to use other extensions it's helpful to know about the config situation without wading through docs / search queries 😅