Skip to main content

AWS ECR scanner reference

You can scan your container images using Amazon Elastic Container Registry (ECR).

Before you begin​

Docker-in-Docker requirements​

note

Docker-in-Docker is not required for ingestion workflows where the scan data has already been generated.

You need to include a Docker-in-Docker background service in your stage if either of these conditions apply:

  • You configured your scanner using a generic Security step rather than a scanner-specific template such as Aqua Trivy, Bandit, Mend, Snyk, etc.
  • You’re scanning a container image using an Orchestration or Extraction workflow.
Set up a Docker-in-Docker background step

  1. Go to the stage where you want to run the scan.

  2. In Overview, add the shared path /var/run.

  3. In Execution, do the following:

    1. Click Add Step and then choose Background.
    2. Configure the Background step as follows:
      1. Dependency Name = dind
      2. Container Registry = The Docker connector to download the DinD image. If you don't have one defined, go to Docker connector settings reference.
      3. Image = docker:dind
      4. Under Optional Configuration, select the Privileged checkbox.
Configure the background step

Root access requirements​

You need to run the scan step with root access if either of the following apply:

  • You need to run a Docker-in-Docker background service.

  • You need to add trusted certificates to your scan images at runtime.

note

You can set up your STO scan images and pipelines to run scans as non-root and establish trust for your own proxies using self-signed certificates. For more information, go to Configure STO to Download Images from a Private Registry.

AWS ECR step configuration​

The recommended workflow is add an AWS ECR step to a Security Tests or CI Build stage and then configure it as described below. You can also configure scans programmatically by copying, pasting, and editing the YAML definition.

note
  • UI configuration support is currently limited to a subset of scanners. Extending UI support to additional scanners is on the Harness engineering roadmap.
  • Each scanner template shows only the options that apply to a specific scan. If you're setting up a repository scan, for example, the UI won't show Container Image settings.
  • Docker-in-Docker is not required for these steps unless you're scanning a container image. If you're scanning a repository using Bandit, for example, you don't need to set up a Background step running DinD.
  • Support is currently limited to Kubernetes and Harness Cloud AMD64 build infrastructures only.

Scan settings​

Scan Mode​

  • Extraction A partially-orchestrated scan. The Security step pulls scan results from an external SaaS service and then normalizes and compresses the data.

Scan Configuration​

The predefined configuration to use for the scan. All scan steps have at least one configuration.

Target Settings​

Type​

  • Container Image Scan the layers, libraries, and packages in a container image.

Name​

The Identifier that you want to assign to the target you’re scanning in the pipeline. Use a unique, descriptive name such as codebaseAlpha or jsmith/myalphaservice. Using descriptive target names will make it much easier to navigate your scan data in the STO UI.

Variant​

An identifier for a specific variant to scan, such as the branch name or image tag. This identifier is used to differentiate or group results for a target. Harness maintains a historical trend for each variant.

You can see the target name, type, and variant in the Test Targets UI:

Target name, type, and branch

Container Image settings​

Type (orchestration)​

The registry type where the image is stored:

Domain (extraction)​

The URL of the artifact repository that contains the image to scan. Examples:

  • docker.io
  • app.harness.io/registry
  • us-east1-docker.pkg.dev
  • us.gcr.io

Name​

The image name. For non-local images, you also need to specify the image repository. Example: jsmith/myalphaservice

Tag​

The image tag. Examples: latest, 1.2.3

Region​

The region where the image to scan is located, as defined by the cloud provider such as AWS.

Authentication settings​

Access ID (orchestration)​

Username to log in to the scanner.

Access Token​

The access token to log in to the scanner. In most cases this is a password or an API key.

You should create a Harness text secret with your encrypted token and reference the secret using the format <+secrets.getValue("project.container-access-id")>. For more information, go to Add and Reference Text Secrets.

Access Region​

The AWS region of the image to scan.

Ingestion settings​

Ingestion File​

The results data file to use when running an Ingestion scan. STO steps can ingest scan data in SARIF and Harness Custom JSON format. Generally an Ingestion scan consists of a scan step (to generate the data file) and an ingestion step (to ingest the data file).

Log Level, CLI flags, and Fail on Severity​

Log Level​

The minimum severity of the messages you want to include in your scan logs. You can specify one of the following:

  • DEBUG
  • INFO
  • WARNING
  • ERROR

Fail on Severity​

Every Security step has a Fail on Severity setting. If the scan finds any vulnerability with the specified severity level or higher, the pipeline fails automatically. You can specify one of the following:

  • CRITICAL
  • HIGH
  • MEDIUM
  • LOW
  • INFO
  • NONE — Do not fail on severity

The YAML definition looks like this: fail_on_severity : critical # | high | medium | low | info | none

Additional Configuration​

In the Additional Configuration settings, you can use the following options:

Advanced settings​

In the Advanced settings, you can use the following options: