# Pinniped, one login for a fleet of Kubernetes clusters > vmware/pinniped is a Kubernetes identity service that lets an organisation connect an existing identity provider, Active Directory or an external OIDC issuer, and then gives users one consistent sign-in across every cluster including on-premises and managed cloud ones. It ships as a server and a kubectl plugin, and it is Apache-2.0 licensed with a public roadmap and scope document. **vmware/pinniped** — Pinniped is the easy, secure way to log in to your Kubernetes clusters. - Repository: https://github.com/vmware/pinniped - Website: https://pinniped.dev - Stars: 743 · Forks: 85 - Language: Go - License: Apache-2.0 - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/vmware-pinniped ## The problem and the shape of the answer Pinniped is described as the easy, secure way to log in to your Kubernetes clusters, and the README says it provides identity services to Kubernetes. The overview breaks that into three commitments. You can plug external identity providers into Kubernetes clusters while keeping the install and configuration experience simple, with first class integration with Kubernetes and the kubectl command line. You can give users a consistent, unified login experience across all your clusters, including on-premises and managed cloud environments. And you can integrate with an enterprise identity provider using standard protocols, or use secure externally managed identities, instead of relying on simple shared credentials. The third point is the heart of it. The common alternative in a fleet is a kubeconfig with a static token or a shared client certificate, and that pattern does not survive contact with an organisation that has a directory service and a policy about credential lifetime. Pinniped's job is to sit between the two, so that kubectl can authenticate against the cluster by completing a flow with the identity provider, and the cluster then has a Kubernetes ServiceAccount for that user behind it. The technology list in the topics confirms the range of providers. OIDC and LDAP are both there, and Active Directory is named separately, which is because AD is usually reached through one of the other two rather than directly. The project is written in Go, with the module path go.pinniped.dev, and the repository is Apache-2.0 licensed with the copyright held by the Pinniped contributors. The releases are steady, v0.45.0 in March 2026, v0.46.0 in May and v0.47.0 in July, with the last push on 2026-10-19. ## SCOPE.md, ROADMAP.md and the governance signals The repository top level contains two documents that tell you more about the project than any feature list would. SCOPE.md is a statement of what the project does and does not intend to be, and the presence of a dedicated scope document is a good sign for a project that could easily sprawl. ROADMAP.md is the public plan, and the fact that it is a file in the repository rather than a wiki page means it is versioned with the code and reviewed like code. There is also a GOVERNANCE.md, a MAINTAINERS.md, a CODE_OF_CONDUCT.md, a CONTRIBUTING.md and an ADOPTERS.md. The adopters file is a list of organisations and products using Pinniped, with a link to a discussion thread where you can add your own, which is the convention for a project that wants a public record of its users without a marketing page. The community channels are broad: GitHub Discussions, GitHub Issues, a Slack channel in the Kubernetes workspace, and a Google Group for updates and meeting invitations. For an evaluation, the combination of SCOPE.md and ROADMAP.md is the most efficient reading you can do. Scope tells you whether the problem is one Pinniped claims to solve, and the roadmap tells you whether the direction of travel is one your organisation wants to depend on. A project with an open roadmap that you disagree with is a different risk from a project with an open roadmap that matches your needs. The contribution guide is described as covering reporting bugs, requesting features, building and testing the code, and submitting pull requests, and the README is unusually direct about why contributions matter: Pinniped is better because of its contributors and maintainers. ## What the dependencies say about the implementation The dependency list in go.mod is instructive because it names the protocols and the machinery in one place. For the identity side there is ory/fosite, which is an OAuth 2 and OpenID Connect server library, coreos/go-oidc for the OIDC client side, golang.org/x/oauth2, and go-jose in both version 3 and version 4, the JOSE implementation for the signed tokens that carry the identity across the boundary. For directories there is go-ldap/ldap/v3, which is how an Active Directory or OpenLDAP server is queried. The Kubernetes side is the usual set of client libraries at 0.37.1, including apiextensions-apiserver, which tells you Pinniped installs its own custom resources and needs the extension API server. It also depends on controller-runtime, since the supervisor and the controller are Kubernetes controllers. Then there are two dependencies that reveal something about how the project is tested. chromedp and creack/pty are the tools for driving a headless browser and for allocating a pseudo terminal, and a project that depends on both is doing end to end tests of a browser-based login flow. The pkg/browser dependency supports the same idea. You cannot test an interactive OIDC login in a unit test without a browser, so the project drives a real one. Two more are worth noting. cel.dev/cel-go is the Common Expression Language, which is how Kubernetes admission policies are written, so Pinniped is generating policy rather than hard-coding a fixed set of rules. And gorilla/securecookie and gorilla/websocket are for the session and callback handling that a browser-based flow needs. The top level directories follow the same separation. There are apis/ for the custom resource definitions, cmd/ for the binaries, deploy/ for the installation manifests, generated/ for generated clients, internal/ for the implementation, pkg/ for the public packages, proposals/ for the design documents that precede each feature, and site/ for the documentation. The proposals/ directory is worth knowing about, because a project that writes proposals before implementing is one where you can read the reasoning before the code changes. ## How it fits against the alternatives The alternative that comes first to mind is the cloud provider's own identity integration, since most managed Kubernetes offerings ship one. The difference in approach is where the trust lives. A provider's integration is convenient and tightly coupled to that provider, and it generally does not speak to an on-premises Active Directory. Pinniped is provider-neutral, sits inside your cluster, and holds the mapping from an external identity to a Kubernetes ServiceAccount in a way you can inspect. The second alternative is a plain OIDC provider configured directly into each cluster's API server. That works and it is less to deploy, and it has two limitations that matter at fleet scale. Each cluster needs its own issuer configuration, so a change of identity provider means touching every cluster. And the mapping from an external identity to a Kubernetes identity has to be expressed in each cluster separately, which is the sort of thing that drifts. The third is a service mesh or a proxy that handles authentication in front of the API server. That changes the trust model rather than improving the same one, and it introduces a component that has to be highly available for the cluster to be usable. The fourth is doing nothing and managing a distribution of kubeconfig files with certificates that you rotate by hand. For a small organisation with a handful of clusters, this is entirely reasonable, and it is where many teams start. It stops being reasonable when the number of clusters and the number of people both grow, because the rotation becomes a recurring project. What Pinniped does not do is worth checking against SCOPE.md, but the general shape is that it is an authentication service rather than an authorisation system. It establishes who someone is and maps that to a cluster identity; it does not decide what they may do. That separation is the right one, because authorisation policies belong to the cluster and change for reasons that have nothing to do with how you log in. The operational cost to plan for is a supervisor and a controller running in each cluster, plus the identity provider configuration, plus the fact that a login flow now involves a browser and a round trip to the identity provider, which is a different failure mode from a token in a file. That is the price of the consistency the README promises, and it is a real price rather than a rounding error. ## Conclusion Adopt Pinniped if you run more than one Kubernetes cluster and want a single sign-in backed by your existing identity provider, including an on-premises directory, rather than per-cluster static credentials. Skip it if you have a single cluster and an identity provider already integrated into it. Verify first by reading SCOPE.md and ROADMAP.md, because the project is explicit about what it does and does not intend to cover, then install one supervisor with a test identity provider before rolling it to a fleet. ## FAQ ### What does Pinniped do for a Kubernetes cluster? It provides identity services to Kubernetes, letting you plug external identity providers into clusters, giving users a consistent unified login across on-premises and managed cloud environments, and integrating with an enterprise identity provider over standard protocols instead of relying on simple shared credentials. ### Which identity protocols does Pinniped support? OIDC and LDAP, with Active Directory usually reached through one of those rather than directly. The dependency list names ory/fosite as the OAuth 2 and OpenID Connect server library, coreos/go-oidc on the client side, and go-ldap for directory queries, with go-jose handling the signed tokens. ### Is Pinniped a Kubernetes project? It is a VMware project licensed under Apache 2.0, but it is not a subproject of Kubernetes upstream. The repository has its own GOVERNANCE.md, MAINTAINERS.md and CODE_OF_CONDUCT.md, and it uses the Kubernetes Slack workspace channel and a Google Group for community discussion. ### What documents should I read before adopting Pinniped? SCOPE.md states what the project does and does not intend to cover, and ROADMAP.md is the public plan kept in the repository alongside the code. Both are in the repository top level, next to ADOPTERS.md, which lists organisations using the project. ### How does Pinniped handle security reports? There is a SECURITY.md file with the procedure to follow, and the README points to it under the reporting security vulnerabilities heading. The project is Apache-2.0 licensed with copyright held by the Pinniped contributors. ## Sources - [License: Apache-2.0](https://github.com/vmware/pinniped/blob/main/LICENSE) - [Project website](https://pinniped.dev) - [README](https://github.com/vmware/pinniped/blob/main/README.md) - [Releases](https://github.com/vmware/pinniped/releases) - [vmware/pinniped on GitHub](https://github.com/vmware/pinniped) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/vmware-pinniped