[iam] iam.Group should check if inline policy exceeds maximum size

[AlJohri]

I received the following error after deploying my CDK stack. For some reason, it took a very long time for this error to appear.

iam Maximum policy size of 5120 bytes exceeded for group XYZ

Use Case

This error seems simple to test at synthesis time in CDK and would save a lot of debugging time.

Proposed Solution

Check the total size of the combined inline policies for an iam.Group and see if it is less than 5120 bytes.

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

---

This is a 🚀 Feature Request

[swar8080]

Hi @rix0rrr, I looked into how to implement this. Not sure if this is a bigger change then expected, so I figured i'd summarize an approach for feedback before writing code.

For reference here's the documentation on policy character limits: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html#reference_iam-quotas-entity-length

Quick summary of existing classes involved

• PolicyDocument: Responsible for constructing the policy document JSON. Has no knowledge of what type of policy the document is for.
• Policy: Encapsulates the PolicyDocument and keeps track of all the users, groups, and roles associated to that document.
• Identities (User, Group, Role): Knows which policies it's associated with but has no access to the underlying PolicyDocument.

High level approach

• A new PolicyDocumentValidator interface is added with method validatePolicyLength(length: number, policyDocument: any): string | null. It would optionally return a message describing any length validation violations.
• A PolicyDocumentValidator would be an optional instance variable on PolicyDocument.
• During post-processing of PolicyDocument (using cdk.IPostProcessor), after all tokens in the document have been resolved, the PolicyDocument generates its JSON string representation and passes the size to its PolicyDocumentValidator.

PolicyDocumentValidator concrete implementations

• User, Group, Role: Would keep a running sum of the lengths of inline policies passed to them and compare that value to the maximum allowed. These implementations would need to keep track of which policyDocument they have already seen to avoid double counting, since policy documents are resolved multiple times (during the prepare and synth phases).
• Policy - The Policy's implementation of PolicyDocumentValidator would be passed to its PolicyDocument. When called, the Policy would iterate through the referenced users, groups, and roles attached to the policy and pass them the length of the policy document for validation. The Policy would either warn or throw any validation error messages returned by those calls.

Other Decisions

• Warning or error when size is exceeded? AWS doesn't count whitespace towards the limit, which JSON.stringify removes, but there could be minor differences in how characters are counted that could cause false positives.
• Should managed and trust policies also be validated as part of this ticket?

[andreialecu]

Got recently hit by this while doing unrelated changes to a stack.

It resulted in CloudFormation getting stuck for 1 hour, then failing with this error, which is not a very good experience.

The problem seems to be that cdk makes it easy to create huge IAM policies. I was able to refactor the stack to work around this.

To exemplify, there were a lot of policies being added similar to this below, from various stacks:

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

Instead, a single policy with multiple arns listed in resources should've been added.

[andreialecu]

Got bit by this again via this innocent construct which was executed on multiple task definitions:

taskDefinition.taskRole.grantPassRole(this.someGroup);
taskDefinition.executionRole?.grantPassRole(this.someGroup);

It appears that only about 7 task definitions can be supported by the above code, after which it runs into the maximum size exeeded error.

I was able to deploy a workaround similar to my previous comment above, but this seems like it should be handled better.