What is the problem?
After updating to CDK verison 1.138.0 from 1.112.0 my CloudFormation deployments started failed with the following error
Cannot exceed quota for ACLSizePerRole: 2048 (Service: AmazonIdentityManagement; Status Code: 409; Error Code: LimitExceeded; Request ID: 45c28053-a294-426e-a4a1-5d1370c10de5; Proxy: null)
This is because the formatting of the role policy changed to have a statement per principal allowing the sts:AssumeRole action rather than a single statement for all the principals. My role allows ~25 accounts to assume it which generates a policy over the limit in the new CDK version. This diff of a test case from that commit mirrors what I am seeing 9f22b2f#diff-a9e05944220b717b56d514486d7213bd99085c533f08d22b0d0606220bd74567.
I'm raising this as a bug since it caused my previously working stack to fail to deploy after the update. For now I've worked around this with a custom iam.IPrincipal implementation which returns a iam.PrincipalPolicyFragment containing all of my principals.
Reproduction Steps
Create a stack with the following
import * as cdk from "monocdk";
import * as iam from "monocdk/aws-iam";
class TestStack extends cdk.Stack {
constructor(scope: cdk.App) {
super(scope, "Stack");
new iam.Role(this, "CrossAccountSharingRole", {
assumedBy: new iam.CompositePrincipal(
new iam.AccountPrincipal("123"),
new iam.AccountPrincipal("456"),
),
roleName: "CloudWatch-CrossAccountSharingRole",
managedPolicies: [
iam.ManagedPolicy.fromAwsManagedPolicyName("CloudWatchReadOnlyAccess"),
],
});
}
}
What did you expect to happen?
An AssumeRolePolicyDocument with many principals
Resources:
CrossAccountSharingRoleFB26871E:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Statement:
- Action: sts:AssumeRole
Effect: Allow
Principal:
AWS:
- Fn::Join:
- ""
- - "arn:"
- Ref: AWS::Partition
- :iam::123:root
- Fn::Join:
- ""
- - "arn:"
- Ref: AWS::Partition
- :iam::456:root
Version: "2012-10-17"
ManagedPolicyArns:
- Fn::Join:
- ""
- - "arn:"
- Ref: AWS::Partition
- :iam::aws:policy/CloudWatchReadOnlyAccess
RoleName: CloudWatch-CrossAccountSharingRole
What actually happened?
Many AssumeRolePolicyDocuments with a single principal in each
Resources:
CrossAccountSharingRoleFB26871E:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Statement:
- Action: sts:AssumeRole
Effect: Allow
Principal:
AWS:
- Fn::Join:
- ""
- - "arn:"
- Ref: AWS::Partition
- :iam::123:root
- Action: sts:AssumeRole
Effect: Allow
Principal:
AWS:
- Fn::Join:
- ""
- - "arn:"
- Ref: AWS::Partition
- :iam::456:root
Version: "2012-10-17"
ManagedPolicyArns:
- Fn::Join:
- ""
- - "arn:"
- Ref: AWS::Partition
- :iam::aws:policy/CloudWatchReadOnlyAccess
RoleName: CloudWatch-CrossAccountSharingRole
CDK CLI Version
1.138.0 (build 6dbfe8f)
Framework Version
No response
Node.js Version
v14.18.3
OS
AL2
Language
Typescript
Language Version
No response
Other information
No response
What is the problem?
After updating to CDK verison 1.138.0 from 1.112.0 my CloudFormation deployments started failed with the following error
This is because the formatting of the role policy changed to have a statement per principal allowing the
sts:AssumeRoleaction rather than a single statement for all the principals. My role allows ~25 accounts to assume it which generates a policy over the limit in the new CDK version. This diff of a test case from that commit mirrors what I am seeing 9f22b2f#diff-a9e05944220b717b56d514486d7213bd99085c533f08d22b0d0606220bd74567.I'm raising this as a bug since it caused my previously working stack to fail to deploy after the update. For now I've worked around this with a custom
iam.IPrincipalimplementation which returns aiam.PrincipalPolicyFragmentcontaining all of my principals.Reproduction Steps
Create a stack with the following
What did you expect to happen?
An AssumeRolePolicyDocument with many principals
What actually happened?
Many AssumeRolePolicyDocuments with a single principal in each
CDK CLI Version
1.138.0 (build 6dbfe8f)
Framework Version
No response
Node.js Version
v14.18.3
OS
AL2
Language
Typescript
Language Version
No response
Other information
No response