David Arnold wrote:
Hello,
I'm using SPIRE/SPIFFE for workload attestation and authC, work brilliant in combination with the spiffe-helper. The spiffe helper communicates with the workload attestation API over a linux socket and provides and rotates the certificates, and then starts the actual daemon process (slapd in our case).
Every 5 minutes certificates are rotated and the helper proactively requests new certs at 80% of TTL. It goes on to provision the newly supplied certs and then signals the daemon process to reload (config-reload, certs-reload, restart, whatever) through a configurable singal (eg. SIGHUP).
An alternative is to run the daemon independently and run the helper as a sidecar process which then communicates with the daemon process through other means (unix socket, TCP socket) to communicate the need for configuration reload.
I - think - I understood that slapd does not have a SIGNAL API by which I can tell it to reload certificates (or subsidiarily configuration). Neither did I find a signal which causes slapd to restart, which still would be acceptable.
Hece I figure, my only option is to deploy the helper as a sidecar process and have it cause the slapd daemon to reload its config over the ldap protocol. For postgres, such thing is achieved similarily for exmample by the query "SELECT pg_reload_config();".
What are my options in ldap - given that slapd.conf is used by the underlying system, unfortunately not dn=config (olc)?
Use cn=config anyway. Even if slapd is started with slapd.conf, the cn=config database exists. But since you're using a .conf file, any modifications you do on cn=config are in-memory only, and won't be saved to disk. This doesn't matter in your case since you're making ephemeral changes anyway.
So: make sure you have credentials for accessing cn=config, and just use ldapmodify to change the olcTLS* attributes as needed.
Thank you in advance for your help!
Best Regards, David Arnold