Yes this is an awesome feature we just announced and we definitely should support that. Would you tell me more about your expected CDK experience with that?

Yes this is an awesome feature we just announced and we definitely should support that. Would you tell me more about your expected CDK experience with that?

Sure. When creating an EKS cluster, we would like to opt in to access entries by passing the authentication mode to the constructor:

cluster = aws_eks.Cluster(
            self,
            id="MyCluster",
            # ...snipped
            authentication_mode=aws_eks.AuthenticationMode.API_AND_CONFIG_MAP
        )

with aws_eks.AuthenticationMode being one of the available cluster authentication modes (default CONFIG_MAP).

For now we would go on to create CfnAccessEntry resource for each of the IAM roles we want to grant cluster access to, but in the future we would be looking to get the higher level AccessEntry resource added so we could create these entries for some aws_iam.Role "role" either on their own:

aws_eks.AccessEntry(
            self,
            id="AdministatorAccessEntry",
            cluster_name=cluster.cluster_name,
            principal_arn=role.role_arn,
            # other options
        )

or with a helper method on the cluster:

cluster.add_access_entry(self, id="AdministatorAccessEntry", principal_arn=role.role_arn, ...)

Thanks @TirTech for raising this one.

@pahud to complement what has been shared above around the expected CDK experience with AccessConfig.

• Ideally, the aws_eks.Cluster construct should also expose the bootstrapClusterCreatorAdminPermissions flag along with AuthenticationMode.
  Today the role which creates the cluster is intrinsically a Kubernetes Cluster Administrator (doesn't even show up in the aws-auth config map). With access entries you might want to have full control and explicitly grant access to IAM entities. The CDK IAM model would need to evolve accordingly as today, by default, the kubectl provider leverages the cluster creation role as kubectl role. I would expect a dedicated IAM identity to be crafted for this specific purpose so that it can be audited and quarantined in case of need.
• About how to provide access to IAM roles into the cluster, I would expect the aws_eks.Cluster construct to somehow expose grant semantics to be consistent with other CDK libraries.
  Something along these lines, where IGrantable is implemented by IAM roles, users, groups etc:

# Grant cluster admin (system:masters RBAC group)
cluster.grant_admin(IGrantable)
# Grant read only (similarly to what a console user needs to navigate the cluster resources)
cluster.grant_read_only(IGrantable)
# General purpose grant where explicit mapping to RBAC access management can be expressed.
# Eventually this one could also take care of the heavy lifting by creating the Kubernetes' Role/ClusterRole/Binding/Group behind the scenes.
cluster.grant(IGrantable, <rbac mapping>)

This makes sense to me. Thank you for the user experience sharing. I am bumping this issue to p1 now but we still welcome any pull requests from the community.

Is this possible/safe to use the escape hatch to enable API_AND_CONFIG mode until this feature is released? Asking because if it’s enabled manually, it cannot be set in the CDK stack anymore since the deployment is going to fail (which seems unnecessary, it could have simply succeeded, but that’s not the point here). Thanks.

Just self-assigned. I will pick up this issue and see if I can submit a PR in the next few days. I can't guarantee any ETA but this is something I am really looking forward to.

FYI, I attempted to use an escape hatch like this:

export default class MyEks extends Construct {
  public readonly cluster: eks.Cluster
  
  // other constructs here

  this.cluster = eks.Cluster(this, 'MyEksCluster', {
    // Various props here
  });
  
  const cfnCluster = this.cluster.node.defaultChild as eks.CfnCluster;
  cfnCluster.accessConfig = {authenticationMode: 'API_AND_CONFIG_MAP'};
}

But this did not set the authentication mode value. It doesn't appear in the synthesized cloudformation and the option isn't selected in the console.

We are discussing with the team what is the best option for us to rollout this feature. Will update here in the next few days.

looking forward for the update...

@pahud Any updates on this? :)

@pahud we are also interested in this feature

Thanks for all the upvotes. We are still discussing with the team as adding this feature is not as simply as just adding the accessConfig prop for the ClusterProps. We probably need to implement the AccessEntry L2 construct as well.

What I am planning for the low hanging fruits is:

1. add accessConfig in ClusterProps and on cluster creation or update, enable this with SDK call.
2. make sure we can create the AccessEntry with CfnAccessEntry L1 construct and work well with the cluster.

This should be a small PR to unblock this for now.

And after that, we could have another PR to implement the AccessEntry L2 for better developer experience.

Let me know if you have different thoughts and feel free to chat with me for more details on cdk.dev slack.