Rationales for using OpenLDAP - or when the Dinosaur meets Terminator!
I am fairly experienced with OAuth and OIDC. But when it’s about Access Management, the OAuth 2.0 framework is just one piece of the cake.
In the project I’m working for, the platform has strong portability requirements. It should be deployable in multiple IT departments and thereby multiple security domains.
In this regard, I need to have hands on the group management, so that I can dynamically map users to groups upon custom criteria. So, the group management part must be agnostic of all of the Identity Provider the platform connects to.
When it comes to user and group storage, my sys-admin soul can’t see a better solution than OpenLDAP. This software has been production proofed for decades and never caused me any major trouble.
Moreover, most of open-source solutions that I categorize as "authorization brokers", like Gravitee Access Management, Keycloak or Dex come with LDAP connectors.
So, in one hand the user/group mapping is handled by a custom API on top of my OpenLDAP instance and, in the other hand, the role management is handled by the authorization broker (Gravitee Access Management in this case).
The point is that among all Helm chart I’ve met for this software, most of them are doing way too much.
Really, I could not imagine deploying any of them, because of - for instance - the base image weight (ubuntu or debian) or the complexity of bash scripts coming along (or in the underlying docker images). Plus some of them look to support LDAP replication but they are not using STatefulSets! 😧
Anyway, I wanted to build mine, lightweight and easy to work with (mostly for dev purpose).
Nothing magic here. I simply installed the OpenLDAP package on top on alpine.
The entrypoint is left as is and simply runs a startup shell script.
This script updates the
rootdn (~admin) password and then loads LDIF data present under
Also, it installs two overlay plugins I like:
refint. That helps you to keep consistency between users and groups.
Access control is strict: only service-account can write data.
For dev environment, the
Makefile makes things easy. Just run the following commands to start a local instance, with a persistent docker volume, and to watch logs.
make run make logs
You will find the source code here: https://github.com/bcollard/simple-openldap-docker
Packaging with Helm
This was pretty straightforward. First basic step was to create the chart skeleton:
helm create simple-openldap-helm-chart
Then, I’ve added a persistent volume for keeping your work safe between restarts. And, of course, a service for exposing the default port 389.
You will find the source code here: https://github.com/bcollard/simple-openldap-helm-chart
Be careful if you want to deploy this chart to production! You should, at least, add some data replication (+client certs, move from deploy to sts), add a server certificate (change port from LDAP to LDAPS) and prepare a
Docker Desktop ❤️ Kubernetes
This is the part I enjoy the most. Taking advantage of the Docker Desktop and its relatively new Kubernetes add-on.
I just had to customize the StorageClass in the
values.yaml file like so:
persistence: enabled: true storageClass: "hostpath" accessMode: ReadWriteOnce size: "64Mi"
The default provisioner named
hostpath does the job and generates a PV matching you claim.
$> helm install openldap-blog . ... $> k get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE openldap-blog-simple-openldap-helm-chart Bound pvc-8cde300b-05dd-4093-9eed-a80621b0ae06 64Mi RWO hostpath 15s
I love it! :)