kubernetes-sigs/cluster-api

Support multiple kubeconfigs for a provider

開放

#3,661 建立於 2020年9月18日

 (30 則留言) (3 個反應) (0 位負責人)Go (1,532 個分叉)auto 404
area/clusterctlhelp wantedkind/featurepriority/important-longtermtriage/accepted

倉庫指標

星標
 (4,267 顆星)
PR 合併指標
 (PR 指標待抓取)

描述

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

貢獻者指南