Update aws-auth ConfigMap in clusters created outside of CDK

[jicowan]

Describe the feature

Add the ability to "import" existing EKS clusters that were created outside of CDK/CloudFormation so that you can use the AddRoleMapping method to update the aws-auth ConfigMap

Use Case

I have inadvertently corrupted the aws-auth ConfigMap when updating it manually. When this happens, I lose access to the cluster and have to manage it using the IAM user/role that was used to provision the cluster. I would like to be able to use the CDK to consistently and correctly apply changes to the ConfigMap.

Proposed Solution

The following should work:

cluster = eks.Cluster.from_cluster_attributes(self, "Cluster", cluster_name="MyEKSCluster") <-- existing cluster
role = iam.Role.from_role_arn(self, "Role", "arn:aws:iam::123456789012:role/my_role") <-- existing role
eks.AwsAuth(self, "Auth", cluster=cluster).add_role_mapping(role=role, groups="system:masters") <-- add role mapping

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

Environment details (OS name and version, etc.)

MacOS Monterey 12.2.1

[jicowan]

The function would need to be authorized to update the aws-auth ConfigMap. If you import an existing cluster, you should be allowed to pass in the role you want the function to assume or run as the current logged in user.

[sdpoueme]

This is definitely a useful feature. We are building an end-to-end ci/cd pipeline for containerized game servers and facing that issue at the moment.

[srinivasreddych]

This is a needed feature for us. We are building a shared compute capacity on EKS, where we would like to run Batch Jobs, Spark jobs etc, and everytime we onboard a new use-case specific module, adding the Role/user to the aws-auth CM on an imported cluster is causing us trouble. For now, we are using eksctl to establish the identity mapping and resuming other CDK processes.

[iliapolo]

This issue has been re-classified as p2. That means a workaround is available or it is deemed a nice-to-have feature. Given the amount of work there is to do and the relative priority of this issue, the CDK team is unlikely to address it. That does not mean the issue will never be fixed! If someone from the community submits a PR to fix this issue, and the PR is small and straightforward enough, and meets the quality bars to be reviewed and merged with little effort we will accept that PR. PRs that do not build or need complex or multiple rounds of reviews are unlikely to be merged and will be closed to keep our backlog manageable.

We use +1s on this issue to help prioritize our work, and are happy to re-evaluate the prioritization of this issue based on community feedback. You can reach out to the cdk.dev community on Slack to solicit support for reprioritization.