As discussed in this and its following posts, it is normal practice for users to configure kubeconfig to execute arbitrary helpers for authentication, and it is not feasible to ship all of these within the fluxctl snap itself. For example doctl or aws-iam-authenticator.
what is your plan for migrating existing fluxctl snap users?
Good question – this might just be a breaking change?
how many authentication helpers are there?
IMO, it’s infeasible to support every arbitrary auth method.
Kubernetes is an open platform meaning every cloud provider, bare-metal vendor, and internal platform team may use their own auth helper for temporary tokens, SAMLv2, kerberos/AD, etc.
When new implementations are created, it becomes user-hostile to expect that maintainers and devs would contribute builds of those tools to some central kubeconfig plug.
The security model of kubeconfig does not appear to isolate well unless we can provide users some way to easily mount binaries and directories into a confined snap runtime.