Pinniped over dex

[HamzaZo]

Hey 👋!

Currently, I'm using simple dex for authentication and I would like to migrate to pinniped.

Could you please tell me what is the advantage of pinniped over a simple dex with ldap? What's the real benefits?

Thanks

[cfryanr]

If you are using an LDAP identity provider, then you could use Pinniped or Dex for authentication.

Pinniped will offer many advantages over Dex when you have lots of Kubernetes clusters. Check out some of the advantages listed at the top of this doc: https://pinniped.dev/docs/tutorials/concierge-and-supervisor-demo/

If you love Dex, for example perhaps you like using Dex's GitHub "connector", then you can get the best of both worlds by combining the projects together. Simply configure Dex as the OIDC provider for the Pinniped Supervisor. Pinniped supports Dex as an identity provider, and then Pinniped can provide you with its deep Kubernetes integration and multi-cluster advantages, even when using Dex as the source of identities.

However, since Pinniped has direct support for LDAP and Active Directory (via LDAP), there is no reason to put Dex in the middle when LDAP/AD is your source of identities.

Happy to answer more specific questions that you might have.

[HamzaZo]

Thanks for your answer @cfryanr
I was wondering how I can use pinniped in the CICD pipeline ? could you share any thoughts about that?

Best regards,

[cfryanr]

Pinniped only focuses on user identity, not machine-to-machine identity. However, if you would like to use a user identity for your CI/CD Kubernetes tasks, then you can use Pinniped's CLI-based authentication flow. This is a feature of the Pinniped Supervisor, so it assumes that you are using the Supervisor. This feature is where the Pinniped CLI (a plugin for kubectl) directly prompts the user for their username and password at the CLI without opening any web browser. This is the default behavior for LDAPIdentityProviders and ActiveDirectoryIdentityProviders, and can optionally be enabled for OIDCIdentityProviders. When using this CLI flow, the user can avoid the CLI's interactive prompts for username and password by setting env vars (see https://pinniped.dev/docs/howto/login/ for more information).

The most typical use for this would be to create a "bot" identity in your identity provider and then use that account's username and password in your CI/CD scripts, rather than using an individual human's username/password in a shared team CI/CD environment. This allows that bot identity to have its own RBAC settings in your clusters, allows you to give that bot identity least permissions required on all systems, and avoids sharing a "real" human account's password. The bot identity can then be managed like any other identity, where the bot's account can maintained in the identity provider: e.g. be locked or removed to prevent further access, have its password rotated, etc.