Question about certs in Helm config

[eroji]

In the helm config, there are values for tlsCert, tlsKey and k8s_ca_uri. I understanding that it needs the Kubernetes CA cert in order to generate the kubeconfig, but is there a way to just put that into the config as a base64 value instead of having to host it somewhere? Also, what exactly are the tlsCert and tlsKey supposed to be? Since the authenticator will be sitting behind a TLS secured ingress rule, it still needs a set of cert and key?

[nabadger]

The TLS options in Helm are all optional, but they exist in Helm to support the full set of features.

I'm not running dex or dex-k8s-authenticator in k8s, so this is why that option exists (Helm charts were contributed later).

Using certificate-authority-data could be optional - I feel it's generally considered cleaner to avoid this, but understand people do want to copy kubeconfig files around (so putting everything in 1 file makes this easier).

This is perhaps related to #8 which proposes some UI changes. I imagine the CA would need to be pasted into a text-field by the user, then some JS to update the output command.

[trinitronx]

Just to chime in with an important thing to note: certificate-authority-data is useful for self-signed or otherwise untrusted certs. Without it, users of kubectl will have issues when trying to use it against a kube-apiserver, or Identity Provider with self-signed or untrusted cert. This is going to be the most common use case, because in my experience, few teams will choose to pay for and supply a true CA-signed cert for all the cluster components (kube-apiserver, dex, nginx-ingress, etcd, etc...). Maybe kube-lego could work here, but that just adds more moving parts & cluster bootstrap chicken-egg issues.

Including it hardcoded in a ~/.kube/config helps to add an anchor of trust for these otherwise untrusted certs & chains. Having a trusted source such as dex-k8s-authenticator supply this as a trust anchor in ~/.kube/config makes things easier for users because if they can trust dex & login app to authenticate them (they are giving dex their username & password in case of LDAP auth backend after all), and trust it to give them cluster authentication creds via ~/.kube/config, then they should be able to trust it to provide them with certificate-authority-data too.

Really I suppose it comes down to mutual trust relationships of users and cluster admins in the end.

[eroji]

I have no issue with providing the k8s CA cert and it makes perfect sense. It's more about having the alternative option available where we can provide a base64 value and that can allow k8s-authenticator generate the full kubeconfig on-the-fly OR they can go with a hosted URI should they prefer doing that.

[nabadger]

The config now accepts k8s_ca_pem for each cluster - see #26

Since the helm chart just takes the clusters yaml spec, this should work in any values.yaml you provide.