[FEATURE] Check if Trivy database download could be done authenticated

[HeavyWombat]

Is there an existing feature request for this?

• I have searched the existing feature requests

Is your feature request related to a problem or use-case? Please describe.

Trivy is used as part of the Test Suite and upon it's first start, it needs to download a database, which is hosted in a container registry. This can lead to a 429 response by the container registry with TOOMANYREQUESTS.

Describe the solution that you would like.

Check if we can authentication against the GitHub Container Registry so that the requests are not anonymously.

Describe alternatives you have considered.

Alternative would be to use an alternative location for the registry, where rate limiting isn't an issue. Need to check, whether quay.io would be an option. The location can be defined using TRIVY_DB_REPOSITORY environment variable.

Anything else?

No response

[qu1queee]

Some notes:

• for trivy tests, we rely on this image https://github.com/shipwright-io/build/pkgs/container/shipwright-samples%2Fnode , which we push via https://github.com/shipwright-io/build/blob/main/.github/workflows/mirror-images.yaml (crane auth automatically, so is not visible there)

[SaschaSchwarze0]

@HeavyWombat can you provide more details of where else a fix is needed = can you reference where you have seen the failures? In #1691, you only mention that it "potentially mitigates (parts of)" this issue and the scope is therefore unclear.

BTW: related Trivy feature: aquasecurity/trivy#3915

[SaschaSchwarze0]

From today's sync meeting:

#1689 is a pain we need to look at. Something that I have set up at home is the following:

kubectl -n shipwright-build set env deployment/shipwright-build-controller 'IMAGE_PROCESSING_CONTAINER_TEMPLATE={"image": "ghcr.io/shipwright-io/build/image-processing:latest", "command": ["/ko-app/image-processing"], "env": [{"name": "HOME","value": "/shared-home"}], "envFrom": [{"secretRef": {"name": "trivy-user", "optional": true}}], "securityContext": {"allowPrivilegeEscalation": false, "capabilities": {"add": ["DAC_OVERRIDE"], "drop": ["ALL"]}, "runAsUser": 0, "runAsgGroup": 0}}'

The relevant addition is the envFrom pointing to an optional secret trivy-user. That secret is opaque and contains the keys TRIVY_USER (GitHub username) and TRIVY_PASSWORD (GitHub token). That way, the two environment variables are available and it should authenticate for the database download as Trivy supports it based on aquasecurity/trivy#3915 - though those flags are not documented in trivy image --help. Therefore need to check if they are really supported.

Other idea: in the image-processing step implementation, we can try to determine that Trivy failed to download the database based on the command output, and retry the command.

And:

On our Trivy scan issues:

• Environment variables are really existing for the --username and --password flags.
• Next step: try the solution in e2e and integration
• Sascha to open PR with retry of trivy if it fails during database download
  -> we then have two PRs that potentially fix the problem and we can take both or just one
• Matthias: side note, noticed that we use different Ginkgo terms for the vulnerability tests = you must skip two things to skip them all

[SaschaSchwarze0]

The retry is working fine so far. In addition, Trivy has already enabled itself to have multiple database locations referenced since v0.56.0. They're also having the database synchronized to ECR. They still have not yet changed the default to contain both locations. So, for now, one can set TRIVY_DB_REPOSITORY=ghcr.io/aquasecurity/trivy-db:2,public.ecr.aws/aquasecurity/trivy-db:2.

Though, I tend to not do that for the v0.14.0 release.