Containers-roadmap: [ECR] [Tags]: Exceptions to Tag Immutability (e.g. latest)

Created on 6 May 2020  路  3Comments  路  Source: aws/containers-roadmap

Community Note

  • Please vote on this issue by adding a 馃憤 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Tell us about your request

Add the ability to specify a whitelist (or regex/pattern) of tags to specifically exclude from the tag immutability feature introduced in #169.

Which service(s) is this request for?
ECR

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?

Tag immutability has a lot of benefits for reliability, security, and compliance; however, it breaks certain workflows. For example, the common use of the latest tag.

Although using latest in production is an anti-pattern, there are multiple valid uses such as to use it in CI/CD builds as a Docker cache, or for dev/test workflows such as local development.

Ideally it would be possible to get the benefits of tag immutability in production without needing to sacrifice the flexibility of having some tags remain mutable.

Are you currently working around this issue?

As far as I know there is not a satisfactory workaround to this issue. One solution might be to maintain two registries (one with immutability, one without), but that would double storage costs and other overhead.

Another possibility discussed in #169 is to programmatically untag prior to pushing a new tag, but that would introduce a race condition whereby the tag is not available between untagging and pushing. If latest is being used in builds, for example, this would be a problem.

Additional context

There is some further discussion in #169.

ECR Proposed

Most helpful comment

This would be handy. Right now we disable immutability if any tag at all might need to be updated.

While we dropped all use of latest we do often use 'series versions', which is a common pattern for shared or public images. So will each build has a unique tag

  • 1.2.10
  • 1.2.11
  • 1.2.12
  • ...

The newest version of 1.2.x is also tagged 1.2. This gives the consumer the options to always pull/check 1.2. or to lock to 1.2.11 and cache that image.

So if we could set a multiple mask regex of \d+\.\d+, we could support this use case.

All 3 comments

This would be handy. Right now we disable immutability if any tag at all might need to be updated.

While we dropped all use of latest we do often use 'series versions', which is a common pattern for shared or public images. So will each build has a unique tag

  • 1.2.10
  • 1.2.11
  • 1.2.12
  • ...

The newest version of 1.2.x is also tagged 1.2. This gives the consumer the options to always pull/check 1.2. or to lock to 1.2.11 and cache that image.

So if we could set a multiple mask regex of \d+\.\d+, we could support this use case.

This would be amazing for us, especially for use cases beyond latest.

For example, our CI/CD system tags our images in a predefined manner and we'd like only those tags to be strictly immutable, while allowing users to add/mutate any other tags they'd like.

As others have said, the ability to retag on some versions and no on others would be amazing. It would also be amazing to be able to set the number of tags required when creating a new image. Using the example above where there is 1.2 which would be tagged on 1.2.x we would want to require a minimum of 2 tags. Other examples such as official language images also include base image and base version so they would set something close to 7 tags on every new image with only the most specific of versions being restricted. But then you could say that having a regex map would allow for a mix of rigidity and flexibility.

Was this page helpful?
0 / 5 - 0 ratings