AWS AmazonECR documentation change
Summary
Expanded lifecycle policy documentation to include archival functionality, new countType options (sinceImagePulled, sinceImageTransitioned), and updated rule constraints related to storage classes and image transitions.
Security assessment
The changes introduce archival capabilities and additional criteria for image lifecycle management, but there is no evidence of addressing a specific security vulnerability. The updates enhance operational controls for image retention/archival rather than patching security flaws. While better lifecycle management can indirectly improve security hygiene, the changes themselves describe feature enhancements rather than security fixes.
Diff
diff --git a/AmazonECR/latest/userguide/LifecyclePolicies.md b/AmazonECR/latest/userguide/LifecyclePolicies.md index dace5c713..66aa6a814 100644 --- a//AmazonECR/latest/userguide/LifecyclePolicies.md +++ b//AmazonECR/latest/userguide/LifecyclePolicies.md @@ -9 +9 @@ How lifecycle policies work -Amazon ECR lifecycle policies provide more control over the lifecycle management of images in a private repository. A lifecycle policy contains one or more rules, and each rule defines an action for Amazon ECR. Based on the expiration criteria in the lifecycle policy, images expire based on age or count within 24 hours. When Amazon ECR performs an action based on a lifecycle policy, this action is captured as an event in AWS CloudTrail. For more information, see [Logging Amazon ECR actions with AWS CloudTrail](./logging-using-cloudtrail.html). +Amazon ECR lifecycle policies provide more control over the lifecycle management of images in a private repository. A lifecycle policy contains one or more rules, and each rule defines an action for Amazon ECR. Based on the expiration criteria in the lifecycle policy, images can be archived or expired based on the criteria specified in the lifecycle policy within 24 hours. When Amazon ECR performs an action based on a lifecycle policy, this action is captured as an event in AWS CloudTrail. For more information, see [Logging Amazon ECR actions with AWS CloudTrail](./logging-using-cloudtrail.html). @@ -25 +25 @@ The following diagram shows the lifecycle policy workflow. - 4. The lifecycle policy evaluator then applies the rules, based on rule priority, and displays which images in the repository are set to be expired. A lower rule priority number means higher priority. For example, a rule with priority 1 takes precedence over a rule with priority 2. + 4. The lifecycle policy evaluator then applies the rules, based on rule priority, and displays which images in the repository are set to be expired or archived. A lower rule priority number means higher priority. For example, a rule with priority 1 takes precedence over a rule with priority 2. @@ -27 +27 @@ The following diagram shows the lifecycle policy workflow. - 5. Review the results of the test, ensuring that the images that are marked to be expired are what you intended. + 5. Review the results of the test, ensuring that the images that are marked to be expired or archived are what you intended. @@ -31 +31 @@ The following diagram shows the lifecycle policy workflow. - 7. Once the lifecycle policy is created, you should expect that images become expired within 24 hours after they meet the expiration criteria. + 7. Once the lifecycle policy is created, you should expect that images are expired or archived within 24 hours after they meet the expiration criteria. @@ -40 +40 @@ The lifecycle policy evaluator is responsible for parsing the plaintext JSON of - * When reference artifacts are present in a repository, Amazon ECR lifecycle policies automatically clean up those artifacts within 24 hours of the deletion of the subject image. + * When reference artifacts are present in a repository, Amazon ECR lifecycle policies automatically expire or archive those artifacts within 24 hours of the deletion or archival of the subject image. @@ -44 +44 @@ The lifecycle policy evaluator is responsible for parsing the plaintext JSON of - * An image is expired by exactly one or zero rules. + * An image is expired or archived by exactly one or zero rules. @@ -46 +46 @@ The lifecycle policy evaluator is responsible for parsing the plaintext JSON of - * An image that matches the tagging requirements of a rule cannot be expired by a rule with a lower priority. + * An image that matches the tagging requirements of a rule cannot be expired or archived by a rule with a lower priority. @@ -48 +48 @@ The lifecycle policy evaluator is responsible for parsing the plaintext JSON of - * Rules can never mark images that are marked by higher priority rules, but can still identify them as if they haven't been expired. + * Rules can never mark images that are marked by higher priority rules, but can still identify them as if they haven't been expired or archived. @@ -50 +50 @@ The lifecycle policy evaluator is responsible for parsing the plaintext JSON of - * The set of rules must contain a unique set of tag prefixes. + * The set of all rules selecting a specific storage class must contain a unique set of prefixes. @@ -52 +52 @@ The lifecycle policy evaluator is responsible for parsing the plaintext JSON of - * Only one rule is allowed to select untagged images. + * Only one rule selecting a specific storage class is allowed to select untagged images. @@ -54 +54 @@ The lifecycle policy evaluator is responsible for parsing the plaintext JSON of - * If an image is referenced by a manifest list, it cannot be expired without the manifest list being deleted first. + * If an image is referenced by a manifest list, it cannot be expired or archived without the manifest list being deleted or archived first. @@ -56 +56 @@ The lifecycle policy evaluator is responsible for parsing the plaintext JSON of - * Expiration is always ordered by `pushed_at_time`, and always expires older images before newer ones. + * Expiration is always ordered by `pushed_at_time` or `transitioned_at_time` and always expires older images before newer ones. If an image was archived and then restored at any point in the past, the image's `last_activated_at` is used instead of `pushed_at_time`. @@ -70 +70 @@ There is a maximum limit of four wildcards (`*`) per string. For example, `["*te - * The `countUnit` parameter is only used if `countType` is `sinceImagePushed`. + * The `countUnit` parameter is only used if `countType` is `sinceImagePushed`, `sinceImagePulled`, or `sinceImageTransitioned`. @@ -72 +72 @@ There is a maximum limit of four wildcards (`*`) per string. For example, `["*te - * With `countType = imageCountMoreThan`, images are sorted from youngest to oldest based on `pushed_at_time` and then all images greater than the specified count are expired. + * With `countType = imageCountMoreThan`, images are sorted from youngest to oldest based on `pushed_at_time` and then all images greater than the specified count are expired or archived. @@ -74 +74,7 @@ There is a maximum limit of four wildcards (`*`) per string. For example, `["*te - * With `countType = sinceImagePushed`, all images whose `pushed_at_time` is older than the specified number of days based on `countNumber` are expired. + * With `countType = sinceImagePushed`, all images whose `pushed_at_time` is older than the specified number of days based on `countNumber` are expired or archived. + + * With `countType = sinceImagePulled`, all images whose `last_recorded_pulltime` is older than the specified number of days based on `countNumber` are archived. If an image was never pulled, the image's `pushed_at_time` is used instead of the `last_recorded_pulltime`. If an image was archived and then restored at any point in the past, but never pulled since the image was restored, the image's `last_activated_at` is used instead of the `last_recorded_pulltime`. + + * With `countType = sinceImageTransitioned`, all archived images whose `last_archived_at` is older than the specified number of days based on `countNumber` are expired. + + * Expiration is always ordered by `pushed_at_time` and always expires older images before newer ones.