(eks): Use L1 construct (CfnCluster) for L2 eks.Cluster

[literalice]

Description

Currently L2 Cluster construct of eks module doesn't use L1 CfnCluster.
It's confusing, for example if users need to "escape hatches" adding overrides to L1 CfnCluster doen't work.

Use Case

• Users can escape hatches like as standard L2 constructs.
• It should make it easy to catch up with the new features of EKS.
  • For example IPv6 need to fix the corresponding custom resource but Lambda's build-in version boto library cannot create a IPv6 Cluster.

Proposed Solution

Sample implementation is here.

Simply use the CfnCluster in the L2 construct:

new eks.CfnCluster(this, "Resource", {
      resourcesVpcConfig: {
        securityGroupIds: [securityGroup.securityGroupId],
        subnetIds: this.vpc.privateSubnets.map(s => s.subnetId),
        endpointPrivateAccess: endpointAccess._config.privateAccess,
        endpointPublicAccess: endpointAccess._config.publicAccess,
      },
      roleArn: clusterRole.roleArn,
  
      // the properties below are optional
      kubernetesNetworkConfig: {
        ipFamily: props.ipFamily ? props.ipFamily : 'ipv4',
      },
// ...
    });

Currently EKS cluster uses the principal that created the cluster as the administrator to the cluster so Kubectl provider should also use the principal. Specifying the CloudFormation execution role and using the role as kubectlRole would be the one of the solutions to the issue.

const adminRole = new iam.Role(this, 'AdminRole', {
  assumedBy: new iam.AccountRootPrincipal(),
});
if (adminRole.assumeRolePolicy) {
  new iam.ServicePrincipal('cloudformation.amazonaws.com').addToAssumeRolePolicy(adminRole.assumeRolePolicy)
}
adminRole.addManagedPolicy(
  iam.ManagedPolicy.fromAwsManagedPolicyName('AdministratorAccess'));

new ClusterStack(app, 'ClusterStack', adminRole, {
  synthesizer: new cdk.DefaultStackSynthesizer({
    cloudFormationExecutionRole: process.env.CLUSTER_ADMIN_ROLE_ARN,
  }),
});

import { aws_eks as eks } from "aws-cdk-lib";
import { Cluster } from "@literalice/aws-cdk-eks-cfn";

export class ClusterStack extends Stack {
  constructor(scope: Construct, id: string, adminRole: iam.IRole, props?: StackProps) {
    super(scope, id, props);

    // ...

    const cluster = new Cluster(this, 'Cluster', {
      vpc,
      clusterName,
      endpointAccess: eks.EndpointAccess.PUBLIC_AND_PRIVATE,
      adminRole,
      mastersRole,
      ipFamily: 'ipv6',
      version: eks.KubernetesVersion.V1_21,
    });
  }
}

Other information

No response

Acknowledge

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

[otaviomacedo]

Hi, @literalice. If you look at the custom resource handler that is responsible for managing the lifecycle of EKS clusters, you'll see that there is a lot of custom logic involved. If we used the L1 directly, we would lose that.

[peterwoodworth]

@otaviomacedo have we considered offering an alternate L2 construct, or an alternate EKS library for constructs which utilize the L1 EKS constructs? I agree with both of the use cases OP listed as valid reasons to want this.

[literalice]

Thank you for your comments, I understand the EKS custom resource requires logics for managing the cluster's lifecycle.
I think it could be an option to delegate the lifecycle management to CloudFormation native EKS resource.
Obviously it'll break the behavior of the eks.Cluster construct. I agree with the idea of creating new L2 construct for it.
Could you give me opinions about validity of introducing the feature?

If it seems to be reasonable, the way to implementation would be following.

• Creating the L2 construct 'ClusterNative' or something in sample construct library.
  • Or creating aws-eks-alpha for experimental features.
• After reviewing the stability, move it to aws-eks module.

or

• aws-eks-native module for experimental features.
• Creating the L2 construct in the module.
• After reviewing the stability, make it a stable version.

[otaviomacedo]

@peterwoodworth Yes, that's fair. We're looking into possible solutions for this. One of them is to write Amazon public extensions, which would remove the need for custom resources and provide all the features. It's still early stages, so I don't have any details at this point. But I'll keep the community updated.

[github-actions]

This issue has not received any attention in 1 year. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.

[diranged]

I'd rally like to see this re-opened