Blog post for LDAP release
This commit is contained in:
Ryan Richard
parent
9621ad9d2c
commit
0d43105759
141
site/content/posts/2021-05-31-first-ldap-release.md
Normal file
141
site/content/posts/2021-05-31-first-ldap-release.md
Normal file
@ -0,0 +1,141 @@
|
||||
---
|
||||
title: "Pinniped v0.9.0: Bring your LDAP Identities to your Kubernetes Clusters"
|
||||
slug: bringing-ldap-identities-to-clusters
|
||||
date: 2021-05-26
|
||||
author: Ryan Richard
|
||||
image: https://cdn.pixabay.com/photo/2018/08/05/15/06/seal-3585727_1280.jpg
|
||||
excerpt: "With the release of v0.9.0, Pinniped now supports using LDAP identities to log in to Kubernetes clusters."
|
||||
tags: ['Ryan Richard', 'release']
|
||||
---
|
||||
|
||||
|
||||
*Photo from [matos11 on Pixabay](https://pixabay.com/photos/seal-animal-water-hairy-3585727/)*
|
||||
|
||||
Pinniped is a “batteries included” authentication system for Kubernetes clusters.
|
||||
With the release of v0.9.0, Pinniped now supports using LDAP identities to log in to Kubernetes clusters.
|
||||
|
||||
This post describes how v0.9.0 fits into Pinniped’s quest to bring a smooth, unified login experience to all Kubernetes clusters.
|
||||
|
||||
## Support for LDAP Identities in the Pinniped Supervisor
|
||||
|
||||
Pinniped is made up of two main components:
|
||||
- The Pinniped [_Concierge_]({{< ref "docs/howto/install-concierge.md" >}}) component implements cluster-level authentication.
|
||||
- The Pinniped [_Supervisor_]({{< ref "docs/howto/install-supervisor.md" >}}) component implements authentication federation
|
||||
across lots of clusters, which each run the Concierge, and makes it easy to bring your own identities using any OIDC or LDAP provider.
|
||||
|
||||
The new LDAP support lives in the Supervisor component.
|
||||
|
||||
### Why LDAP? And why now?
|
||||
|
||||
From the start, the Pinniped Supervisor has supported getting your identities from OIDC Providers. This was a strategic
|
||||
decision for the project, and was made for three reasons:
|
||||
|
||||
1. OIDC is an established standard with good security properties
|
||||
2. Many modern identity systems commonly used by enterprises implement OIDC, making it immediately useful for many Pinniped users
|
||||
3. Other open source projects, such as [Dex](https://dexidp.io) and [UAA](https://github.com/cloudfoundry/uaa),
|
||||
can act as a shim between OIDC and many other identity systems, and can provide a bridge between Pinniped and LDAP
|
||||
|
||||
This strategy has served us well for the initial launch of Pinniped to make it maximally useful for a minimal amount of code.
|
||||
|
||||
Although LDAP is a legacy identity protocol, and it is likely that nobody loves LDAP, the reality seems to be that a lot of enterprises keep using it anyway.
|
||||
Luckily, these other technologies could bridge LDAP into earlier versions of Pinniped for us.
|
||||
|
||||
At this point you may be asking yourself: since other systems can be used as a shim between Pinniped and an LDAP provider,
|
||||
then why would Pinniped ever need to provide direct support for LDAP providers? Good question. One of our goals is to make Kubernetes
|
||||
authentication as flexible and easy to use as possible. While Dex and UAA are excellent and feature-rich projects, they
|
||||
are not necessarily easy to configure. Also their deployment, initial configuration, and day-two reconfiguration are not necessarily
|
||||
accomplished in a Kubernetes-native style using K8s APIs.
|
||||
|
||||
We felt it was worth the effort of building native LDAP support in order to reduce the number of moving parts in your
|
||||
authentication system and to simplify the configuration of integrating your LDAP identity providers with Pinniped.
|
||||
Although we contemplated including this feature from the beginning, we waited until we had other higher priority
|
||||
features in place before prioritizing this effort.
|
||||
|
||||
### What about Active Directory's LDAP?
|
||||
|
||||
This release includes support for generic LDAP providers. When configured correctly for your provider,
|
||||
it should work with any LDAP provider.
|
||||
|
||||
We recognize that legacy Active Directory systems are probably one of the most popular LDAP providers.
|
||||
|
||||
However, for this first release we have not specifically tested with Microsoft Active Directory.
|
||||
Our generic LDAP implementation should work with Active Directory too.
|
||||
We intended to add features in future releases to make it more convenient to integrate with Microsoft Active Directory
|
||||
as an LDAP provider, and to include AD in our automated testing suite. Stay tuned.
|
||||
|
||||
In the meantime, please let us know if you run into any issues or concerns using your LDAP system.
|
||||
Feel free to ask questions via [#pinniped](https://kubernetes.slack.com/archives/C01BW364RJA) on Kubernetes Slack,
|
||||
or [create an issue](https://github.com/vmware-tanzu/pinniped/issues/new/choose) on our Github repository.
|
||||
|
||||
### Security Considerations
|
||||
|
||||
LDAP is inherently less secure than OIDC in one important way. In an OIDC login flow, your account credentials are only
|
||||
handled by your web browser, which you generally trust, and by the OIDC provider itself. The Pinniped CLI and Pinniped
|
||||
server-side components never handle your credentials. Unfortunately, LDAP does not work that way. LDAP authentication
|
||||
requires that the client send the user's password on behalf of the user. This means that the Pinniped CLI and the
|
||||
Pinniped Supervisor both see your LDAP password. If you have the choice between using an OIDC provider or an LDAP
|
||||
provider as your source of identity, then you might want to lean toward the OIDC provider for this reason.
|
||||
|
||||
We've taken care to always use TLS encrypted communication channels
|
||||
between the CLI and the Supervisor and between the Supervisor and the LDAP provider. We've also taken care to never
|
||||
log your password or write it to any storage. The Supervisor is already a privileged component in your chain of trust
|
||||
in the sense that if it were compromised by a bad actor, all of your clusters which are trusting it to provide authentication
|
||||
would therefore also become vulnerable to intrusion. While in an ideal world we would prefer that no components handled
|
||||
your LDAP password, at least the credential is only handled by components which are already assumed to be trusted.
|
||||
|
||||
Other clusters running the Concierge will never see your LDAP password. The Supervisor authenticates your users with
|
||||
the LDAP provider, and then the Supervisor issues unique, short-lived, per-cluster tokens. These are the only credentials
|
||||
transmitted to the clusters running the Concierge for authentication. Each token is only accepted by its target cluster,
|
||||
so a token somehow stolen from one cluster has no value on other clusters. This limits the impact of a compromise on one
|
||||
of those clusters.
|
||||
|
||||
You might notice that we have not implemented an API to configure LDAP as an identity provider directly in the Concierge
|
||||
component, without requiring use of the Supervisor component. We may add this in the future, although it would be less secure
|
||||
for the reasons described above. The reason that we would consider adding it would be for use cases where you are configuring
|
||||
authentication only for one or a very small number of clusters, and you don't feel like incurring the overhead of running
|
||||
a Supervisor such as configuring ingress, TLS certs, and usually a DNS entry. (Interested in having this feature? Reach out and
|
||||
let us know!) Having the Concierge directly talk to the LDAP provider would imply that users would be handing their LDAP
|
||||
passwords directly to the Concierge. If a bad actor were able to compromise that cluster as an admin-level user, then
|
||||
they might interfere with the Concierge software on that cluster to find a way to see your password. Once they have your
|
||||
password they could access other clusters, and even other unrelated systems which are also using LDAP authentication.
|
||||
As a design consideration in Pinniped, we generally consider clusters to be untrustworthy to reduce the impact of a successful
|
||||
attack on a cluster.
|
||||
|
||||
As an aside, this is a good time to remind you that whether you use OIDC or LDAP identity providers, it is important to
|
||||
keep the Supervisor secure. We recommend running the Supervisor on a separate cluster, or a cluster that you use to only run other
|
||||
similar security-sensitive components, which is appropriately secured and accessible to the fewest number of users as possible.
|
||||
It is also important to ensure that your users are installing the authentic versions of the `kubectl` and `pinniped` CLI tools.
|
||||
And it is important that your users are using authentic kubeconfig files handed out by a trusted source.
|
||||
|
||||
### How to use LDAP with your Pinniped Supervisor
|
||||
|
||||
Once you have [installed]({{< ref "docs/howto/install-supervisor.md" >}})
|
||||
and [configured]({{< ref "docs/howto/configure-supervisor.md" >}}) the Supervisor, adding an LDAP provider is as easy as creating
|
||||
an [LDAPIdentityProvider](https://github.com/vmware-tanzu/pinniped/blob/main/generated/1.20/README.adoc#ldapidentityprovider) resource.
|
||||
|
||||
We've provided examples of using [OpenLDAP]({{< ref "docs/howto/install-supervisor.md" >}})
|
||||
and [JumpCloud]({{< ref "docs/howto/install-supervisor.md" >}}) as LDAP providers.
|
||||
Stay tuned for examples of using Active Directory.
|
||||
|
||||
### What about SAML?
|
||||
|
||||
Now that we support OIDC and LDAP identity providers, the obvious next question is whether we should also support the third
|
||||
big enterprise authentication protocol: SAML.
|
||||
|
||||
We are currently undecided about the value of offering direct support for SAML. The protocol is complex and
|
||||
[difficult to implement without mistakes or vulnerabilities in dependencies](https://github.com/dexidp/dex/discussions/1884).
|
||||
Additionally, SAML seems to be waning in popularity in favor of OIDC, which provides a similar end-user experience.
|
||||
|
||||
What do you think? Do you still use SAML in your enterprise?
|
||||
Do you need SAML for authentication into your Kubernetes clusters? Let us know!
|
||||
|
||||
### We'd love to hear from you!
|
||||
|
||||
We thrive on community feedback. Did you try our new LDAP features?
|
||||
What else do you need from identity systems for your Kubernetes clusters?
|
||||
|
||||
Find us in [#pinniped](https://kubernetes.slack.com/archives/C01BW364RJA) on Kubernetes Slack,
|
||||
[create an issue](https://github.com/vmware-tanzu/pinniped/issues/new/choose) on our Github repository,
|
||||
or start a [Discussion](https://github.com/vmware-tanzu/pinniped/discussions).
|
||||
|
||||
Thanks for reading our announcement!
|
||||
Loading…
Reference in New Issue
Block a user