aws / aws/containers-roadmap

[ECR] [request]: Add signingRoleArn support to pull-through cache rules

Open
#2,830 0 comments 1 reaction 0 assignees View on GitHub
ECR Proposed
Dominant language
Shell
Stars
5.4k
Forks
334
PR merge metrics
No merged PRs in 30d

Description

### Community Note

* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) 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 an optional signingRoleArn field to the pull-through cache rule configuration so that ECR managed signing works for images cached via pull-through cache.

Which service(s) is this request for?

Amazon ECR, AWS Signer

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

We want to use ECR managed signing (via AWS Signer) for all images in our registry, including those pulled via pull-through cache rules.

When an image is fetched through pull-through cache, ECR uses AWSServiceRoleForECRPullThroughCache to push the cached image. With ECR managed signing enabled, ECR attempts to call signer:SignPayload under this role during the push. However, the attached managed policy (AWSECRPullThroughCache_ServiceRolePolicy) does not include signer:SignPayload, resulting in:

`arn:aws:sts:::assumed-role/AWSServiceRoleForECRPullThroughCache/...`is not authorized
to perform: signer:SignPayload on resource: `arn:aws:signer:us-east-1::/signing-profiles/...`
because no identity-based policy allows the signer:SignPayload action

Are you currently working around this issue?

No workaround exists. The service-linked role is immutable — customers cannot attach additional policies or inline policies to it. The only option is to disable managed signing for pull-through cache repositories entirely, which defeats the purpose of having a registry-wide signing policy.

Adding signer:SignPayload to AWSECRPullThroughCache_ServiceRolePolicy is not a viable fix either, since signer:SignPayload must be scoped to a specific signing profile resource. A wildcard grant across all signing profiles in an account would be overly permissive.

Possible Solution

Add an optional signingRoleArn field to the pull-through cache rule configuration. When ECR managed signing is enabled and a cached image is being pushed, ECR assumes this customer-provided role to call signer:SignPayload instead of using AWSServiceRoleForECRPullThroughCache.

This follows the pattern already established by custom_role_arn on pull-through cache rules for cross-account access. The customer creates an IAM role with signer:SignPayload scoped to their exact signing profile ARN and passes it on the rule. This keeps the SLR minimal and unchanged, requires no policy changes on AWS's side, and gives customers precise control over which signing profiles are usable per cache rule.

Example configuration:

{
"ecrRepositoryPrefix": "docker-hub",
"upstreamRegistryUrl": "registry-1.docker.io",
"signingRoleArn": "arn:aws:iam:::role/ecr-pull-through-signing-role"
}

There may be other ways to do this as well but I would like to be able to use one signing profile for all images in our ECR registry regardless of if they were made via pull through cache or not.

Contributor guide

Open the contributing guide

Research direction

Start with the pull-through cache rule configuration and compare the requested signingRoleArn with the existing custom_role_arn pattern. Review how ECR managed signing invokes AWS Signer and verify that the configured IAM role can be scoped to the signing profile ARN. Done means pull-through cached images can use managed signing without changing the service-linked role.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws
Domain
cloud, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.