Currently KubePlus Pod uses an in-cluster ServiceAccount (named "kubeplus-saas-provider") which needs to be created per cluster separately. This requires that when a service provider is working with multiple clusters, there needs to be a separate provider kubeconfig created and maintained per cluster.
This issue is to track the work for creating a provider identify abstraction that is independent of a cluster. With this, it will be possible for a provider to use a single identity across clusters for the KubePlus Pod. For example, using something like AWS IAM User and Role that work across different EKS clusters.
Note that even if we use AWS IAM User and a Role, which will be defined outside of a cluster, still that role will need to be mapped to an identity within a cluster (like a ServiceAccount), because the identity in the cluster is what the KubePlus Pod uses when it starts running. So we will still need ServiceAccount creation per cluster, but may be by using an outside identity, the provider gets a single notion of identity that is independent of the cluster.
@PatrickBladeeman Thanks for the suggestion.
Could DEX help? https://dexidp.io/docs/getting-started/
Currently KubePlus Pod uses an in-cluster ServiceAccount (named "kubeplus-saas-provider") which needs to be created per cluster separately. This requires that when a service provider is working with multiple clusters, there needs to be a separate provider kubeconfig created and maintained per cluster.
This issue is to track the work for creating a provider identify abstraction that is independent of a cluster. With this, it will be possible for a provider to use a single identity across clusters for the KubePlus Pod. For example, using something like AWS IAM User and Role that work across different EKS clusters.
Note that even if we use AWS IAM User and a Role, which will be defined outside of a cluster, still that role will need to be mapped to an identity within a cluster (like a ServiceAccount), because the identity in the cluster is what the KubePlus Pod uses when it starts running. So we will still need ServiceAccount creation per cluster, but may be by using an outside identity, the provider gets a single notion of identity that is independent of the cluster.
@PatrickBladeeman Thanks for the suggestion.
Could DEX help? https://dexidp.io/docs/getting-started/