Skip to content

(aws-iam): policy document optimization #14713

@andreialecu

Description

@andreialecu

I wonder if this is an acceptable feature request. If so, I could try submitting a PR myself.

aws-iam currently creates sub-optimal policies that could be pretty easily optimized. For example consider a helper method that runs this on an ECR repository:

    policy.addToPolicy(
      new iam.PolicyStatement({
        resources: [repository.repositoryArn],
        actions: [
          "ecr:InitiateLayerUpload",
          "ecr:UploadLayerPart",
          "ecr:CompleteLayerUpload",
          "ecr:BatchCheckLayerAvailability",
          "ecr:PutImage",
        ],
      })
    );

If policy is a "shared" policy, and the stack adds new ECR repositories over time, this construct will very quickly run into #11562.

The optimization would be that instead of creating duplicate statements with the same actions for every separate resource, it could just create one policy statement and merge all the resources together.

For example, it would be the equivalent of adding just one policy of:

    policy.addToPolicy(
      new iam.PolicyStatement({
        resources: [repository.repositoryArn, repository2.repositoryArn, ...etc],
        actions: [
          "ecr:InitiateLayerUpload",
          "ecr:UploadLayerPart",
          "ecr:CompleteLayerUpload",
          "ecr:BatchCheckLayerAvailability",
          "ecr:PutImage",
        ],
      })
    );

Note that I'm aware that new resources could be added to the PolicyStatement instead of adding new statements to the policy, but this results in a lot of extra complexity in the stack's implementation, and I feel that cdk could do an optimization here instead.

Additionally, there are places like:

return Grant.addToPrincipal({
grantee,
actions,
resourceArns: [this.roleArn],
scope: this,
});
which are outside of the user's control, which suffer from the same problem (this very quickly runs into #11562 (comment)) but which could be optimized by this step.

Use Case

The main issue is that the resulting CloudFormation template ends up huge, and runs over some internal limits as mentioned in #11562 (comment) and #11562 (comment)

Proposed Solution

My initial idea is to add a post-processor similar to the one in:

context.registerPostProcessor(new RemoveDuplicateStatements(this.autoAssignSids));

It would detect if the generated policy can be optimized by merging similar resources or actions together.

Other

I think this shouldn't be a breaking change if implemented correctly. Also I'm not sure if it requires any changes, or if it affects the IAM Statement Changes interactive prompt.

  • 👋 I may be able to implement this feature request
  • ⚠️ This feature might incur a breaking change

This is a 🚀 Feature Request

Metadata

Metadata

Assignees

No one assigned

    Labels

    @aws-cdk/aws-iamRelated to AWS Identity and Access Managementeffort/largeLarge work item – several weeks of effortfeature-requestA feature should be added or improved.p2

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions