Description
User Story
As a Cluster API Provider developer I would like Cluster API to support multiple kubeconfigs for the situation where the kubeconfig used by CAPI needs to be different to the kubeconfig that a user would use to connect to the created Kubernetes cluster.
Detailed Description
The implementation of EKS support in CAPA generates 2 kubeconfig files. We did this as the kubeconfig for EKS usually uses the aws-iam-authenticator or aws binary to generate the authentication token. This caused issues with CAPI as those binaries don't exists in the capi images (and shouldn't exist in the images). So we decided to generate 2 different kubeconfigs, one for use by CAPI that has a short lived token (max 15mins validity) and adheres to the current kubeconfig secret naming convention. A second kubeconfig is generated and stored in the management cluster for use by a user and this uses aws-iam-authentictor or the aws cli and we add a -user to the name of the secret.
Currently this difference is documented in the EKS specific documentation as the feature is experimental.
It would good to allow this distinction in CAPI and define a naming convention etc. And clusterctl get kubeconfig should probably return the user focused kubeconfig by default with an option to return the one used by capi. Both configs could be the same as well.
Anything else you would like to add:
There has been a feature request raised about this in capa about this
/kind feature
Activity