For use cases where it is desirable to perform image analysis for a locally build container image, and import the image analysis to an existing Anchore Engine installation, we support a methodology using the inline_scan tool. With this technique, you can ‘add’ an image to your anchore engine service by analyzing any image that is available locally (say, on the docker host on which the image was built). You can then import the analysis data into anchore engine, rather than the regular method where images are pulled from a registry when added to anchore engine.
The only requirements to run the inline_scan script with the ‘analyze’ operation is the ability to execute Docker commands, network connectivity to an anchore engine API endpoint & bash. We host a versioned copy of this script that can be downloaded directly with curl and executed in a bash pipeline.
URLrefer to an anchore engine user, password, and engine endpoint URL (http://:/v1) respectively.
To run the script on your workstation, use the following command syntax.
curl -s https://ci-tools.anchore.io/inline_scan-latest | bash -s -- analyze -u <USER> -p <PASS> -r <URL> [ OPTIONS ] <FULL_IMAGE_TAG>
-r <TEXT> [required] URL to remote Anchore Engine API endpoint (ex: -r 'https://anchore.example.com:8228/v1') -u <TEXT> [required] Username for remote Anchore Engine auth (ex: -u 'admin') -p <TEXT> [required] Password for remote Anchore Engine auth (ex: -p 'foobar') -a <TEXT> [optional] Add annotations (ex: -a 'key=value,key=value') -d <PATH> [optional] Specify image digest (ex: -d 'sha256:<64 hex characters>') -f <PATH> [optional] Path to Dockerfile (ex: -f ./Dockerfile) -i <TEXT> [optional] Specify image ID used within Anchore Engine (ex: -i '<64 hex characters>') -m <PATH> [optional] Path to Docker image manifest (ex: -m ./manifest.json) -t <TEXT> [optional] Specify timeout for image analysis in seconds. Defaults to 300s. (ex: -t 500) -g [optional] Generate an image digest from docker save tarball -P [optional] Pull docker image from registry -V [optional] Increase verbosity
In order to perform local analysis and import the image correctly into your existing anchore engine deployment, special attention should be paid to the image identifiers (image id, digest, manifest, full tag name) when performing local analysis. Since image digests are generated from an image ‘manifest’ which is generated by a container registry, this technique requires that you either specify a digest, ask for one to be randomly ‘generated’, or supply a valid manifest alongside the image when it is being imported. An image ID can also be supplied if one is available that you would prefer to use. Best practice is to supply these identifiers in whichever way is most appropriate for your use case, resulting in the information being associated with the imported image correctly such that you can refer to it later using these identifiers.
For a simple example, we show here how to perform a local docker build, then analyze the image (specifying the Dockerfile) and upload the analysis results to a remote anchore engine installation. The end result is that the image is ‘added’ to the specified anchore engine service as if it were ‘added’ using the regular
anchore-cli image add process.
Note that in this scenario, the image has never been pushed to any container image registry, meaning that this technique is an alternate path for ensuring that images are added to anchore engine for later vulnerability scanning, policy evaluations, and any other functionality of anchore engine that can be performed against analyzed images.
# docker build -t localbuild/example-image:latest -f Dockerfile . # curl -s https://ci-tools.anchore.io/inline_scan-latest | bash -s -- analyze -u <USER> -p <PASS> -r <URL> -f ./Dockerfile -g localbuild/example-image:latest
Alternatively, we can specify a digest and image ID, instead of asking the analyzer to generate one randomly:
# docker build -t localbuild/example-image:latest -f Dockerfile . # docker images localbuild/example-image:latest --digests --no-trunc ...get the full image ID of the image, in this case 363f10f9... ...get the image digest from the local image if available, in this case sha256:d212a12aa.... # curl -s https://ci-tools.anchore.io/inline_scan-latest | bash -s -- analyze -u <USER> -p <PASS> -r <URL> -f ./Dockerfile -i 363f10f920d05943659ffa0b9ac9a98582bd71841b58c0a50fd596d6285404b2 -d sha256:d212a12aa728ccb4baf06fcc83dc77392d90018d13c9b40717cf455e09aeeef3 localbuild/example-image:latest # anchore-cli image get localbuild/example-image:latest Image Digest: sha256:d212a12aa728ccb4baf06fcc83dc77392d90018d13c9b40717cf455e09aeeef3 ...
Here we show an example of an image (docker.io/alpine:latest) that is available in a registry (thus the manifest is accessible). We get the manifest from the registry, using skopeo, by first getting the parent digest - which will be used to get the digest of the image that matches your desired architecture- then getting the actual image digest. Finally, we perform analysis/import using the inline_scan tool.
# skopeo inspect --raw docker://docker.io/alpine:latest > alpine_parent_digest.json # cat ./alpine_parent_digest.json ...find and note the digest for the image with the architecture we want (sha256:acd3... in this example) # skopeo inspect --raw docker://docker.io/[email protected]:acd3ca9941a85e8ed16515bfc5328e4e2f8c128caa72959a58a127b7801ee01f > alpine_manifest.json # curl -s https://ci-tools.anchore.io/inline_scan-latest | bash -s -- analyze -u <USER> -p <PASS> -r <URL> -P -m ./alpine_manifest.json docker.io/alpine:latest # anchore-cli image get docker.io/alpine:latest Image Digest: sha256:acd3ca9941a85e8ed16515bfc5328e4e2f8c128caa72959a58a127b7801ee01f