aws / aws/aws-cdk

(app-staging-synthesizer-alpha): Allow adding PolicyStatements to imageRole

Open
#29,894 3 comments 0 reactions 0 assignees View on GitHub
@aws-cdk/app-staging-synthesizer-alpha effort/small feature-request p2
Dominant language
TypeScript
Stars
12.9k
Forks
4.6k
Avg merge
2d 3h
Merged PRs (30d)
83

Description

### Describe the feature

I'd like to be able to grant the auto-generated image publishing role additional permissions.

### Use Case

I want to add [registry caching](https://docs.docker.com/build/cache/backends/registry/) to my `DockerImageAsset` builds. I have a separate ECR repo called `docker-image-cache` with a lifecycle policy specifically designed for storing cache layers.

However, the Docker `AppStagingSynthesizer` image role doesn't, by default, allow working with other ECR repos for security. For example, the `imageRole` it creates (`cdk-my-app-image-role-us-west-2`) looks like this:

```json
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"ecr:BatchCheckLayerAvailability",
"ecr:BatchGetImage",
"ecr:CompleteLayerUpload",
"ecr:DescribeImages",
"ecr:DescribeRepositories",
"ecr:GetDownloadUrlForLayer",
"ecr:InitiateLayerUpload",
"ecr:PutImage",
"ecr:UploadLayerPart"
],
"Resource": "arn:aws:ecr:us-west-2:12345678910:repository/my-app/my-app-service",
"Effect": "Allow"
},
{
"Action": "ecr:GetAuthorizationToken",
"Resource": "*",
"Effect": "Allow"
}
]
}
```

So the cache step fails:

> User: arn:aws:sts::12345678910:assumed-role/cdk-my-app-image-role-us-west-2/aws-cdk-blimmer is not authorized to perform: ecr:BatchCheckLayerAvailability on resource: arn:aws:ecr:us-west-2:12345678910:repository/docker-image-cache because no identity-based policy allows the ecr:BatchCheckLayerAvailability action

### Proposed Solution

It'd be nice to provide some API to access the imageRole that's auto-generated. Then, I'd like to call `.grantPullPush(imageRole)` on the other ECR repo.

### Other Information

I can work around this by creating a role that allows access to the cache repo:

```ts
private createCdkAppStagingSynthesizerImagePublishingRole(dockerImageCacheRepository: Repository): Role {
const role = new Role(this, "CdkAppStagingSynthesizerImagePublishingRole", {
description: "Used by AppStagingSynthesizer stacks to publish images",
assumedBy: new AccountPrincipal(this.awsAccount.id),
roleName: "cdk-app-staging-synthesizer-image-role",
});
dockerImageCacheRepository.grantPullPush(role);

return role;
}
```

Then referencing it in the defaultStackSynthesizer:

```ts
const app = new App({
defaultStackSynthesizer: AppStagingSynthesizer.defaultResources({
appId: "my-app",
stagingBucketEncryption: BucketEncryption.S3_MANAGED,
imageAssetVersionCount: 10, // keep the 10 most recent versions of the image assets for rollback
imageAssetPublishingRole: BootstrapRole.fromRoleArn(
"arn:aws:iam::13245678910:role/cdk-app-staging-synthesizer-image-role",
),
}),
});
```

However, I will eventually run into a quota issue because each app staging synthesizer attaches a managed policy that grants access to work with its specific ECR repos.

I also tried to dig into the staging stack to find the role resource and append another PolicyStatement. However, I think the role is lazily created, so I'm not sure how to grab it through L1 constructs (e.g., `this.synthesizer.stagingStack`).

I also considered saving the cache in the same ECR repo, however, it pushes a lot of extra layers (with mode `max` for caching), so the "expire any 10 images" lifecycle rule will cause problems.

### Acknowledgements

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

### CDK version used

2.135.0 (build d46c474)

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

MacOS Sonoma

Contributor guide

Open the contributing guide

Research direction

Start with AppStagingSynthesizer.defaultResources and the imageAssetPublishingRole configuration, then inspect how the generated image role is created and how stagingStack exposes it. Define an API for adding PolicyStatements or equivalent permissions to that role, while preserving its existing repository access. Done means callers can grant access to an additional ECR repository and the generated IAM policy contains those permissions.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, typescript
Domain
cloud, security
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.