Pinniped generate kubeconfig - multi clusters use cases

[HamzaZo]

In the Pinniped documentation, it is mentioned that "For each cluster, use pinniped get kubeconfig to generate the new kubeconfig file for that cluster." However, since we are using the cluster as a service model for our clients, we want to provide a way for users to generate their own Pinniped kubeconfig without requiring admin-level access.

One approach could be to use the following command:

$ pinniped get kubeconfig --api-server-url <url> --api-server-crt <crt> --kube-context <ctx> , etc..

By using this command, users can specify the necessary parameters for Pinniped to generate the kubeconfig file. All they need is the Pinniped CLI, and they can generate the kubeconfig file themselves.
This would eliminate the need for us to generate and share the Pinniped kubeconfig file for each delivered cluster with our clients, and it would also give our clients greater autonomy and flexibility. Moreover, this approach would enhance security by reducing the need for admin-level access.

[cfryanr]

Thanks for the suggestion @HamzaZo.

It would be great for Pinniped to have a built-in solution for self-service kubeconfig generation, but unfortunately we haven't solved that problem yet. One idea that we had was to make an API on the Pinniped Supervisor for this (see #751). Are you using the Supervisor for these clusters?

In the meantime, as a service provider you can create and distribute the Pinniped-compatible kubeconfig files however you see fit. You don't even need to use the pinniped get kubeconfig command to do it if you would prefer to write your own equivalent code.

For example, VMware TKG's integration of Pinniped incudes a custom controller which automatically writes a ConfigMap to the kube-public namespace on every cluster, which includes just enough information for the tanzu CLI to read (as an unauthenticated client) to be able to generate the correct kubeconfig on behalf of any user. I'm not suggesting that you necessarily follow that exact same model, but just mentioning it as an example of a custom integration that solved this problem based on the specific requirements of the use case.

[HamzaZo]

For each cluster we will have both supervisor and concierge.

It sound a great solution to put the necessary informations for a kubeconfig in the kube-public namespace as a configmap. In that case, how pinniped will be able to read the configmap to generate it's own kubeconfig ?

I have another question about user authentication. While reading the doc it's mentioned that :
"The Supervisor will provide a federated identity across all clusters that use the same FederationDomain. The user will be prompted by kubectl to interactively authenticate once per day "

Is there a way to customize it to 2h for example or something like that?

Thanks @cfryanr

[cfryanr]

In that case, how pinniped will be able to read the configmap to generate it's own kubeconfig ?

In that case, the open source pinniped CLI would not know how to use that ConfigMap to generate a kubeconfig. In the TKG example, they use a custom command in their own CLI to generate the kubeconfig file (by reading the ConfigMap).

You could design lots of similar solutions. For example, as the cluster admin, you could build some simple automation that uses the Pinniped CLI to generate a kubeconfig and then write it as a ConfigMap (or Secret, or whatever) in the kube-public namespace. Clients could use kubectl to read the ConfigMap to download the already-assembled kubeconfig from inside the ConfigMap's contents (assuming that your cluster allows unauthenticated API requests). There are no credentials or identities in a Pinniped-generated kubeconfig when you are using the Supervisor, so there's nothing secret in there. That's just one idea. There are lots of ways to solve the problem of distributing kubeconfigs, which are basically just yaml files (by using git, ftp, http, etc).

The current model is that the cluster's creator is usually the person (or the automation) that runs the pinniped get kubeconfig command, and then uses any method that they prefer to distribute that yaml to all the end users of that cluster.

Is there a way to customize it to 2h for example or something like that?

There is not currently a way to directly customize that. It is hardcoded in the Supervisor source code to be 9 hours. However, if you are using an OIDC identity provider, then you can configure the lifetime of the refresh tokens that the OIDC identity provider issues to the Pinniped Supervisor to be shorter. The Pinniped Supervisor will honor the shorter lifetime of the refresh tokens. If the refresh token stops working for refreshing after 2 hours, then the kubectl user's session will also stop working after about 2 hours (plus a few minutes), and they will be prompted to log in again.

[HamzaZo]

Thanks @cfryanr