(app-staging-synthesizer-alpha): Allow adding PolicyStatements to imageRole
- 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
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