Allow using Starboard with Trivy plugin in air-gapped environments

[danielpacak]

When Starboard is using Trivy plugin in Standalone mode Trivy will pull its vulnerability database from the GitHub release page.

Trivy standalone binary has the --skip-db-update flag to disable database downloads and use pre-downloaded file instead. This mechanism can be used in air-gapped environment.

For Starboard to support air-gapped environments we could think of a solution that allows configuring Trivy DB container image, i.e. docker.pkg.github.com/aquasecurity/trivy-db/trivy-db:latest, which may be used as an init container (configuration container pattern) to the main Trivy container that performs scan.

Work on this issue should start off with the discussion in the comment how a scan PodTemplate would look like when the air-gapped flag in on. It should also define new configuration parameters if required.

[kfox1111]

What additional info is required?

[danielpacak]

What additional info is required?

I've updated the description and removed the label to mark this issue as ready for development.

[kfox1111]

Just taking a glance at things, I think this could be handled by building a trivy container with the database already in place and disabling the initContainer, that does the download and volume?

[danielpacak]

Just taking a glance at things, I think this could be handled by building a trivy container with the database already in place and disabling the initContainer, that does the download and volume?

This is a quick win but how would that fit into existing Starboard architecture and plugins ecosystem? How would you build and release such custom Trivy image? Would it be part of Starboard or Trivy or 3rd party repo? We strive to not host scanner specific extensions and customisations in this repo to facilitate maintenance. That's why I suggested reusing existing container and just run it in the init container. WDYT?

[kfox1111]

I'm not sure why the Trivy image doesn't already produce a Trivy + up to date db version of the image. The db image would just be an additional layer and would utilize the docker cache well. The Starboard job would just need to be modified not to force pull a new db, but skip it if it notices its already there. Minimal changes on both sides really.

[kfox1111]

In fact, the job is already trivy specific, as it does call trivy two different ways so it knows some of the internal details of it.

[danielpacak]

I'm not sure why the Trivy image doesn't already produce a Trivy + up to date db version of the image. The db image would just be an additional layer and would utilize the docker cache well. The Starboard job would just need to be modified not to force pull a new db, but skip it if it notices its already there. Minimal changes on both sides really.

Trivy DB is being updated every 6 hours and published to GitHub and some public container registries. Trivy binary release has completely different lifecycle. Starboard is one of many possible integrations where Trivy is used as vulnerability scanner. Therefore, we keep data (Trivy DB) and logic (Trivy command) separate. Anyway, we won't change Trivy architecture in scope of this issue but you can share your ideas by creating relevant discussion in the Trivy repository.

[kfox1111]

Docker uses a layered structure. If you:

FROM TRIVY:latest
RUN trivy DBSYNCTHING

and publish those images too. only the db layer would change from version to version and would not incur additional overhead over the trivy container it inherits from. That can be built / pushed every 6 hours too.

The really nice thing about it, is if there were multiple instances running on the same node, the cache layer would automatically share between the running instances as would keeping the image cached on the node if space was available so subsequent starboard jobs would launch faster as trivy/db is already cached.

It also would make air-gapped environments easier, as you would just mirror the image to your local registry, which you already need. So no special types of things would need to happen for trivy compared to other software that is airgapped in the same environment.

I can file a discussion item for it. Thanks for the pointer.