starred/lldap-lldap

Fork 0

mirror of https://github.com/lldap/lldap.git synced 2026-04-25 16:25:55 +03:00

[GH-ISSUE #504] Allow setting the `key_file` value as an env var #186

New issue

Closed

opened 2026-02-27 08:15:45 +03:00 by kerem · 12 comments

kerem commented

2026-02-27 08:15:45 +03:00

Owner

Originally created by @onedr0p on GitHub (Mar 27, 2023).
Original GitHub issue: https://github.com/lldap/lldap/issues/504

This is a continuation of a discussion in https://github.com/nitnelave/lldap/issues/502

There's two point that could be covered here, ideally number 2 makes the most sense to me.

In order to simplify running lldap in high availability...

The user can run lldap and obtain the contents of the key_file which would allow them to set this via env, or
Remove the logic for generating a private key and allow the user to create and set the key_file value in the env or config file.

Originally created by @onedr0p on GitHub (Mar 27, 2023). Original GitHub issue: https://github.com/lldap/lldap/issues/504 This is a continuation of a discussion in https://github.com/nitnelave/lldap/issues/502 There's two point that could be covered here, ideally number 2 makes the most sense to me. In order to simplify running lldap in high availability... 1. The user can run lldap and obtain the contents of the `key_file` which would allow them to set this via env, or 2. Remove the logic for generating a private key and allow the user to create and set the `key_file` value in the env or config file.

kerem

2026-02-27 08:15:45 +03:00

closed this issue
added the
enhancement

backend
labels

kerem commented

2026-02-27 08:15:45 +03:00

Author

Owner

@miberecz commented on GitHub (Apr 11, 2023):

I'm just facing the exact same issue as @onedr0p in the mentioned ticket.
I'm trying to create a Kubernetes deployment without any persistent storage, so make it truly stateless by providing every configuration by environment variables or secrets, so it can be scaled to multiple replicas on demand.
I just found out that the private_key needs to be created by the lldap server itself.

I realize the scope of this project is to provide a very simple LDAP solution for mainly selfhosters, so make it as simple as possible, but I strongly support the second solution previously mentioned.
If a JWT sercet can be a simple variable in the config, private_key should be also.

@miberecz commented on GitHub (Apr 11, 2023): I'm just facing the exact same issue as @onedr0p in the mentioned ticket. I'm trying to create a Kubernetes deployment without any persistent storage, so make it truly stateless by providing every configuration by environment variables or secrets, so it can be scaled to multiple replicas on demand. I just found out that the private_key needs to be created by the lldap server itself. I realize the scope of this project is to provide a very simple LDAP solution for mainly selfhosters, so make it as simple as possible, but I strongly support the second solution previously mentioned. If a JWT sercet can be a simple variable in the config, private_key should be also.

kerem commented

2026-02-27 08:15:45 +03:00

Author

Owner

@nitnelave commented on GitHub (Apr 11, 2023):

As I explained in the linked discussion, the contents of the key file have to be generated by LLDAP, they're not just random bytes like the JWT key. So anyway you'll have to run LLDAP at least once to generate the key (which you could conceivably then pass by environment variable).

Actually, now that I think about it, I wonder if there is a way to use a seeded RNG to re-generate the key file every time? That would allow an easy external secret generation, with a consistent (as long as we use the same code) generated key.

@nitnelave commented on GitHub (Apr 11, 2023): As I explained in the linked discussion, the contents of the key file _have_ to be generated by LLDAP, they're not just random bytes like the JWT key. So anyway you'll have to run LLDAP at least once to generate the key (which you could conceivably then pass by environment variable). Actually, now that I think about it, I wonder if there is a way to use a seeded RNG to re-generate the key file every time? That would allow an easy external secret generation, with a consistent (as long as we use the same code) generated key.

kerem commented

2026-02-27 08:15:45 +03:00

Author

Owner

@miberecz commented on GitHub (Apr 11, 2023):

Okay, I get it.
In this case one could implement an initContainer which runs before the Lldap server starts. Creates the private_key which can be mounted in the actual container running the server.
Only if there would be a command like lldap create-key

About the seeded RNG you mention. I'm not sure about the math behind the crypto stuff, but if there would be a fixed value, and with that value always the same key is generated, then we could just use that as a config parameter, and the key still be created by the server.

@miberecz commented on GitHub (Apr 11, 2023): Okay, I get it. In this case one could implement an [initContainer](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) which runs before the Lldap server starts. Creates the private_key which can be mounted in the actual container running the server. Only if there would be a command like `lldap create-key` About the seeded RNG you mention. I'm not sure about the math behind the crypto stuff, but if there would be a fixed value, and with that value always the same key is generated, then we could just use that as a config parameter, and the key still be created by the server.

kerem commented

2026-02-27 08:15:45 +03:00

Author

Owner

@onedr0p commented on GitHub (Apr 11, 2023):

I've thought about the create key command and using an initContainer but it's still not great. That command would need to be idempotent to not regenerate the key or more glue needed to make it work that way.

I'd rather effort be put into making it so lldap can be 100% env driven. I'm going to continue using glauth over lldap until this is accomplished. I'm really looking forward to using lldap one day.

@onedr0p commented on GitHub (Apr 11, 2023): I've thought about the create key command and using an `initContainer` but it's still not great. That command would need to be idempotent to not regenerate the key or more glue needed to make it work that way. I'd rather effort be put into making it so lldap can be 100% env driven. I'm going to continue using glauth over lldap until this is accomplished. I'm really looking forward to using lldap one day.

kerem commented

2026-02-27 08:15:45 +03:00

Author

Owner

@nitnelave commented on GitHub (Apr 13, 2023):

See https://github.com/lldap/lldap/pull/549, you can now set a key_seed (or LLDAP_SERVER_KEY_SEED) to generate the private key from a stable seed. Note that the private key generated is not going to be the same as the existing server_key file that you had previously, so all the passwords will have to be reset.

@nitnelave commented on GitHub (Apr 13, 2023): See https://github.com/lldap/lldap/pull/549, you can now set a `key_seed` (or `LLDAP_SERVER_KEY_SEED`) to generate the private key from a stable seed. Note that the private key generated is _not_ going to be the same as the existing `server_key` file that you had previously, so all the passwords will have to be reset.

kerem commented

2026-02-27 08:15:45 +03:00

Author

Owner

@miberecz commented on GitHub (Apr 13, 2023):

I have tested it, and works like a charm so far.
Only minor problem I noticed, that the value of the key_seed is not censored in the logs at startup.

@miberecz commented on GitHub (Apr 13, 2023): I have tested it, and works like a charm so far. Only minor problem I noticed, that the value of the `key_seed ` is not censored in the logs at startup.

kerem commented

2026-02-27 08:15:45 +03:00

Author

Owner

@onedr0p commented on GitHub (Apr 13, 2023):

I'm going to test this out today too, thanks @nitnelave

@onedr0p commented on GitHub (Apr 13, 2023): I'm going to test this out today too, thanks @nitnelave

kerem commented

2026-02-27 08:15:45 +03:00

Author

Owner

@onedr0p commented on GitHub (Apr 13, 2023):

I have deploy this in my kubernetes cluster and it is working with the following config (I use Flux):

https://github.com/onedr0p/home-ops/tree/main/kubernetes/apps/default/lldap/app

My only question would be is the data directory needed? I have it set to emptyDir now.

@onedr0p commented on GitHub (Apr 13, 2023): I have deploy this in my kubernetes cluster and it is working with the following config (I use Flux): https://github.com/onedr0p/home-ops/tree/main/kubernetes/apps/default/lldap/app My only question would be is the data directory needed? I have it set to emptyDir now.

kerem commented

2026-02-27 08:15:45 +03:00

Author

Owner

@miberecz commented on GitHub (Apr 13, 2023):

I do not mount any persistent data directory, only the lldap_config.toml as a configMap.

@miberecz commented on GitHub (Apr 13, 2023): I do not mount any persistent data directory, only the lldap_config.toml as a configMap.

kerem commented

2026-02-27 08:15:46 +03:00

Author

Owner

@onedr0p commented on GitHub (Apr 13, 2023):

Any reason you need to include that file? It looks like everything is able to be set via env now.

@onedr0p commented on GitHub (Apr 13, 2023): Any reason you need to include that file? It looks like everything is able to be set via env now.

kerem commented

2026-02-27 08:15:46 +03:00

Author

Owner

@miberecz commented on GitHub (Apr 13, 2023):

Any reason you need to include that file? It looks like everything is able to be set via env now.

Simply personal preference. I like to keep configuration in a separate file.

@miberecz commented on GitHub (Apr 13, 2023): > Any reason you need to include that file? It looks like everything is able to be set via env now. Simply personal preference. I like to keep configuration in a separate file.

kerem commented

2026-02-27 08:15:46 +03:00

Author

Owner

@nitnelave commented on GitHub (Apr 13, 2023):

@miberecz I'm making the key_seed a secret here: https://github.com/lldap/lldap/pull/554
We'll still know whether there is a key_seed, but not what it contains.

@nitnelave commented on GitHub (Apr 13, 2023): @miberecz I'm making the key_seed a secret here: https://github.com/lldap/lldap/pull/554 We'll still know _whether_ there is a `key_seed`, but not what it contains.

kerem referenced this issue

2026-02-27 08:18:08 +03:00

[PR #186] [MERGED] docs: add Grafana config #599