OpenLDAP Helm chart for devs

April 14, 2020 3-minute read
Kubernetes • OpenLDAP • Helm

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).

Docker image

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 /ldif.

Also, it installs two overlay plugins I like: memberOf and 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 slapcat-style backup cronjob.

Docker Desktop ❤️ Kubernetes

This is the part I enjoy the most. Taking advantage of the Docker Desktop and its relatively new Kubernetes add-on.

docker desktop kub

I just had to customize the StorageClass in the values.yaml file like so:

persistence:
  enabled: true
  storageClass: "hostpath"
  accessMode: ReadWriteOnce
  size: "64Mi"

And voilà!

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! :)