Repository navigation
[Feature] Implement templating of the tenant clusters kubeconfig files #1604
Description
The admin-kubeconfig file now looks like this:
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: XXXYYYZZZ1
server: https://kubernetes-qwerty-xxx-xxx-xxx-3.qwerty.com:443
name: kubernetes-qwerty-xxx-xxx-xxx-3
contexts:
- context:
cluster: kubernetes-qwerty-xxx-xxx-xxx-3
user: kubernetes-admin
name: kubernetes-admin@kubernetes-qwerty-xxx-xxx-xxx-3
current-context: kubernetes-admin@kubernetes-qwerty-xxx-xxx-xxx-3
kind: Config
preferences: {}
users:
- name: kubernetes-admin
user:
client-certificate-data: XXXYYYZZZ2
client-key-data: XXXYYYZZZ3
The main problem is that if you have several clusters and want to combine them into one kubeconfig or write them all to the shell environment variable: KUBECONFIG, then because kubectl matches the context not by the context itself, but by the user, kubectl will not be able to find the right cluster and will return a certificate error. This means that each user must be unique. Currently, I have to manually add any suffix to the user name like that: kubernetes-admin@qwerty-xxx-xxx-xxx-3, and then kubectl successfully connects to the desired cluster.
The second problem is that the context name contains the “@” symbol: name: kubernetes-admin@kubernetes-qwerty-xxx-xxx-xxx-3. Some tools, such as juju, return an error for such contexts.
So, it would be better to add a prefix to the user, as is done with the context, but remove this prefix from the context itself. In addition, I would prefer to remove the kubernetes prefix, as it lengthens the name and is completely useless in terms of naming.
For example, admin-config could look like this:
apiVersion: v1
kind: Config
clusters:
- cluster:
certificate-authority-data: XXXYYYZZZ1
server: https://kubernetes-qwerty-xxx-xxx-xxx-3.qwerty.com:443
name: qwerty-xxx-xxx-xxx-3
contexts:
- context:
cluster: qwerty-xxx-xxx-xxx-3
user: kubernetes-admin@qwerty-xxx-xxx-xxx-3
name: qwerty-xxx-xxx-xxx-3
current-context: qwerty-xxx-xxx-xxx-3
users:
- name: kubernetes-admin@qwerty-xxx-xxx-xxx-3
user:
client-certificate-data: XXXYYYZZZ2
client-key-data: XXXYYYZZZ3
preferences: {}
I also think that many users are already accustomed to the current naming of kubeconfig generation in the CozyStack, so perhaps it would be better to implement a templating settings.
Activity
[-][Feature] Required templating of the kubfeconfig file[/-][+][Feature] Implement templating of the tenant clusters kubfeconfig files[/+][-][Feature] Implement templating of the tenant clusters kubfeconfig files[/-][+][Feature] Implement templating of the tenant clusters `kubeconfig` files[/+]dosubot commentedon Feb 18, 2026
Hi, Petr Dondukov (@kinseii). I'm Dosu, and I'm helping the cozystack team manage their backlog and am marking this issue as stale.
Issue Summary:
Next Steps:
Thank you for your understanding and contribution!
kinseii commentedon Feb 18, 2026
bump
dosubot commentedon Feb 18, 2026
Timofei Larkin (@lllamnyp) The user has indicated this issue is still relevant and needs attention regarding tenant cluster kubeconfig templating and context name improvements. Could you please assist?
github-actions commentedon May 2, 2026
This issue has had no activity for 60 days and was marked
lifecycle/stale.It will be closed in 14 days unless commented or labelled
lifecycle/frozen.dosubot commentedon Aug 1, 2026
Hi, Petr Dondukov (@kinseii). I'm Dosu, and I'm helping the cozystack team manage their backlog and am marking this issue as stale.
Issue Summary
kubectlcertificate conflicts when multiple kubeconfigs are merged or used viaKUBECONFIG.@from context names for better compatibility with tools likejuju.kubernetesprefix.Next Steps
Thanks for your understanding and contribution.