[Feature Request] Trigger ldap config / search password reload (or periodically reload)

[con-f-use]

We rotate passwords for our LDAP service users. It would be nice, if at least the search password, if not the whole ldap-config could be reloaded without restarting the whole service. The reload might either be triggered (e.g. sending the HUP-signal, or any other signal, to the devpi server) or simply done periodically. LDAP config / search password seems to change more often, than the service itself is re-deployed.

(Edited for clarification)

[fschulze]

I don't understand how rotating passwords is a problem. Each login re-validates the password via LDAP which creates a token that is valid for 10 hours.

Rotating passwords is an old recommendation that turned out to be a bad idea in regard to password security, as it causes users to choose simple passwords with only slight predictable changes.

Reloading the config could be possible, but I don't see a use case for that, as the configuration should be pretty static most of the time. Could you elaborate on why you would need that?

[con-f-use]

The rotation for service user accounts is done automatically and chooses sufficiently complex and random passwords.

While not recommended for humans, it is the more secure practice for services.

And sorry, I wasn't sufficiently clear. I'm talking about the LDAP search password. i.e.

---
devpi-ldap:
  url: ldaps://ldap.myorg.com:636
  user_search:
    userdn: SERVICE-LDAP@ad.myorg.com
    password: password1234insecure    <----------- this one
    base: DC=EU,DC=AD,DC=MYORG,DC=COM
    filter: (&(objectClass=user)(userPrincipalName={username}))
    attribute_name: distinguishedName

[fschulze]

That is fine then. I still don't understand what the problem on the devpi-server side is then. The passwords are in LDAP and are validated each time. There is no caching or anything like that.

[fschulze]

And sorry, I wasn't sufficiently clear. I'm talking about the LDAP search password.

Ahhh, that makes sense then.

[con-f-use]

Yeah sorry, that key piece of info stayed in my head, but that's not a place for the outside world :grin:

[fschulze]

I have to think about that. It would be better if that wasn't in the config at all. How do you solve that for other services? Would using the keyring package work for you? Or should the password be read from another file or from the environment? I'm not too deep into that stuff, but passwords in configuration generally bother me and I haven't seen a good general solution yet. There are some "vault" thingies, but they seem to be too complex for simple use cases.

[con-f-use]

I absolutely agree, it should not be in the config, because you want to be able to commit config without (accedentally) committing secrets. The keyring package, on the other hand, can be a pain to use in some applications. I'm most happy when it's just a configurable file path. That will be most compatible and can work with almost any secret management system. Hashicorp Vault (Agent) can do file templating, systemd-credentials can provide a file, docker-secrets too, kubernetes vault, dito ansible vault, etc. I don't think there's a more complex "industry standard" solution that everybody can agree on and use.

So my vote would be to introduce a new password_file keyword:

---
devpi-ldap:
  url: ldaps://ldap.myorg.com:636
  user_search:
    userdn: SERVICE-LDAP@ad.myorg.com
    password_file: /some/arbitrary/path/to/a/password.txt  <----------- this
    base: DC=EU,DC=AD,DC=MYORG,DC=COM
    filter: (&(objectClass=user)(userPrincipalName={username}))
    attribute_name: distinguishedName

and then, if you wanted to be extra accommodating have a corresponding environment variable and command-line option, while gradually deprecating the old plain text password option.