aws_eks: Support AccessConfig on aws_eks.Cluster

[TirTech]

Describe the feature

Support setting AccessConfig (or at least AuthenticationMode) on aws_eks.Cluster.

Use Case

We currently use aws_eks.Cluster to create our clusters, and would like to start using EKS access modes (specifically API_AND_CONFIG_MAP)

Proposed Solution

No response

Other Information

No response

Acknowledgements

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

CDK version used

2.118.0

Environment details (OS name and version, etc.)

Ubuntu 22.04.3 LTS on Windows 11 x86_64, python 3.10

[pahud]

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?

[TirTech]

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, ...)

[codeJack]

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>)

[pahud]

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.

[akefirad]

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.

[pahud]

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.

[mikelane]

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.

[pahud]

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.

[venkates67]

looking forward for the update...

[hbjydev]

@pahud Any updates on this? :)

[derbauer97]

@pahud we are also interested in this feature

[pahud]

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.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

[pahud]

Hi folks, this feature was just merged. Let me know if you have any issues and feel free to reach out to me on cdk.dev slack.

@TirTech @codeJack @akefirad @mikelane @venkates67 @hbjydev @derbauer97

[mikelane]

Hi folks, this feature was just merged. Let me know if you have any issues and feel free to reach out to me on cdk.dev slack.

@TirTech @codeJack @akefirad @mikelane @venkates67 @hbjydev @derbauer97

Somewhat unrelated to this thread, but the CDK.dev slack link is broken.

[Xfel]

One thing I noticed is that the L2 construct does not support the KubernetesGroups parameter, which would be very useful for cases where we need more fine-grained options than what the pre-defined AccessPolicies provide.

[pahud]

@mikelane please create a new issue if it's still broken.

@Xfel thank you for your valuable feedback. Can you create a new feat issue for it?