In the last blog post, we discussed about Amazon’s docker container image repository service, Elastic Container Registry (ECR). We learned how to create ECR, push and pull images and other basic operations. In this blog post, we’ll discuss about advanced features such as scan on push, lifecycle policies, etc. We’ll learn what these features are about, and how to turn them on or off.
Image tag Mutability
You can configure a repository to be immutable to prevent image tags from being overwritten. After the repository is configured for immutable tags, an
ImageTagAlreadyExistsException error is returned, if you attempt to push an image with a tag that is already in the repository.
This feature can be turned on or off for existing repositories. Alternatively, you can turn this feature on at the time of creating ECR, by using the
aws ecr create-repository --repository-name mgoyal-demo-dev --image-tag-mutability IMMUTABLE --region ap-south-1
To turn this feature on/off for existing images, use the
aws ecr put-image-tag-mutability --repository-name mgoyal-demo-dev --image-tag-mutability IMMUTABLE
Note that this is also true for the
latest tag as well. If you are trying to push an image with
latest tag again, you’ll get below error:
tag invalid: The image tag 'latest' already exists in the 'mgoyal-demo-dev' repository and cannot be overwritten because the repository is immutable.
Scan Images for security vulnerabilities
Amazon ECR image scanning helps in identifying software vulnerabilities in the container images. Amazon ECR uses the Common Vulnerabilities and Exposures (CVEs) database from the open-source Clair project and provides a list of scan findings. You can manually scan container images stored in Amazon ECR. Alternatively, you can configure your repositories to scan images when you push them to a repository. The last completed image scan findings can be retrieved for each image.
You can create an image with scan on push feature enabled by using
aws ecr create-repository --repository-name mgoyal-demo-dev --image-scanning-configuration scanOnPush=true --region ap-south-1
Alternatively, you can enable it for existing repository using
aws ecr put-image-scanning-configuration --repository-name mgoyal-demo-dev --image-scanning-configuration scanOnPush=true
You can also initiate manual scan option by using
aws ecr start-image-scan --repository-name mgoyal-demo-dev --image-id imageTag=latest
Once the scan is complete, you can retrieve image scan findings either from portal or at command line using the
describe-image-scan-findings option. Since number of issues found can be too many to read on command line, most of the time you will be reviewing it from AWS portal itself:
To have more resiliency for your infrastructure, you can choose to replicate container images either into different regions or across accounts as well. This setting is enabled at the registry level which is further controlled at region level.
As the name indicates, the cross-region replication makes copies of the repositories in more or more destination regions. And the cross-account replication makes copies of the repositories in the destination account and regions specified.
Do note that repository settings and lifecycle policies are not replicated.
AWS ECR lifecycle policies allow developers and administrators to manage container images using specific rules that automatically help with the tasks such as deleting unused images, manage active number of images. This can be based on a certain criteria like image age, size, count etc.
Creating Lifecycle Policy Preview
A lifecycle policy preview allows us to see the impact of a policy, thus preventing us from doing unintentional mistakes. To create a lifecycle policy in preview mode, open AWS portal, go to services -> ECR -> Select Repository -> Lifecycle Policy -> Edit test rules -> Create Rule:
In the page opened next, you can see that AWS offers many options to control images. It also offers a Rule priority option in case you have multiple rules. The higher priority rule will take precedence, over lower priority rules with 1 being assigned the highest priority.
You can also apply the rules to images with the following status: Tagged, Untagged, Any
Note that if you choose to apply multiple lifecycle policies to an ECR, there can be only one lifecycle policy with container images tagged as any. If you specified tagged for image status, then for tag prefixes, you can optionally specify a list of image tags on which to take action with your lifecycle policy. If you specified
Untagged, this field must be empty:
In the Match criteria section, you can decide when to delete an image based on specific criteria you define. Currently, ECR offers two options. The first option is Since image pushed X Days, which means that once X number of days have passed, the image will be deleted. The second criteria is Image counter more than X, which means that if the repository has more than X images, the excess images are to be deleted:
Review and once satisfied, select Save. You can repeat above steps to create as many rules as you need.
Testing Lifecycle Policies
To run the lifecycle policy preview, choose Save and run test. Under Image matches for test lifecycle rules, review the impact of your lifecycle policy preview by choosing choose Save and run test:
Applying the Lifecycle Policy
Under Image matches for test lifecycle rules, review the impact of your lifecycle policy preview. If you are satisfied with the preview results, choose Apply as lifecycle policy to create a lifecycle policy with the specified rules.
View Results of Applying Policy
After you click Apply, the policy goes into effect. You should expect that after creating a lifecycle policy, the affected images are expired within 24 hours.
Do note that once a lifecycle policy deletes an image, the image cannot be recovered.
Tagging an existing ECR
Tagging is another important ECR feature that allows you to manage your repositories by assigning metadata to every repository in the form of a tag. A tag is a label that contains two types of information, a name and a value both of which you can define. Tags enable you to categorize your AWS resources in different ways, for example, by purpose, owner, or environment. This is useful when you have many resources of the same type , allowing you to quickly identify a specific resource based on the tags assigned.
Once applied to a repository, tags allows you to define ownership for billing purposes or just for reporting or for other purposes like lifecycle policies.
Tag an existing Repository
We can use
tag-resource sub-command to tag an repository:
aws ecr tag-resource --resource-arn arn:aws:ecr:ap-south-1:123412341234:repository/mgoyal-demo-dev --tags Key=stack,Value=dev
Specify Multiple Tags for existing Repo
We can also specify multiple tags like below:
aws ecr tag-resource --resource-arn arn:aws:ecr:ap-south-1:123412341234:repository/mgoyal-demo-dev --tags Key=environment,Value=demo Key=key2,Value=value2 Key=key3,Value=value3
List tags already allocated
We can list tags for an ECR as below:
aws ecr list-tags-for-resource --resource-arn arn:aws:ecr:ap-south-1:123412341234:repository/mgoyal-demo-dev
Remove tags from Repo
We can remove tag using
aws ecr untag-resource --resource-arn arn:aws:ecr:ap-south-1:123412341234:repository/mgoyal-demo-dev --tag-keys Key2
As you can see, we have discussed quite a few features for ECR. In the next few posts, we’ll discuss features such as sccurity, billing etc. and be more familiar with real-world considerations and implications.