(aws-iam): policy document optimization

[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:

aws-cdk/packages/@aws-cdk/aws-iam/lib/role.ts

Lines 241 to 246 in 7966f8d

	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:

aws-cdk/packages/@aws-cdk/aws-iam/lib/policy-document.ts

Line 55 in 7966f8d

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

[andreialecu]

I implemented this in #14714

[rix0rrr]

Leaving this open for future upvotes which may increase the weight, but we consciously decided not to do anything about this.

IAM policy optimization is attractive but also dangerous, and we're super scared of messing up.

If you want to implement this for now, I would suggest you implement an Aspect to twiddle the construct tree out-of-band.

[andreialecu]

@rix0rrr wondering if you saw my comment just above you? The PR received no comments.

[bilalq]

The absence of this results in AWS CodePipelines being unusable for cross-region deployments in many cases. See #16244 for more details.

[comcalvi]

I think this has been resolved by #19114

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.