[aws-eks] Can we remove the use of {cluster resource,kubectl} provider completely if the situation is changed?

[foriequal0]

❓ General Issue

This is a summary of my understandings and questions about why we don't use CfnCluster directly, and whether it'll be forever like this.
Correct me if I'm wrong. Thanks.

If I understand correctly, the following issues are major reasons why we have {cluster resource,kubectl} providers.

1. EKS RBAC is tied to who created the cluster: [EKS] [request]: Add AdminRole option at cluster creation containers-roadmap#554
   • Related? EKS API to manage cluster auth: [EKS] [request]: Manage IAM identity cluster access with EKS API containers-roadmap#185 (comment)
2. CF doesn't support some features that REST supports(?)
   • [EKS] Cloudformation support for control plane logging and endpoint access control containers-roadmap#242

So we use a cluster resource provider to delegate the creation/management of a EKS cluster.
We have 2 roles so far:

• adminRole( == kubectlRole): Creates and manage EKS cluster, and issues kubectl command. For CF to automation. Cannot be changed.
• mastersRole: For users. Users assume this. Can be chagned.

Quickstart Amazon EKS takes similar approach for this, but with custom AWSQS::EKS::Cluster type: https://github.com/aws-quickstart/quickstart-amazon-eks/
(I feel like re:inventing wheels around the limitations, not fixing the core problem. It looks like it would support import since it implements update handler, but more complex. Why it isn't public/upstream?)

The Question

1. Would it be possible if situations changed?
   What if we have AdminRole option? What if we have EKS API to manage IAM permissions to a cluster?
   Even if without the fix, what if new eks.Cluster() spawns a nested stack that has a cloudFormationExecutionRoleArn: adminRole?
   Or can we put AWS::EKS::Cluster directly on our stack, and delegate only unsupported options such as endpointPrivateAccess?

2. If all the restrictions are gone, so all the providers become obsolete, how do we migrate after that?
   Would it be simply setting the deletion policy to Retain and importing them to the main stack?

Environment

Other information

[iliapolo]

@foriequal0 Your analysis is correct.

If all the restrictions are gone, so all the providers become obsolete, how do we migrate after that?
Would it be simply setting the deletion policy to Retain and importing them to the main stack?

It might be, we would need to dive deeper into this. Right now it doesn't look like CloudFormation supports importing EKS clusters.

Regardless, the KubectlProvider, will still remain because it serves not just for aws auth, but also for applying general manifests.

We would also need to consider whether or not its worth the effort, do you have specific considerations or are you asking for the sake of maintainability of the EKS construct?

[foriequal0]

Oh I thought CF had supported importing ELS clusters. I didn't know that. Thanks for pointing it out.
I was interested in general maintanability/refactorability of CDK and Cfn stacks. I was concerned about that I cannot freely rename/move/refactor resources in general. EKS was just an example of it since I had tried to use it.

[iliapolo]

I understand. As far as maintainability, while I think that using the CFN resource would provide some relief, at this point, i'm not sure the migration is worth it.

As for refactoring, this is known discussion point (which I see you also participated in :)), but I don't see how using CFN resources helps in that regard, apart from just reducing the number of resources/moving-parts, but it doesn't change anything inherently.

[foriequal0]

I understand that. Thank you for replying the question :)

[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.