Managing trivy fanal db in operational environment

[dh-seanmurphy]

Hi all,

We've been using harbor for some years now - great tool!

Maybe unlike many folks, we use it via docker compose on a VM.

We use artifact scanning selectively (we did have it enabled for all artifacts, but it consumed too many resources for us so we reduced coverage). We have found that the fanal database is getting quite large and we're not sure about the best approach to managing this. I've seen some commentary that this is essentially ephemeral content and can be safely removed and in a kubernetes content a simple pod restart can be used to clean this up.

In our case, we have the trivy-adapter container and the content it manages is mounted into the container; hence fanal is persistent and a simple restart would not solve the issue for us.

I have some questions:

• is it true that the fanal db is essentially a cache and can safely be removed?
• what happens if the db is removed while a scan is ongoing?
• i see there is a trivy clean command which somehow can clean up content including the cache - can i safely run this from inside the trivy-adapter container? Iiuc,, boltdb only permits a single connection at any point in time - how does this interact with trivy clean?

More generally, if anyone has advice on dealing with fanal in this context, it would be appreciated.

Thanks,
Sean.

[MinerYang]

Hi @dh-seanmurphy ,

Thanks for connecting with us.

• Generally, fanal.db is a local cache for holding os/package info , metadata for each image layers that avoid keeping fetch from internet each scanning and it cause endlessly growing while you keep scanning new images.
• There's no automatic purging for fanal.db, and Yes you could safely remove it by deleting the db file manually. Once it been deleted, trivy would re-fetching all these package/vulnerability info from internet on the next run.
• You could either manually deleteing the scan cache by rm -rf /home/scanner/.cache/trivy/fanal or running cmd trivy clean --scan-cache

More info could refer to : #16606

[dh-seanmurphy]

Thanks for the clarifications here @MinerYang.

Do you have any insights wrt performing this when a scan could be ongoing? Does this break things badly, or would (perhaps?) harbor just see a failed scan and just try to run it again?

[MinerYang]

Thanks for the clarifications here @MinerYang.

Do you have any insights wrt performing this when a scan could be ongoing? Does this break things badly, or would (perhaps?) harbor just see a failed scan and just try to run it again?

I would say it might failed due to some io error or generate incomplete report if deleting the fanal.db during a scanning process. You may get more details from aquasecurity/trivy community.
So my suggestion is only cleanup the db between scans or if you are aware of there's a misbehaving during a round of scanning, you should re-run another round.

[dh-seanmurphy]

Thanks for your help here @MinerYang - to close this out, I'll just note here what we did.

We created a new container based on trivy-adapter which has an entrypoint which runs the cleanup. We run this nightly.

That keeps our fanal.db in check but perhaps means we download a bit more content.