In kubeconfig, every cluster has its own pinniped user entry?

[lknite]

When using kubelogin & its variant which works with azure identity server, in both cases, there is only one user entry in the kube config even if there are multiple clusters defined in the kube config. As long as the user for each cluster is configured as the one user defined, it works. Somehow, when logging in kubelogin knows which cluster you are attempting to access.

But, with pinniped, it appears that I will need to have a pinniped user entry for every cluster (because --concierge-endpoint is required). Is this correct? It's ok if it is, I am building my kubeconfig with a script, just wanting to confirm.

I'm currently using pinniped-concierge only, haven't tried using the supervisor. Not sure yet what it is or why I'd need it.

[cfryanr]

Hi @lknite,

You mentioned that you're not familiar with the Pinniped Supervisor. The Supervisor is a central server which can mange user authentication to a group of Kubernetes clusters. You configure an Identity Provider where your user accounts live, and then the Supervisor provides user-friendly, secure, single sign-on for the whole group of clusters. Your end users sign-on once per day for the whole group of clusters. Currently, the user accounts can come from OIDC, LDAP, or ActiveDirectory identity providers (more IDPs will be supported in the future). See https://pinniped.dev/docs/tutorials/concierge-and-supervisor-demo/ for more details about what it is and why you might need it.

Coming back to your question.... yes, you will have one user entry per cluster. When pinniped get kubeconfig generates a kubeconfig file, it will contain one context, one cluster, and one user. This is true both in a Concierge-only setup and in a Supervisor plus multiple Concierges setup.

• The cluster defines the URL and CA of the Kube API server.
• The user defines how the login should happen. With Pinniped, the user section will not have any specific identity or credentials, making it possible for all your end users to use the same kubeconfig file.
• The context simply binds together the cluster and the user, and provides a name for the context.

If you like, you can use kubectl to merge multiple kubeconfig files into a single file. Or you can keep them as separate files, depending on your preference.

All the usual stuff about choosing which kubeconfig file to use (e.g. $KUBECONFIG or --kubeconfig) and choosing which context to use (e.g. kubectl config use-context) still applies.

As you pointed out, the information about how to connect to the Concierge (URL and CA) are encoded into the user section, and that will be different for each cluster. If you were using the Supervisor then the request-audience would also be different for each cluster. It's also possible for some of the other settings to be different per cluster (e.g. concierge-authenticator-name) although those may not always be different.

Hope this helps! Please let us know if you have any questions about it.

[lknite]

Thank you! This is what I needed to know.