(aws-eks-v2-alpha): kubectl provider function cannot be placed outside of VPC

[msessa]

Describe the bug

When a Cluster is provisioned with endpointAccess: eks.EndpointAccess.PUBLIC, the kubectl handler function is provisioned outside of a VPC but not its associated Provider function

Regression Issue

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

Last Known Working CDK Library Version

No response

Expected Behavior

When a cluster is provisioned with endpointAccess: eks.EndpointAccess.PUBLIC both kubectl handler and kubectl provider functions should not have a VpcConfig associated

Current Behavior

The Handler lambda function doesn't receive a VpcConfig but its associated Provider function does.

Reproduction Steps

The following test fails

test('public non restricted', () => {
      new eks.Cluster(stack, 'Cluster', {
        version: CLUSTER_VERSION,
        endpointAccess: eks.EndpointAccess.PUBLIC,
        kubectlProviderOptions: {
          kubectlLayer: new KubectlV32Layer(stack, 'kubectlLayer'),
        },
      });


      Template.fromStack(stack).allResourcesProperties('AWS::Lambda::Function', {
        VpcConfig: Match.absent(),
      });
    });

Possible Solution

No response

Additional Information/Context

No response

AWS CDK Library version (aws-cdk-lib)

2.203.0

AWS CDK CLI version

latest

Node.js Version

20

OS

Max

Language

TypeScript

Language Version

No response

Other information

No response

[pahud]

Hi @msessa,

Thank you for reporting this inconsistency in the EKS v2 alpha module. I can confirm this is a valid bug where the kubectl handler and provider functions have inconsistent VPC configuration when using endpointAccess: eks.EndpointAccess.PUBLIC.

Root Cause:
The issue is in the KubectlProvider constructor where the Provider is always created with vpc: props.cluster.vpc, while the Handler correctly uses conditional VPC assignment based on whether privateSubnets is defined.

Expected Fix:
The Provider should use the same VPC logic as the Handler - only placing functions in VPC when private subnets are explicitly specified or when private endpoint access is enabled.

This is a straightforward fix that would make the VPC configuration consistent between both Lambda functions.

Your PR #34878 addresses this by ensuring both the Handler and Provider use the same VPC configuration logic, which will properly place both functions outside the VPC when using public-only endpoint access.

The PR is currently labeled as needing community review. The fix looks straightforward and well-tested. Thank you for both identifying the issue and providing a comprehensive solution!