Cannot connect to Azure Container Registry about trivy HOT 6 CLOSED

Almost as a reminder to myself... but running Trivy via docker on an image hosted by Azure's ACS looks like this -

repo="foo.azurecr.io" image="foo/bar:0.0.1" docker run --rm -v $HOME/.docker/config.json:/root/.docker/config.json -v $HOME/Library/Caches:/root/.cache/ aquasec/trivy --severity HIGH,CRITICAL "$repo/$image"

You almost say that above, but it'd be nice to have a simple working example for that stupid cloud (not blaming you :))

(slight edit to put in newline between commands :(

from trivy.

This issue is stale because it has been labeled with inactivity.

from trivy.

We scan ACR images on daily basis with no issues. I think the exception complains about your image name.
Could you try to specify it without https, like trivy agrdev.azurecr.io/accumulo-1.9.2:12?

from trivy.

hi @v1r7u - Thank you for your comment. I just tried to run a scan using the format you suggested and got a new error now;
C:\Users\SMcEnery>trivy agrdev.azurecr.io/accumulo-1.9.2:25
2019-07-27T21:16:33.912-0400 �[34mINFO�[0m Updating vulnerability database...
2019-07-27T21:16:36.204-0400 �[31mFATAL�[0m error in image scan: failed to analyze image: failed to extract files: error unmarshalling content: unexpected end of JSON input

if you are able to run scans of ACR Images, do you have any environment variables set? How do you have it working?

from trivy.

Try to update docker server version. We had similar problem with older one, but it works fine with 18.09.7
Also, trivy is not capable to scan some images, take a look on #96

How our process looks like

1. We built an own trivy docker image from sources and pushed it to our ACR registry.
2. In CI pipeline, we run trivy from docker container using the following command docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v $HOME/Library/Caches:/root/.cache/ ouracrname.azurecr.io/security/trivy:c29f6f5 --exit-code 1 --severity CRITICAL --quiet --auto-refresh $IMAGE.

Note, we're mapping 2 volumes: one with docker socket, another with cache folder.

With properly mapped docker.sock, if image is already in local docker cache, trivy does not need any environment variables with credentials. If image is not on machine, trivy would try to pull it using credentials in env.vars.
Another caveat with pull process (to be honest, it was with older version of trivy, no idea if it still the case with the latest one):

• if you want to scan public image - do not specify creds in env-vars;
• if you want to scan private registry - specify env-vars.

off-top

The problem with trivy - it's quite fragile. There is 100 and 1 ways of running it in a wrong way... The worst part, exceptions often are not self-explaining :)
From the other hand, you're getting a free scanner (not like https://snyk.io/, for example), which does not require maintaining several infrastructure components (not like https://github.com/coreos/clair/), which does not require dockerfile modifications (not like https://github.com/aquasecurity/microscanner), and it's open-sourced.
So, pros and cons as usual :D

from trivy.

@divgo do you still have problems? Trivy actually dont have support for windows OS.

from trivy.