[ECR] [request]: ECR granular permissions (IAM condition/policy to include individual images/tags)

[ajohnstone]

Tell us about your request
ECR permissions are not granular enough and do not allow you to prevent pulls of an individual image/tag.

In a nutshell, I want to prevent an image from being pulled by my production account until it's passed some sort of test/quality gate in a pre-production environment.

Relates to:

• [ECR] [Tags]: immutable image tags #169
• [ECR] [request]: Cross Region Replication for Repositories #140
• ECR Image vulnerability scanning #17

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?

Current use cases:
Use case 1: image-scanning has not been run, prior to utilising an image as such would like to use tags/labels to prevent pulls until an image has been marked as scanned.

Use case 2: an image has been found to be vulnerable and to prevent future pulls of the image. The image should be retained and not deleted for auditing purposes and for specific IAM policies/conditions to allow the image to be pulled in an isolated environment.

Use case 3: Apply tags at the image (not repository), that marks the image is/ is not allowed to be pulled. Tags at the image level should be able to be made immutable.

Use case 4: Support more than one scanning tool, I.e. FOSS scanning, vulnerability scans etc. We have more than one form of scan. I.e. allow IAM and conditions to prevent pulls with custom tags/labels.

Currently it is not possible to put preventative measures to pull images other than at an entire repository level or to delete an image. As such the request for granular permissions.

Are you currently working around this issue?
Looking to use more than one account as scanned and unscanned and replicate images once scanning has occurred.

[jtoberon]

Hi @ajohnstone, thanks for the request! This is a common request that I understand to mean: it should be easier to build a workflow on top of ECR and have ECR enforce that workflow. I'd add another common use case to the examples that you already provided: I want to prevent an image from being pulled by my production account until it's passed some sort of test/quality gate in a pre-production environment.

A common workaround involves copying an image to a "production" repository once it's ready. However, this is a pain to set up, and it's hard to maintain an audit trail of what happened.

We're starting to think about this, but I don't have a specific proposal to share yet.

[ajohnstone]

Thanks @jtoberon, I've updated the description to be a litter clearer.

[leofernandezg]

+1
I have the same issue, but pusing images.
We need IAM Permissions at image-level.

My example:

1. We have a "hello-world-application" ECR Private Repository with that name.

2. We created a different docker image tag for each environment: "hello-world-application:prod", "hello-world-application:dev".

3. Each environment, pulls the last ECR Image with the tag associated to their environment (Dev Environment pulls hello-world-application:dev, Prod Environment pulls hello-world-application:prod, etc).

4. We have a CI/CD listening different Github Protected Branches, and each one deploys the image for their tag.

5. Depending on the name of the Github Protected Branches, the CI/CD will instantiate a different IAM Role that should be able to deploy just their tag (Dev shouldn't be able to deploy Prod, and vice-versa).

I know that this can be "solved" using different repositories for each environments, but this is not a best practice in "Docker world", (You can see standard images in DockerHub, for instance). You should have a repository for each application, and different tags are different versions, with their CI/CD systems attached.

[sreedharbukya]

I am also having similar situation now, where I would like to give permissions to my external vendor to pull only tagged images with certain pattern, but not allowing them to download any images from the repository.

[thenoid]

I have the same issue, but pushing images.

☝️

[JunaidChaudry]

+1

[cmorinupgrade]

+1

[one-summers-day]

Please please please.. it's agonizing to realize you've overwritten a prod image from an experimental branch merge or to realize that you've overwritten a dev image from a prod branch merge only after ECS task definitions dependent on those images start flashing red lights. Happened to me 2 times already 😢 🙏🏻

[nategoethel]

Would love to get this prioritized.

[ojaswa1942]

+1. We use tags for different environments and versions, however not being able to control tag-level permissions raises a security red-flag where each environment can read / write others' tags.