Kubeconfig Templating & Disabling /quitquitquit

[ripta]

First off, thanks for your work on kuberos!

There are two features that we'd find useful for our cluster, and I wanted to see your thoughts before submitting a PR:

1. Some form of kubecfg templating. We're already operating multiple clusters, and users to authenticate to each cluster separately. We have an installation of kuberos running on each cluster. Right now, it means we have to maintain a different ConfigMap for each cluster. I think it would be handy to be able to have kuberos inject the API server's ca.crt (available from inside the pod as /run/secrets/kubernetes.io/serviceaccount/ca.crt if a service account is mounted). Being able to do the same for the name of the cluster cluster and/or setting a default context would be great, too.

   One obvious way is the have some form of templating. It's obviously the most flexible, but not sure how/if templating would Just Work™ with clientcmd.LoadFromFile(*templateFile). Another way would be to make it a CLI flag that makes it such that kuberos always injects the local ca.crt (if one exists) in populateUser(...).

2. Disabling /quitquitquit. I think it can be as simple as a CLI flag, but I'd like to propose the endpoint be disabled by default.

[negz]

Thanks for the kind words!

1. I think this would be useful for folks with a single cluster, or a one-Kuberos-per-cluster pattern that you have deployed. If we can implement this in a backwards compatible fashion I'd be happy to have it supported. I'm not a huge fan of templating - assuming you mean building a kubeconfig from a template. I wonder if there's some functionality in the clientcmd package for forming a kubeconfig file from the various parts we care about (i.e. CA cert, API server address, Kuberos user).

2. This seems straightforward. I usually don't like to change the default behaviour, but I bet few if any people are using /quitquitquit, so I'd be happy for it to default off.

[ripta]

Implemented in the two referenced PRs. Closing.