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)?
Thank you in advance for your help!
Best Regards, David Arnold
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
Even if slapd is started with slapd.conf, the cn=config database exists.
Thanks, didn't know that!
So: make sure you have credentials for accessing cn=config, and just use ldapmodify to change the olcTLS* attributes as needed.
Since the paths don't actually change (and I have no means to make them change), can I do a dummy modification that would trigger cert reloading?
--On Friday, August 21, 2020 2:56 PM -0500 David Arnold dar@xoe.solutions wrote:
Since the paths don't actually change (and I have no means to make them change), can I do a dummy modification that would trigger cert reloading?
Yeah, just do a replace op, like:
ldapmodify ... dn: cn=config changetype: modify replace: olcTLS.. olcTLS...: original value
For the slapd.conf configuration to enable the cn=config db just have:
database config rootpw somepassword
and then you can bind to it w/ that password. Alternatively, you can set up an authz-regexp, etc.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Cool, I'm getting there! Unfortunately and for good reasons the creator of ae-dir.com has restricted modifying access for config (in order to tightly control runtime config state).
So this is how far as I get: ``` [nix-shell] ➜ aedir-ldap.k8s git:(da-openldap-base) ✗ just mprovider SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn: cn=config changetype: modify replace: olcTLSCertificateFile olcTLSCertificateFile: /var/run/certs/svid.pem - replace: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /var/run/certs/svid_key.pem
modifying entry "cn=config" ldap_modify: Server is unwilling to perform (53) additional info: operation restricted
command terminated with exit code 53 error: Recipe `mprovider` failed with exit code 5 ```
Furthermore, would this dummy change also reload the certificates that are configured for the syncrepls? See:
``` dn: olcDatabase={2}mdb,cn=config olcSyncrepl: rid=001 provider=ldaps://aedir-0.aedir.aedir-provider.svc.cluster .local bindmethod=sasl timeout=5 network-timeout=5 saslmech=EXTERNAL keepaliv e=240:10:30 starttls=no tls_cert="/var/run/certs/svid.pem" tls_key="/var/run/ certs/svid_key.pem" tls_cacert="/var/run/certs/svid_bundle.pem" tls_reqcert=d emand tls_cipher_suite=ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384: ECDH-RSA-AES256-GCM-SHA384:!ADH tls_protocol_min=3.3 tls_crlcheck=none filter ="(objectClass=*)" searchbase="ou=ae-dir" scope=sub attrs="*,+" schemacheckin g=on type=refreshAndPersist retry="30 +" ```
I'm starting to think plain process signalling for reloading the TLS context would actually be a cleaner, more elegant and stable solution. Would you be ok if I opened an issue for that?
On Fri, Aug 21, 2020 at 12:00, Quanah Gibson-Mount quanah@symas.com wrote:
--On Friday, August 21, 2020 2:56 PM -0500 David Arnold <dar@xoe.solutions mailto:dar@xoe.solutions> wrote:
Since the paths don't actually change (and I have no means to make them change), can I do a dummy modification that would trigger cert reloading?
Yeah, just do a replace op, like:
ldapmodify ... dn: cn=config changetype: modify replace: olcTLS.. olcTLS...: original value
For the slapd.conf configuration to enable the cn=config db just have:
database config rootpw somepassword
and then you can bind to it w/ that password. Alternatively, you can set up an authz-regexp, etc.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com http://www.symas.com/>
--On Friday, August 21, 2020 5:53 PM -0500 David Arnold dar@xoe.solutions wrote:
Cool, I'm getting there! Unfortunately and for good reasons the creator of ae-dir.com has restricted modifying access for config (in order to tightly control runtime config state).
SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
Did you actually add an authz-regexp to your config that maps this DN to the cn=config rootdn? Otherwise I'd expect it to fail. Not sure this is really an AEDir thing.
Furthermore, would this dummy change also reload the certificates that are configured for the syncrepls?
No, you'd need to do a replace op on the olcSyncrepl attribute for that database as well.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Did you actually add an authz-regexp to your config that maps this DN to the cn=config rootdn? Otherwise I'd expect it to fail. Not sure this is really an AEDir thing.
Yep, double checked. globally, I'm impersonating root:
``` # Map root user to rootdn when SASL/EXTERNAL is used with LDAPI authz-regexp "gidnumber=0\+uidnumber=0,cn=peercred,cn=external,cn=auth" "cn=root,ou=ae-dir" ```
and config is really put readonly
``` database config
require strong
# yes, really read-only! readonly on restrict write
access to dn.subtree="cn=config" attrs=entry,objectClass,olcServerID,olcSaslHost by dn.onelevel="cn=ae,ou=ae-dir" read by group/aeGroup/member="cn=ae-login-proxies,cn=ae,ou=ae-dir" read by * none break
access to dn.subtree="cn=config" by dn.exact="cn=root,ou=ae-dir" read by group/aeGroup/member="cn=ae-admins,cn=ae,ou=ae-dir" read by group/aeGroup/member="cn=ae-auditors,cn=ae,ou=ae-dir" read by * none ```
Since I'm probably going to write a controller which joins syncrepls one the fly anyways, I need to deviate from this.
However, for realoding rolled certs this is a bit unfortunante. Alternatively, would it be possible rather than using a SIGNAL to gracefully fall back to reload the TLS context once if the current certs appear expired?
I predict I'm not gonna be the last person with this issue...
Best Regards, David A.
On Fri, Aug 21, 2020 at 15:36, Quanah Gibson-Mount quanah@symas.com wrote:
--On Friday, August 21, 2020 5:53 PM -0500 David Arnold <dar@xoe.solutions mailto:dar@xoe.solutions> wrote:
Cool, I'm getting there! Unfortunately and for good reasons the creator of ae-dir.com has restricted modifying access for config (in order to tightly control runtime config state).
SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
Did you actually add an authz-regexp to your config that maps this DN to the cn=config rootdn? Otherwise I'd expect it to fail. Not sure this is really an AEDir thing.
Furthermore, would this dummy change also reload the certificates that are configured for the syncrepls?
No, you'd need to do a replace op on the olcSyncrepl attribute for that database as well.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com http://www.symas.com/>
--On Friday, August 21, 2020 8:47 PM -0500 David Arnold dar@xoe.solutions wrote:
# yes, really read-only! readonly on restrict write
That's... really really dumb. It should absolutely be possible to tweak things in the cn=config db.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On Fri, Aug 21, 2020 at 19:52, Quanah Gibson-Mount quanah@symas.com wrote:
That's... really really dumb. It should absolutely be possible to tweak things in the cn=config db.
Yeah, I kind of agree. However there is one valid use case: config is put under gitops and operators want to make sure nobody can modify at runtime. Trying to apply gitops principles I'm struggling with software that is dynamically configured - worst case via the UI - all the time.
--On Saturday, August 22, 2020 12:05 AM -0500 David Arnold dar@xoe.solutions wrote:
Yeah, I kind of agree. However there is one valid use case: config is put under gitops and operators want to make sure nobody can modify at runtime.
The whole idea is that you can modify it so you can do really useful things like change the logging level on the fly w/o having to stop and start the service. If gitops means preventing people from being able to gather useful information from a running process, I'd definitely avoid it.
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On 8/22/20 4:52 AM, Quanah Gibson-Mount wrote:
--On Friday, August 21, 2020 8:47 PM -0500 David Arnold dar@xoe.solutions wrote:
# yes, really read-only! readonly on restrict write
That's... really really dumb. It should absolutely be possible to tweak things in the cn=config db.
For Æ-DIR I deliberately chose ansible as authorative config management which generates static site-specific slapd.conf for all the replicas. (I don't want to start yet another fight about the pros and cons here. Raise your questions off-list why I'm doing this.)
In this case it would be really really dumb to allow direct altering of cn=config and would cause lots of trouble for the average sysadmin. cn=config is provided read-only for the monitoring check.
David is using Æ-DIR in a non-supported container setup experimenting with a PKI issuing short-term certs. While it's somewhat interesting what will come out of these experiments I have to emphasize that it's far from standard Æ-DIR operation.
Ciao, Michael.
David Arnold wrote:
However, for realoding rolled certs this is a bit unfortunante. Alternatively, would it be possible rather than using a SIGNAL to gracefully fall back to reload the TLS context once if the current certs appear expired?
I predict I'm not gonna be the last person with this issue...
I suggest writing an overlay for this, whose only function is to schedule a periodic task that does all of the refreshing you want to have happen.
Best Regards, David A.
On Fri, Aug 21, 2020 at 15:36, Quanah Gibson-Mount quanah@symas.com wrote:
--On Friday, August 21, 2020 5:53 PM -0500 David Arnold <dar@xoe.solutions mailto:dar@xoe.solutions> wrote:
Cool, I'm getting there! Unfortunately and for good reasons the creator of ae-dir.com has restricted modifying access for config (in order to tightly control runtime config state). SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=authDid you actually add an authz-regexp to your config that maps this DN to the cn=config rootdn? Otherwise I'd expect it to fail. Not sure this is really an AEDir thing.
Furthermore, would this dummy change also reload the certificates that are configured for the syncrepls?No, you'd need to do a replace op on the olcSyncrepl attribute for that database as well. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
I can see how ramping up diagnosis capabilities on a running piece of software is an outstanding feature, that unfortunately not a lot programs have out there.
My mental model of gitops certainly doesn't aim at blocking diagnostic capabilities, it does however seek to keep critical knobs under a general, unified and well established approval and auditing process across the entire system components zoo.
I suggest writing an overlay for this, whose only function is to schedule
a periodic task that does all of the refreshing you want to have happen.
I understand why signalling is not considered a valid solution. In fact it's not the cleanest one. Given the security aware user base of OpenLDAP, I'd predic that a generic solution to certificate rolling will spark some interest.
Times where such a roll is done once in a few years are fading. In my case, the default with spiffe is every 5 minutes, but short lived certificates are a general trend in software.
Wouldn't we be able to conceive an acceptable patch that doesn't introduce (too much) runtime penalties which gracefully reloads TLS context on expiry exactly once?
Assuming that the proclaimed trend towards short lived certificates pervails, such patch adds value to OpenLDAP's user community as it - by default - lowers the barrier to adoption of more secure practices.
Best Regards, David A.
El sábado, 22 de agosto de 2020, Howard Chu hyc@symas.com escribió:
David Arnold wrote:
However, for realoding rolled certs this is a bit unfortunante.
Alternatively, would it be possible rather than using
a SIGNAL to gracefully fall back to reload the TLS context once if the
current certs appear expired?
I predict I'm not gonna be the last person with this issue...
I suggest writing an overlay for this, whose only function is to schedule a periodic task that does all of the refreshing you want to have happen.
Best Regards, David A.
On Fri, Aug 21, 2020 at 15:36, Quanah Gibson-Mount quanah@symas.com
wrote:
--On Friday, August 21, 2020 5:53 PM -0500 David Arnold
<dar@xoe.solutions mailto:dar@xoe.solutions> wrote:
Cool, I'm getting there! Unfortunately and for good reasons thecreator of ae-dir.com has restricted modifying access for config (in order to tightly
control runtime config state). SASL/EXTERNAL authentication started SASL username:gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
Did you actually add an authz-regexp to your config that maps this DN
to the cn=config rootdn? Otherwise I'd expect it to fail. Not sure this is really an
AEDir thing.
Furthermore, would this dummy change also reload the certificatesthat are configured for the syncrepls?
No, you'd need to do a replace op on the olcSyncrepl attribute for that
database as well. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas
Corporation Packaged, certified, and supported LDAP solutions powered
by OpenLDAP: http://www.symas.com
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
openldap-technical@openldap.org
-
David Arnold -
Howard Chu -
Michael Ströder -
Quanah Gibson-Mount