starred/lldap-lldap

Fork 0

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

[GH-ISSUE #1064] [FEATURE REQUEST] Separate env variable for password for external database #381

New issue

Closed

opened 2026-02-27 08:16:58 +03:00 by kerem · 9 comments

kerem commented

2026-02-27 08:16:58 +03:00

Owner

Originally created by @LonguCodes on GitHub (Dec 18, 2024).
Original GitHub issue: https://github.com/lldap/lldap/issues/1064

Motivation
I'm trying to securely deploy lldap to k8s. The database password is stored in a secret, managed by an operator. It cycles the password regularly and automatically updates the secret.

Describe the solution you'd like
Separate env variable, that will overwrite the password specified in url, either by env or configuration file.

Describe alternatives you've considered
I was thinking about creating the variable dynamically on container startup and writing it into the configuration file.
This would work, but it would still leave it in the file. Also, I wanted the to be from a configmap, which would mean that it would be read-only from inside of the container.

Originally created by @LonguCodes on GitHub (Dec 18, 2024). Original GitHub issue: https://github.com/lldap/lldap/issues/1064 **Motivation** I'm trying to securely deploy lldap to k8s. The database password is stored in a secret, managed by an operator. It cycles the password regularly and automatically updates the secret. **Describe the solution you'd like** Separate env variable, that will overwrite the password specified in url, either by env or configuration file. **Describe alternatives you've considered** I was thinking about creating the variable dynamically on container startup and writing it into the configuration file. This would work, but it would still leave it in the file. Also, I wanted the to be from a configmap, which would mean that it would be read-only from inside of the container.

kerem

2026-02-27 08:16:58 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-02-27 08:16:59 +03:00

Author

Owner

@LonguCodes commented on GitHub (Dec 19, 2024):

Turns out it's doable in k8s natively.
https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/#using-environment-variables-inside-of-your-config

The feature would still be nice, as this workaround is k8s-only.

@LonguCodes commented on GitHub (Dec 19, 2024): Turns out it's doable in k8s natively. https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/#using-environment-variables-inside-of-your-config The feature would still be nice, as this workaround is k8s-only.

kerem commented

2026-02-27 08:16:59 +03:00

Author

Owner

@nitnelave commented on GitHub (Dec 19, 2024):

I'm skeptical that this is a common use case, especially from non-k8s users.
If this gets requested again, I might reconsider, but especially since you have a perfectly valid workaround for your use case, I'm going to close this issue.

@nitnelave commented on GitHub (Dec 19, 2024): I'm skeptical that this is a common use case, especially from non-k8s users. If this gets requested again, I might reconsider, but especially since you have a perfectly valid workaround for your use case, I'm going to close this issue.

kerem commented

2026-02-27 08:16:59 +03:00

Author

Owner

@ametis70 commented on GitHub (Feb 25, 2025):

Hi @nitnelave, I'm facing a similar issue in other scenario: I'm trying to deploy a Docker Swarm stack with LLDAP and Postgres. I can pass the password as a secret to the Postgres container, but AFAIK I cannot build the connection URI for the DB without hardcoding it in plain text as an env var in the Docker Compose file or by writing it to the persisted LLDAP config file. I believe there should be multiple env vars in addition to LLDAP_DATABASE_URL (which should take precedence if set) to provide the ability to set the following items individually:

LLDAP_DATABASE_TYPE
LLDAP_DATABASE_PORT
LLDAP_DATABASE_DB
LLDAP_DATABASE_USER
LLDAP_DATABASE_PASSWORD

And the URI should be automatically built from that. It should be also possible to pass file paths to use the mounted secrets for the following items (to match Postgres):

LLDAP_DATABASE_DB_FILE
LLDAP_DATABASE_USER_FILE
LLDAP_DATABASE_PASSWORD_FILE

Or is there a way of reading the secret from the file to build the URI that I'm not aware of?

@ametis70 commented on GitHub (Feb 25, 2025): Hi @nitnelave, I'm facing a similar issue in other scenario: I'm trying to deploy a Docker Swarm stack with LLDAP and Postgres. I can pass the password as a secret to the Postgres container, but AFAIK I cannot build the connection URI for the DB without hardcoding it in plain text as an env var in the Docker Compose file or by writing it to the persisted LLDAP config file. I believe there should be multiple env vars in addition to `LLDAP_DATABASE_URL` (which should take precedence if set) to provide the ability to set the following items individually: - `LLDAP_DATABASE_TYPE` - `LLDAP_DATABASE_PORT` - `LLDAP_DATABASE_DB` - `LLDAP_DATABASE_USER` - `LLDAP_DATABASE_PASSWORD` And the URI should be automatically built from that. It should be also possible to pass file paths to use the mounted secrets for the following items (to match Postgres): - `LLDAP_DATABASE_DB_FILE` - `LLDAP_DATABASE_USER_FILE` - `LLDAP_DATABASE_PASSWORD_FILE` Or is there a way of reading the secret from the file to build the URI that I'm not aware of?

kerem commented

2026-02-27 08:16:59 +03:00

Author

Owner

@nitnelave commented on GitHub (Feb 25, 2025):

I'm not sure I follow, is LLDAP_DATABASE_URL_FILE an answer to your question?

There's currently no way to pass the DB password separately.

Do I understand correctly that your DB address is dynamic, can be set through the env, but the password is always the same and should be a secret?

@nitnelave commented on GitHub (Feb 25, 2025): I'm not sure I follow, is `LLDAP_DATABASE_URL_FILE` an answer to your question? There's currently no way to pass the DB password separately. Do I understand correctly that your DB address is dynamic, can be set through the env, but the password is always the same and should be a secret?

kerem commented

2026-02-27 08:16:59 +03:00

Author

Owner

@ametis70 commented on GitHub (Feb 26, 2025):

LLDAP_DATABASE_URL_FILE would also work, is that already supported? I did not see it in the docs.

In my case all the variables are static, they aren't likely to change but I need to pass the password (or the full connection URI) as a secret

@ametis70 commented on GitHub (Feb 26, 2025): `LLDAP_DATABASE_URL_FILE` would also work, is that already supported? I did not see it in the docs. In my case all the variables are static, they aren't likely to change but I need to pass the password (or the full connection URI) as a secret

kerem commented

2026-02-27 08:16:59 +03:00

Author

Owner

@nitnelave commented on GitHub (Feb 26, 2025):

Yes, every config value has a matching _FILE variant.

@nitnelave commented on GitHub (Feb 26, 2025): Yes, every config value has a matching _FILE variant.

kerem commented

2026-02-27 08:16:59 +03:00

Author

Owner

@nitnelave commented on GitHub (Feb 26, 2025):

I guess we call it out for the few secrets (which didn't include the DB url at the time), but it would make sense to also point it out at the top of the file. Do you want to send a PR adding something to that effect to the config template?

@nitnelave commented on GitHub (Feb 26, 2025): I guess we call it out for the few secrets (which didn't include the DB url at the time), but it would make sense to also point it out at the top of the file. Do you want to send a PR adding something to that effect to the config template?

kerem commented

2026-02-27 08:16:59 +03:00

Author

Owner

@ametis70 commented on GitHub (Feb 26, 2025):

Alright, I don't know why I didn't try it before commenting. I will open a PR later to add that to the docs. Thanks!

@ametis70 commented on GitHub (Feb 26, 2025): Alright, I don't know why I didn't try it before commenting. I will open a PR later to add that to the docs. Thanks!

kerem commented

2026-02-27 08:16:59 +03:00

Author

Owner

@mufasachan commented on GitHub (Apr 24, 2025):

Hello, I have another use case where env variables for each part might be interesting (not required though). First thing first, thanks for your works on LLDAP! I am looking forward to use the bootstrap.sh file and interface it with my other services. Plus, I am looking forward to see the webapp built with yew.

I just have a bunch of container services running on my server with Podman and its .container (Quadlet) files. The default for podman is to expose secret in file. In principle, it avoids to expose secrets in the environment of the child process. While the env variable LLDAP_DATABASE_URL_FILE exists, I think it might be convenient to have this in multiple parts.

For a workaround with multiple env variables, I could add some lines of script at the beginning of the container to create a file which has the correct value. Also, making a new secret for the database URL requires to build this secret on host from the secret of the postgres password. These ways of doing it are inconvenient and are error-prone in my opinion.

This features request is a quality of life improvement since workarounds exist, I cited 2 from my limited knowledge. Also, from what I understand from the LLDAP project, you emphasis accessible LDAP support, I think this configuration goes into this direction. LinuxServer propose this kind of features, and other applications such as Authelia also uses this kind of multiple environment variables setup.

I think this configuration might be a great addition for your project.

@mufasachan commented on GitHub (Apr 24, 2025): Hello, I have another use case where env variables for each part might be interesting (not required though). First thing first, thanks for your works on LLDAP! I am looking forward to use the `bootstrap.sh` file and interface it with my other services. Plus, I am looking forward to see the webapp built with yew. I just have a bunch of container services running on my server with Podman and its `.container` (Quadlet) files. The default for podman is to expose secret in file. In principle, it avoids to expose secrets in the environment of the child process. While the env variable `LLDAP_DATABASE_URL_FILE` exists, I think it might be convenient to have this in multiple parts. For a workaround with multiple env variables, I could add some lines of script at the beginning of the container to create a file which has the correct value. Also, making a new secret for the database URL requires to build this secret on host from the secret of the postgres password. These ways of doing it are inconvenient and are error-prone in my opinion. This features request is a quality of life improvement since workarounds exist, I cited 2 from my limited knowledge. Also, from what I understand from the LLDAP project, you emphasis accessible LDAP support, I think this configuration goes into this direction. [LinuxServer](https://www.linuxserver.io/our-images) propose this kind of features, and other applications such as [Authelia](https://www.authelia.com/integration/deployment/docker/) also uses this kind of multiple environment variables setup. I think this configuration might be a great addition for your project.

kerem referenced this issue

2026-02-27 09:09:27 +03:00

[PR #381] [MERGED] server: prefer immutable path #709