Do you ever plan on doing something by the book, but it turns out to be too time-consuming and end up taking shortcuts or even postponing the task for another time?
Well, we made no such excuses when that “something” was “authentication,” an important part of modern app development that should be done by the book and not put off until later!
Deploying and Managing a Kubernetes Cluster
Our use case at hand was not that unusual—we had to devise a way to share a Kubernetes cluster with several people across the team, with a single sign-on (SSO) for running “kubectl” across our Kubernetes clusters, without having to pass secret keys between one another.
While Kubernetes has built-in authentication support it requires extra effort to replicate the simple authentication experience we were seeking. For example, you could set up an external OIDC provider, but it involves a lot of manual work. In addition, the right API server flags must be assigned before you create a cluster, or set up in run time with a restart of the control plane. On top of that, every new cluster to be supported requires doing everything mentioned so far, along with opening a help desk ticket to create a dedicated OAuth client for it. You see, it’s easy to see how authentication can become increasingly complex and overwhelming!
Seamless Simplified Login Flow Across All Clusters
This is where Pinniped, a VMware-originated open source project, can help and simplify authentication. Pinniped allows cluster administrators to easily plug in various identity providers and gives users a consistent “log-in-once” authentication experience across all Kubernetes clusters. Users can manage and reconfigure the authentication for all their clusters dynamically via declarative Kubernetes Custom Resource Definitions, or CRDs, rather than when a cluster is created. This capability enables control of all these aspects in a modern GitOps way, limiting the need for manual configurations. Pinniped supports LDAP, Active Directory, and OIDC-compliant identity providers—meaning, a user can log into their cluster using their identity provider of choice with their established identity. With an OIDC IDP, Pinniped streamlines the authentication process by allowing users to have only one OAuth client for all clusters. It issues its own federated tokens, which adds another layer of security, as each token works only with its intended Kubernetes cluster.
Switching and Configuring Authentication Sources
Getting back to our use case, we wanted to authenticate to Kubernetes using our Gitlab identities. What if we decide to switch to another authentication source at some point, like LDAP, you may ask? Pinniped allows us to do it seamlessly! It supports a wide range of identity providers, which gives users the flexibility to move to another authentication provider whenever they want. It’s something that’s easily done by making a minor change in Pinniped’s configuration and has no impact in interacting with the way the Kubernetes clusters are set up.
Configuring our Pinniped and Gitlab identities in our use case is quite straightforward. We started by creating a new OAuth client application in Gitlab, where we specified a few things like the callback URL and the “openid” OAuth scope, which are required so our Gitlab “username” and “group” claims are available in the JWT token. Once this step was done, we copied the Client ID from the Application ID field and Secret given to us from Gitlab, and proceeded with setting up Pinniped.
Configuring the Pinniped side of our environment was simple. Pinniped is composed of three parts – The CLI client (which will be discussed later in this blog), Supervisor and Concierge. The Pinniped Supervisor is an OIDC server that allows users to authenticate with an external identity provider and then issue its own federation ID tokens with user information from the IDP. In our use case, we used Gitlab as our external identity provider. We connected the two by creating an OIDCIdentityProvider resource in which we specified the issuer URL and the claim mappings between our Gitlab claims (i.e., username, mail, group) and the ones to be used in the federated ID tokens. We also specified the name of the Secret, which stores our OAuth Client ID and Secret credentials from Gitlab, before proceeding with configuring the Concierge.
More on Concierge and Supervisor
Pinniped Concierge takes a credential from an identity source (Supervisor in our use case), authenticates the user via that credential, and returns another credential that is understood by the Kubernetes cluster. To connect it to the Supervisor, we had to create a JWTAuthenticator object where we specified things like the issuer URL (Pinniped’s FederationDomain issuer), and any additional claim mappings, etc. The remaining step was to configure the desired RBAC rules for our Kubernetes users.
Once we had everything configured, we were able to use the Pinniped CLI to run through the authentication flow. Pinniped provided us with a kubeconfig file without any identity or credentials baked into it, ready for use by all our teammates. This meant no more headaches managing keys and such! Just the simple log-in-once experience that we wanted.
Configuring and managing the authentication to Kubernetes clusters can be simplified in a way that’s reasonable for everyone to do. With Pinniped, you can add authentication and integrate with almost any Kubernetes cluster in one step. You can use the authentication mechanisms of your choice and have a safer login-once experience when interacting with your clusters. This setup is just one example of Pinniped’s deployment scenarios. Depending on your use case, you can deploy the Supervisor, the Concierge, or both.
Get Involved with the Pinniped Community
Pinniped is being actively developed and the team has just released their latest version, v0.12, which includes better support for Active Directory (AD) identity providers and non-interactive logins to OIDC issuers. Read more about the release on Pinniped’s website or join the community behind the project where everyone is welcome to attend the meetings, ask questions and propose features. Another option is to ask questions via the #pinniped Slack channel in the Kubernetes Slack Workspace (request invite to join if you are not already a member) or if you’re interested in authentication and Go, check out Pinniped’s Contributing guidelines for details on how to contribute to the project. Lastly, I invite you to follow the Pinniped team on Twitter @projectpinniped.
What’s keeping you from learning more about Pinniped?
