feat(eks): support AWS Load Balancer Controller 2.8.3 - 2.13.3

[arlampin]

Issue # (if applicable)

Closes #34724.

Reason for this change

AWS Load Balancer Controller project has released versions up to 2.13.3, CDK supports versions only up to 2.8.2

Description of changes

Changes were based on earlier v2.8.2 update PR #31264:

• IAM policy files were downloaded by script
• helm version mapping was created by bash command

Description of how you validated changes

• There already exists a parameterized unit test at packages/aws-cdk-lib/aws-eks/test/alb-controller.test.ts that tests all version definitions.
• Integration test updated to latest version

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[aws-cdk-automation]

(This review is outdated)

[arlampin]

I tried to run integ.alb-controller.ts integration test, but could not get it run for what I think is unrelated setup issue with my dev env.

I got the following error during EKS cluster creation

Resource handler returned message: "Could not unzip uploaded file. Please check your file, then try to upload again.

"errorMessage": "Could not unzip uploaded file. Please check your file, then try to upload again.",
"requestParameters": {
    "layerName": "NodeProxyAgentLayer924C1971",
    "description": "/opt/nodejs/node_modules/proxy-agent",
    "content": {
        "s3Bucket": "cdk-hnb659fds-assets-650891366354-us-east-1",
        "s3Key": "93d96d34e0d3cd20eb082652b91012b131bdc34fcf2bc16eb4170e04772fddb1.zip"
    }
},

[aws-cdk-automation]

This PR has been in the CHANGES REQUESTED state for 3 weeks, and looks abandoned. Note that PRs with failing linting check or builds are not reviewed, please ensure your build is passing

To prevent automatic closure:

• Resume work on the PR
• OR request an exemption by adding a comment containing 'Exemption Request' with justification e.x "Exemption Request: "
• OR request clarification by adding a comment containing 'Clarification Request' with a question e.x "Clarification Request: "

This PR will automatically close in 14 days if no action is taken.

[vishaalmehrishi]

This PR adds multiple versions with new features - it might be a good idea to include some guidance for users to help them decide which one to use (or link some documentation to the version documentation).

[vishaalmehrishi]

@pahud Need some guidance here: the PR refers to a previous PR which used a script to download the IAM policy files. Some of the policies grant broad permissions (resource: *) and some others do not have any conditions attached.

Do we need a security review to ensure that the default policies are safe?

[pahud]

@pahud Need some guidance here: the PR refers to a previous PR which used a script to download the IAM policy files. Some of the policies grant broad permissions (resource: *) and some others do not have any conditions attached.

Totally agree. I don't think we should continue import everything from there as the policies is way too wide open.

Analysis

Analyzing the upstream v2.8.2 iam policies with potential CDK scoped implementation

1. Overly Broad Resource Permissions

// Multiple statements with Resource: "*"
{
  "Action": ["ec2:AuthorizeSecurityGroupIngress", "ec2:RevokeSecurityGroupIngress"],
  "Resource": "*"  // Can modify ANY security group in the account
}
{
  "Action": ["elasticloadbalancing:CreateListener", "elasticloadbalancing:DeleteListener"],
  "Resource": "*"  // Can modify ANY load balancer listener
}

2. Cross-Account/Cross-Region Access

// Allows operations across ALL regions and accounts
"Resource": "arn:aws:elasticloadbalancing:*:*:targetgroup/*/*"

3. Unnecessary Permissions for Many Use Cases

• WAF/Shield permissions (not needed if not using WAF)
• Cognito permissions (only needed for Cognito authentication)
• Service-linked role creation (often already exists)

Benefits of CDK Scoped Approach

1. VPC-Scoped Security Groups

// Instead of: "Resource": "*" for security group operations
// CDK generates:
{
  "Action": ["ec2:AuthorizeSecurityGroupIngress"],
  "Resource": [
    "arn:aws:ec2:us-east-1:123456789012:security-group/*"
  ],
  "Condition": {
    "StringEquals": {
      "ec2:vpc": "vpc-12345678"  // Only this VPC
    }
  }
}

2. Cluster-Specific Resource Tagging

// Enhanced tagging conditions
{
  "Condition": {
    "StringEquals": {
      "aws:RequestTag/kubernetes.io/cluster/my-cluster": "owned",
      "aws:RequestTag/kubernetes.io/service-name": "${service-name}"
    }
  }
}

3. Feature-Based Permission Sets

// Only grant permissions for features actually used
const albController = new AlbController(this, 'ALB', {
  cluster,
  features: {
    wafIntegration: false,        // No WAF permissions
    cognitoAuth: false,          // No Cognito permissions
    shieldProtection: false,     // No Shield permissions
    crossZoneLoadBalancing: true // Only ELB permissions
  }
});

4. Subnet-Scoped Load Balancer Creation

// Instead of creating load balancers anywhere
{
  "Action": ["elasticloadbalancing:CreateLoadBalancer"],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "elasticloadbalancing:subnet": [
        "subnet-12345678",  // Only specific subnets
        "subnet-87654321"
      ]
    }
  }
}

Concrete Security Benefits

Risk Reduction Examples:

1. Blast Radius Limitation
   • Upstream: Can modify security groups across entire AWS account
   • CDK Scoped: Only security groups in specific VPC with cluster tags

2. Cross-Service Isolation
   • Upstream: Can interfere with other ALB controllers or manual load balancers
   • CDK Scoped: Only resources tagged for this specific cluster

3. Feature Isolation
   • Upstream: Always gets WAF/Shield/Cognito permissions
   • CDK Scoped: Only permissions for features you actually use

Migration Path with Immediate Benefits

For migration path with compatibility, we probably want to introduce something like this:

// Phase 1: Drop-in replacement with same broad permissions
albController: {
  version: AlbControllerVersion.V2_8_2,
  policyMode: 'compatible' // Uses broad permissions like upstream
}

// Phase 2: Opt-in to scoped permissions
albController: {
  version: AlbControllerVersion.V2_8_2,
  policyMode: 'scoped',
  scope: { vpcId: vpc.vpcId }
}

// Phase 3: Feature-specific permissions
albController: {
  version: AlbControllerVersion.V2_8_2,
  policyMode: 'minimal',
  features: ['basic-alb', 'ssl-termination']
}

Or just stop supporting the compatible mode as it comes with overly permissive policies.

[vishaalmehrishi]

I tried to run integ.alb-controller.ts integration test, but could not get it run for what I think is unrelated setup issue with my dev env.

I got the following error during EKS cluster creation

Resource handler returned message: "Could not unzip uploaded file. Please check your file, then try to upload again.

"errorMessage": "Could not unzip uploaded file. Please check your file, then try to upload again.",
"requestParameters": {
    "layerName": "NodeProxyAgentLayer924C1971",
    "description": "/opt/nodejs/node_modules/proxy-agent",
    "content": {
        "s3Bucket": "cdk-hnb659fds-assets-650891366354-us-east-1",
        "s3Key": "93d96d34e0d3cd20eb082652b91012b131bdc34fcf2bc16eb4170e04772fddb1.zip"
    }
},

I ran this command and it updates the snapshots (takes time though):

yarn integ test/aws-eks/test/integ.alb-controller.js --update-on-failed --disable-update-workflow

I have the snapshots updated locally - I tried to push to your branch to make it easier, but I do not have permission. You can run the command above in your own workspace, or give me permission to merge to your branch - whatever works best for you.

[vishaalmehrishi]

@pahud Need some guidance here: the PR refers to a [previous PR

](https://github.com/aws/aws-cdk/pull/31264) which used a script to download the IAM policy files. Some of the policies grant broad permissions (resource: `*`) and some others do not have any conditions attached.

Totally agree. I don't think we should continue import everything from there as the policies is way too wide open.

Analysis

Analyzing the upstream v2.8.2 iam policies with potential CDK scoped implementation

1. Overly Broad Resource Permissions

// Multiple statements with Resource: "*"
{
  "Action": ["ec2:AuthorizeSecurityGroupIngress", "ec2:RevokeSecurityGroupIngress"],
  "Resource": "*"  // Can modify ANY security group in the account
}
{
  "Action": ["elasticloadbalancing:CreateListener", "elasticloadbalancing:DeleteListener"],
  "Resource": "*"  // Can modify ANY load balancer listener
}

2. Cross-Account/Cross-Region Access

// Allows operations across ALL regions and accounts
"Resource": "arn:aws:elasticloadbalancing:*:*:targetgroup/*/*"

3. Unnecessary Permissions for Many Use Cases

• WAF/Shield permissions (not needed if not using WAF) • Cognito permissions (only needed for Cognito authentication) • Service-linked role creation (often already exists)

Benefits of CDK Scoped Approach

1. VPC-Scoped Security Groups

// Instead of: "Resource": "*" for security group operations
// CDK generates:
{
  "Action": ["ec2:AuthorizeSecurityGroupIngress"],
  "Resource": [
    "arn:aws:ec2:us-east-1:123456789012:security-group/*"
  ],
  "Condition": {
    "StringEquals": {
      "ec2:vpc": "vpc-12345678"  // Only this VPC
    }
  }
}

2. Cluster-Specific Resource Tagging

// Enhanced tagging conditions
{
  "Condition": {
    "StringEquals": {
      "aws:RequestTag/kubernetes.io/cluster/my-cluster": "owned",
      "aws:RequestTag/kubernetes.io/service-name": "${service-name}"
    }
  }
}

3. Feature-Based Permission Sets

// Only grant permissions for features actually used
const albController = new AlbController(this, 'ALB', {
  cluster,
  features: {
    wafIntegration: false,        // No WAF permissions
    cognitoAuth: false,          // No Cognito permissions
    shieldProtection: false,     // No Shield permissions
    crossZoneLoadBalancing: true // Only ELB permissions
  }
});

4. Subnet-Scoped Load Balancer Creation

// Instead of creating load balancers anywhere
{
  "Action": ["elasticloadbalancing:CreateLoadBalancer"],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "elasticloadbalancing:subnet": [
        "subnet-12345678",  // Only specific subnets
        "subnet-87654321"
      ]
    }
  }
}

Concrete Security Benefits

Risk Reduction Examples:

1. Blast Radius Limitation
   • Upstream: Can modify security groups across entire AWS account
   • CDK Scoped: Only security groups in specific VPC with cluster tags
2. Cross-Service Isolation
   • Upstream: Can interfere with other ALB controllers or manual load balancers
   • CDK Scoped: Only resources tagged for this specific cluster
3. Feature Isolation
   • Upstream: Always gets WAF/Shield/Cognito permissions
   • CDK Scoped: Only permissions for features you actually use

Migration Path with Immediate Benefits

For migration path with compatibility, we probably want to introduce something like this:

// Phase 1: Drop-in replacement with same broad permissions
albController: {
  version: AlbControllerVersion.V2_8_2,
  policyMode: 'compatible' // Uses broad permissions like upstream
}

// Phase 2: Opt-in to scoped permissions
albController: {
  version: AlbControllerVersion.V2_8_2,
  policyMode: 'scoped',
  scope: { vpcId: vpc.vpcId }
}

// Phase 3: Feature-specific permissions
albController: {
  version: AlbControllerVersion.V2_8_2,
  policyMode: 'minimal',
  features: ['basic-alb', 'ssl-termination']
}

Or just stop supporting the compatible mode as it comes with overly permissive policies.

@arlampin take a look at the possible options here. We should scope down the permissions before merging this change.

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: 2566e51
• Result: FAILED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[aws-cdk-automation]

This PR cannot be merged because it has conflicts. Please resolve them. The PR will be considered stale and closed if it remains in an unmergeable state.

[aws-cdk-automation]

This PR cannot be merged because it has conflicts. Please resolve them. The PR will be considered stale and closed if it remains in an unmergeable state.

[aws-cdk-automation]

This PR cannot be merged because it has conflicts. Please resolve them. The PR will be considered stale and closed if it remains in an unmergeable state.

[aws-cdk-automation]

This PR cannot be merged because it has conflicts. Please resolve them. The PR will be considered stale and closed if it remains in an unmergeable state.

[aws-cdk-automation]

This PR has been in the BUILD FAILING state for 3 weeks, and looks abandoned. Note that PRs with failing linting check or builds are not reviewed, please ensure your build is passing

To prevent automatic closure:

• Resume work on the PR
• OR request an exemption by adding a comment containing 'Exemption Request' with justification e.x "Exemption Request: "
• OR request clarification by adding a comment containing 'Clarification Request' with a question e.x "Clarification Request: "

This PR will automatically close in 14 days if no action is taken.

[pahud]

Hi @arlampin

This PR has been stale for while, are you still working on it? If you need discussion, feel free to reach out to me on cdk.dev

[aws-cdk-automation]

This PR has been deemed to be abandoned, and will be automatically closed. Please create a new PR for these changes if you think this decision has been made in error.

[github-actions]

Comments on closed issues and PRs are hard for our team to see.
If you need help, please open a new issue that references this one.