Anchore Engine Inline Image Analysis/Engine Import

Introduction

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.

  • Note - For the rest of this document, USER, PASS, and URL refer 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-v0.6.0 | bash -s -- analyze -u <USER> -p <PASS> -r <URL> [ OPTIONS ] <FULL_IMAGE_TAG>

Inline Analysis Options

-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

Image Identity Selection

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.

Analyzing a local image

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-v0.6.0 | 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-v0.6.0 | 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
...

Analyzing an image from a registry

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-v0.6.0 | 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

Last modified December 12, 2019: Btodhunter/2.2 dev (#85) (4fccec4)