Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rewrite EKS L2 construct (EKSv2) #605

Open
10 of 11 tasks
evgenyka opened this issue Dec 20, 2023 · 4 comments
Open
10 of 11 tasks

Rewrite EKS L2 construct (EKSv2) #605

evgenyka opened this issue Dec 20, 2023 · 4 comments
Labels

Comments

@evgenyka
Copy link

evgenyka commented Dec 20, 2023

Description

When an EKS cluster is created, the only role that has access to the cluster itself (e.g running kubectl commands) is the role that created the cluster. When using CloudFormation, this would be the CloudFormation execution role. Since this role isn’t assumable by anyone, it effectively means it is impossible to connect to the cluster post creation.
In CDK, we workaround this issue by implementing the L2 using custom resources, instead of L1s. This allows us to create the role that creates the cluster (i.e invokes eks.CreateCluster API), and subsequently use this role to grant additional (user defined) roles permissions on the cluster.
The EKS team added a new feature that allows more control over cluster access. Now it would be possible for CloudFormation to specify a list of roles to be granted access to the cluster, in addition to the role that creates the cluster.
The RFC is to create a new EKS L2 construct and drop the custom resource implementation in favor of the native L1.

This is going to incur a breaking change that will require cluster replacement (because type will change from Custom::AWSCDK-EKS-Cluster to AWS::EKS::Cluster). Given a breaking change is inevitable, we can decide also to make some additional breaking changes in the API that make it more ergonomic and aligned with the new cluster implementation.

Roles

Role User
Proposed by @evgenyka
Author(s) @xazhao
API Bar Raiser @iliapolo
Stakeholders @alias, @alias, @alias

See RFC Process for details

Workflow

  • Tracking issue created (label: status/proposed)
  • API bar raiser assigned (ping us at #aws-cdk-rfcs if needed)
  • Kick off meeting
  • RFC pull request submitted (label: status/review)
  • Community reach out (via Slack and/or Twitter)
  • API signed-off (label status/api-approved applied to pull request)
  • Final comments period (label: status/final-comments-period)
  • Approved and merged (label: status/approved)
  • Execution plan submitted (label: status/planning)
  • Plan approved and merged (label: status/implementing)
  • Implementation complete (label: status/done)

Author is responsible to progress the RFC according to this checklist, and
apply the relevant labels to this issue so that the RFC table in README gets
updated.

@diranged
Copy link

Yes please. Also given how many people have created their clusters via the custom resource, please think about how to introduce an import-system so that we can transition from the old model to the new model seamlessly (I know that's not trivial, but it should be possible).

@kromanow94
Copy link

Hey, this would be really great.

Also, would this other approach drop the need to create two Nested Stacks when creating the EKS Cluster and one Nested Stack when importing to other Stack?

@iliapolo iliapolo added status/proposed Newly proposed RFC and removed status/planning RFC implementation is being planned labels Nov 12, 2024
@xazhao
Copy link
Contributor

xazhao commented Nov 13, 2024

Hi @kromanow94 yes nested stack will be removed in the new EKS L2

@iliapolo iliapolo added status/review Proposal pending review/revision and removed status/proposed Newly proposed RFC labels Nov 19, 2024
@dsilbergleithcu-godaddy

I know that in Dynamo we have Table and TableV2. It might be a wise idea to approach this problem in a similar manner. Have eks.Cluster and eks.ClusterV2. That way we don't have to worry about rolling out the new features and magically breaking anybody who has an EKS cluster. Cluster could then be deprecated and marked as such, and eventually obsoleted. Support could be defined as ending at a particular point in time related to deprecation.

This also facilitates API updates as we really would be independent of the existing "v1" api.

@iliapolo iliapolo added status/final-comment-period Pending final approval status/api-approved API Bar Raiser signed-off the API of this RFC status/approved Ready for implementation and removed status/review Proposal pending review/revision status/api-approved API Bar Raiser signed-off the API of this RFC status/final-comment-period Pending final approval labels Dec 4, 2024
xazhao added a commit that referenced this issue Dec 10, 2024
This is a request for comments about Rewrite EKS L2 Construct. See #605
for additional details.

APIs are signed off by @iliapolo.

---

_By submitting this pull request, I confirm that my contribution is made
under
the terms of the Apache-2.0 license_

---------

Co-authored-by: Eli Polonsky <[email protected]>
@iliapolo iliapolo added status/implementing RFC is being implemented and removed status/approved Ready for implementation labels Dec 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants