preloder

Scanning Images on Amazon Elastic Container Registry (ECR)

by | Jan 17, 2018

The Anchore Engine supports analyzing images from any Docker V2 compatible registry however when accessing an Amazon ECR registry extra steps must be taken to handle Amazon Web Services authentication.

The Anchore Engine will attempt to download images from any registry without requiring further configuration. For example running the following command:

$ anchore-cli image add prod.example.com/myapp/foo:latest

Would instruct the Anchore Engine to download the myapp/foo:latest image from the prod.example.com registry. Unless otherwise configured the Anchore Engine will try to pull the image from the registry without authentication.

In the following example we fail to add an image for analysis due to an error.

$ anchore-cli image add prod.example.com/myapp/bar:latest
Error: image cannot be found/fetched from registry
HTTP Code: 404

In many cases it is not possible to distinguish between an image that does not exist and an image that you are not authorized to access since many registries do not wish to disclose the existence of private resources to unauthenticated users.

The Anchore Engine can store credentials used to access your private registries.

Running the following command lists the defined registries.

$ anchore-cli registry list

Registry                                                User            
docker.io                                               anchore
quay.io                                                 anchore
registry.example.com                                    johndoe
123456789012.dkr.ecr.us-east-1.amazonaws.com            ABC

Here we can see that 4 registries have been defined. When pulling an image the Anchore Engine checks to see if any credentials have been defined for the registry, if none are present then the Anchore Engine will attempt to pull images without authentication but if registry is defined then all access of metadata or pulls for images from that registry will use the specified username and password.

Registries can be added using the following syntax:

$ anchore-cli registry add REGISTRY USERNAME PASSWORD

The REGISTRY parameter should include the fully qualified hostname and port number of the registry. For example: registry.anchore.com:5000

Amazon AWS typically uses keys instead of traditional usernames & passwords. These keys consist of an access key ID and a secret access key. While it is possible to use the aws ecr get-login command to create an access token, this will expire after 12 hours so it is not appropriate for use with Anchore Engine, otherwise a user would need to update their registry credentials regularly. So when adding an Amazon ECR registry to Anchore Engine you should pass the aws_access_key_id and aws_secret_access_key.

For example:

$ anchore-cli registry add /
             1234567890.dkr.ecr.us-east-1.amazonaws.com /
             MY_AWS_ACCESS_KEY_ID /
             MY_AWS_SECRET_ACCESS_KEY /
             --registry-type=awsecr

The registry-type parameter instructs Anchore Engine to handle these credentials as AWS credentials rather than traditional usernames and passwords. Currently the Anchore Engine supports two types of registry authentication standard username and password for most Docker V2 registries and Amazon ECR. In this example we specified the registry type on the command line however if this parameter is omitted then the CLI will attempt to guess the registry type from the URL which uses a standard format.

The Anchore Engine will use the AWS access key and secret access keys to generate authentication tokens to access the Amazon ECR registry, the Anchore Engine will manage regeneration of these tokens which typically expire after 12 hours.

In addition to supporting AWS access key credentials Anchore also supports the use of IAM roles for authenticating with Amazon ECR if the Anchore Engine is run on an EC2 instance.

In this case you can configure the Anchore Engine to inherit the IAM role from the EC2 insance hosting the engine.

When launching the EC2 instance that will run the Anchore Engine you need to specify a role that includes the AmazonEC2ContainerRegistryReadOnly policy.

While this is best performed using a CloudFormation template, you can manually configure from the launch instance wizard.

Select Create new IAM role.

Under type of trusted entity select EC2.

Ensure that the AmazonEC2ContainerRegistryReadOnly policy is selected.

Give a name to the role and add this role to the Instance you are launching.

On the running EC2 instance you can manually verify that the instance has inherited the correct role by running the following command:

#curl http://169.254.169.254/latest/meta-data/iam/info
{
 "Code" : "Success",
 "LastUpdated" : "2018-01-1218:45:12Z",
 "InstanceProfileArn" : "arn:aws:iam::123456789012:instance-profile/ECR-ReadOnly",
 "InstanceProfileId" : "ABCDEFGHIJKLMNOP”
}

By default the support for inheriting the IAM role is disabled. This can be enabled by adding the following entry to the top of the Anchore Engine config.yaml file.

allow_awsecr_iam_auto: False

When IAM support is enabled instead of passing the access key and secret access key use “awsauto” for both username and password. This will instruct the Anchore Engine to inherit the role from the underlying EC2 instance.

$ anchore-cli registry add /
               1234567890.dkr.ecr.us-east-1.amazonaws.com /
               awsauto /
               awsauto /
               --registry-type=awsecr

You can learn more about Anchore Engine and how you can scan your container images whether they are hosted on cloud based registries such as DockerHub and Amazon ECR or on private Docker V2 compatible registries hosted on-premises.

Learn More About Anchore Engine