(aws-eks): ALB Controller deployment fails on a fully-private cluster

[daniel-rhoades]

Describe the bug

When using the L2 construct within the aws_eks_v2_alpha library to define an EKS cluster, specifying an ALB Ingress Controller will cause the stack deployment to fail when using a fully-private cluster (a cluster with a private control plane running in a VPC without any routes to an IGW).

The problem arrises due to the assumption of Internet access within the Helm chart definition of the AlbController construct:

aws-cdk/packages/@aws-cdk/aws-eks-v2-alpha/lib/alb-controller.ts

Lines 333 to 356 in 6a57c50

	const chart = new HelmChart(this, 'Resource', {
	cluster: props.cluster,
	chart: 'aws-load-balancer-controller',
	repository: 'https://aws.github.io/eks-charts',
	namespace,
	release: 'aws-load-balancer-controller',
	version: props.version.helmChartVersion,
	wait: true,
	timeout: Duration.minutes(15),
	values: {
	clusterName: props.cluster.clusterName,
	serviceAccount: {
	create: false,
	name: serviceAccount.serviceAccountName,
	},
	region: Stack.of(this).region,
	vpcId: props.cluster.vpc.vpcId,
	image: {
	repository: props.repository ?? '602401143452.dkr.ecr.us-west-2.amazonaws.com/amazon/aws-load-balancer-controller',
	tag: props.version.version,
	},
	},
	});

Currently the AlbControllerOptions do not support specifying an alternative repository.

Not sure if this should be a bug or feature request.

Regression Issue

• Select this option if this issue appears to be a regression.

Last Known Working CDK Version

No response

Expected Behavior

Allow alternative location of helm chart assets to be passed when specifying an ALB Controller on a fully-private EKS cluster.

Current Behavior

Although the AlbController supports specifying an alternative repository, it does not currently support specifying an alternative location for its corresponding helm chart asset:

aws-cdk/packages/@aws-cdk/aws-eks-v2-alpha/lib/alb-controller.ts

Lines 244 to 273 in 6a57c50

	export interface AlbControllerOptions {
	/**
	* Version of the controller.
	*/
	readonly version: AlbControllerVersion;
	/**
	* The repository to pull the controller image from.
	*
	* Note that the default repository works for most regions, but not all.
	* If the repository is not applicable to your region, use a custom repository
	* according to the information here: https://github.com/kubernetes-sigs/aws-load-balancer-controller/releases.
	*
	* @default '602401143452.dkr.ecr.us-west-2.amazonaws.com/amazon/aws-load-balancer-controller'
	*/
	readonly repository?: string;
	/**
	* The IAM policy to apply to the service account.
	*
	* If you're using one of the built-in versions, this is not required since
	* CDK ships with the appropriate policies for those versions.
	*
	* However, if you are using a custom version, this is required (and validated).
	*
	* @default - Corresponds to the predefined version.
	*/
	readonly policy?: any;
	}

As the default helm chart location is not reachable from within a private VPC, enabling the ALB Controller feature of this L2 construct will cause a stack deployment failure.

Reproduction Steps

1. Create a VPC with only private subnets, but with access to the necessary VPC Endpoint Interfaces for EKS deployment and operations
2. Create a Cluster with an endpoint access of "PRIVATE" and ALB Controller options

Possible Solution

The HelmChart construct already provides the necessary configuration. Probably the quickest fix would be within AlbControllerOptions, I suggest replacing the repository property with a new property (e.g. helmChartOptions) for HelmChartOptions, this will allow specifying external chart assets (e.g. an S3 Asset or ECR Repository) as preferred.

Workaround

Use a CDK escape hatch to override properties of the chart resource embedded within the AlbController construct after specifying an ALB Controller on a cluster.

Additional Information/Context

After drafting this issue, I realise it may be related / duplicate of #33801, I've left this for now as hopefully the analysis completed for this issue will be useful.

CDK CLI Version

2.1002.0 (build 09ef5a0)

Framework Version

No response

Node.js Version

22.14.0

OS

MacOS

Language

Python

Language Version

No response

Other information

No response

[pahud]

Yes, for fully private environment, some additional vpc endpoints will be required.

Unfortunately we don't have a working sample for albController in a isolated VPC.

Making this a p2 and we welcome more inputs here.

related #12171