Docker image analysis

Using the Buildah engine

A Linux distribution with a Kernel greater than or equal to 5.11 is required to use the Buildah engine. For more information, see Technical requirements to the Cyberwatch installation.

On instances that support it, Cyberwatch configures by default the Buildah Docker engine, whose name refers to the technology it uses. Unlike an external Docker daemon, this engine runs inside the Cyberwatch instance and does not require any extra configuration.

To recreate manually the Buildah engine, go to the Stored credentials menu and add a new Docker engine with URL buildah:// and without certificates.

In the case of intensive use of Docker scans, or if the scanned images may possibly contain malicious code, it might be preferable to favor an external Docker engine in order to split the load and to reinforce the isolation of the execution.

Configuring a external Docker engine

First of all, you need to prepare a dockerd instance accepting external connections. For security reasons, it is essential to authenticate incoming connections through TLS, as described in the official Docker documentation: https://docs.docker.com/engine/security/https/.

Cyberwatch provides documentation and scripts to generate the required certificates to configure TLS for your Docker engine: https://github.com/Cyberwatch/docker-scanner.

Please follow the given documentation on GitHub to configure your Docker engine.

The Cyberwatch support team may also assist you in this configuration if needed.

Once the Docker engine is ready with TLS, you should have the following elements:

  • The certificate of your Certificate Authority
  • The client certificate signed by your Certificate Authority
  • The private key associated to your client certificate

Finally, go to Stored credentials, from which you may add credentials of type Docker engine. The expected URL looks like tcp://…:2376, and the expected certificates are the ones described above.

Configuring Docker registries

From Stored credentials, you may add credentials of type Docker registry. For testing purposes, the Docker Hub public registry should be configured by default.

If your registry uses a self-signed certificate, you will need to either disable certificate verification, or have it signed by a trusted Certificate Authority. Please note that the Docker engine will likely require a similar configuration, as described at https://docs.docker.com/registry/insecure/.

Private Amazon ECR registries require an access to the AWS API for authenticating. The procedure for creating an API key and adding it to Cyberwatch using stored credentials is the same as described for AWS discoveries. The API key must allow creating temporary passwords for logging in to the registry. Then, to make the AWS key selector appear in the Docker registry addition form, the URL of the registry must end with .amazonaws.com.

Google Artifact Registry requires a service account JSON key for authentication. See https://cloud.google.com/artifact-registry/docs/docker/authentication?hl=en#json-key for details. You first need to register that key as a stored credential of type Google Cloud Platform. Then, when adding the Docker Registry stored credential, you will be able to select your key as soon as you enter a URL ending with -docker.pkg.dev.

Adding a Docker image

Docker images are managed from Assets management > Docker images.

To add a Docker image:

  1. Go to Docker images
  2. Click Add on the top right corner

  3. Fill in the form:

    • Image refers to the name of the Docker image in the “namespace/name” format. When using an official image from the Docker Hub registry, please explicitly specify the library namespace
    • Tag refers to the version of the image
    • Registry refers to the Docker registry to pull the image from
    • Engine refers to the Docker engine to run the container and the analyses on
    • Source refers to the Cyberwatch node that should send the commands to the Docker engine
  4. Click Confirm

When adding an image, an analysis task is spawned in the background, leading on success to the creation of an asset in the Vulnerabilities inventory. The associated asset, or a potential error message, will be displayed on the image index at Docker images when the task completes.

Table of contents

Back to top