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 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>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/