aws / aws/aws-cdk

lambda.DockerImageCode: Support passing only an ECR image URI w/ digest to DockerImageFunction / DockerImageCode (cross-account scenario)

Open
#36,196 2 comments 0 reactions 0 assignees View on GitHub
@aws-cdk/aws-lambda effort/medium feature-request p2
Dominant language
TypeScript
Stars
12.9k
Forks
4.6k
Avg merge
2d 3h
Merged PRs (30d)
83

Description

### Describe the feature

Similar to `ContainerImage.fromRegistry(imageUri)` in ECS Fargate, support passing just an ECR URI to DockerImageFunction / DockerImageCode.

Related to https://github.com/aws/aws-cdk/issues/15333#issuecomment-916532353, currently the DockerImageFunction / DockerImageCode construct in CDK supports two main code sources for container images:
- `DockerImageCode.from_image_asset(...)` which builds locally and push as asset. 
- `DockerImageCode.from_ecr(repository: IRepository, …)` which references an existing ECR repository object in the same or different account/stack. 

However, in many cross-account or cross-organization deploy scenarios, you don’t have access (or don’t want to depend) on the Repository CDK object (and its CloudFormation managed lifecycle). Instead you just have a fully formed image URI such as: `111122223333.dkr.ecr.us-east-1.amazonaws.com/my-repo@sha256:…`

The request is to allow passing just that URI so that the construct can still work (with the correct permissions) without requiring the repository object import in the same stack.

Additional notes
- There is an existing issue about referencing images by digest only: “Allow referencing lambda container image by digest” (#15333) which was closed and addressed partly. 
- But that issue did not address passing only an ARN of the repository (without the Repository construct) in cross-account scenarios.
- It might also be worth consulting with the CDK team about handling immutable image digests (for deployment stability) vs. tags.

### Use Case

- A central CI/CD or build account pushes container images into a shared ECR repository (in account A).
- Several deployment stacks in other accounts (account B, account C…) need to deploy lambda functions referencing those images, but do not manage the ECR repo themselves.
- They might only be given the image URI (including digest/tag).
- Using ECS/ Fargate, you can simply pass `ContainerImage.fromRegistry(imageUri)` or similar. The equivalent for Lambda is more constrained.

### Proposed Solution

- Add a new method, e.g., `DockerImageCode.fromImageUrii(imageUri: string)`
- Or overload/extend from_ecr() so that the repository parameter can accept a string URI in addition to the IRepository interface.
- Ensure that IAM permissions (e.g., ```ecr:GetDownloadUrlForLayer, ecr:BatchGetImage, ecr:BatchCheckLayerAvailability```) are still added correctly for cross-account usage.
- Provide documentation examples of passing external image URIs, especially in multi-account setups.

### Other Information

_No response_

### Acknowledgements

- [ ] I may be able to implement this feature request
- [ ] This feature might incur a breaking change

### AWS CDK Library version (aws-cdk-lib)

n/a

### AWS CDK CLI version

n/a

### Environment details (OS name and version, etc.)

n/a

Contributor guide

Open the contributing guide

Research direction

Start with the DockerImageFunction and DockerImageCode entry points, especially from_ecr(), and compare their behavior with ECS ContainerImage.fromRegistry(imageUri). Trace how ECR permissions are added for cross-account images. Done means a decided URI-based API, correct digest or tag handling, IAM coverage, tests, and documentation examples for external image URIs.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, typescript
Domain
cloud
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.