Config: Read passwords and secrets from files

[jandaa]

Is your feature request related to a problem? Please describe.

I would like to have a way to pass the admin password to Photoprism as a docker secret. The only way to set the password right now is to explicitly write out the password in the docker-compose file which is not very secure.

Describe the solution you'd like

Support passing secrets using the standard convention of passing in the secret to an environment variable with _FILE appended to it. It would look like this

photoprism:
    image: photoprism/photoprism:20220121
    secrets:
      - photoprism_admin_password
   ...
    environment:
      PHOTOPRISM_ADMIN_PASSWORD_FILE: /run/secrets/photoprism_admin_password

This can be done by modifying the entrypoint.sh file to check if its a secret or not and if it is, to cat the file to get its contents

Describe alternatives you've considered

Running from command line but this is not very maintainable or scalable.

Additional context

[mbelangergit]

I would love to see this request get traction too. Most (if not all) of the other containers I used are using the proposed _FILE ending or similar. PHOTOPRISM_DATABASE_USER and PHOTOPRISM_DATABASE_PASSWORD are also good candidates for this feature.

[StudioLE]

Instead of writing the passwords directly in the docker-compose.yml you can use a .env file:
https://docs.docker.com/compose/environment-variables/#the-env-file

It will still be loaded as an environment variable in the container but this way means you can safely commit the docker-compose.yml to version control while ignoring the .env

[lastzero]

Also, you can encrypt the password with blowfish. That way, you can't just read it. While that is not possible for MariaDB for the obvious reason, you can use an env file or apply the env value from the global environment without setting an explicit password in the docker-compose.yml file.

[Stunkymonkey]

@lastzero I am currently working in providing this as NixOS-Module. I considered all the suggestions. In the end a passed env-var can be read by any other user. Placing tha password into a file is the easiest.
Could you please consider the PR linked to this Issue.

[dynamicat]

Any chance of pushing this request forward?

[lastzero]

Since we are currently busy with a very long list of other tasks, you can either use a .env file or provide the password as a hash as a workaround. Also, we recommend changing the password after the first login so that you can use a password that is secure enough for the initial setup instead of choosing your actual password, which may be very long and complex.

Helping us with issues labeled "help wanted" will allow us to ship feature requests more quickly, for example:

• FFmpeg: Allow selection of specific video and audio streams for transcoding #3284

[inthreedee]

I understand that the project has other new feature priorities at the moment, but I'd like to politely suggest that this security improvement be given a higher priority than it currently has, especially since someone has already provided help by implementing it in a PR.

Using an env file does not improve security in the way docker secret files do since the password still gets preserved in the container's perpetual environment. The point of docker secrets is to remove the environment variable attack vector. The hash workaround does not work for mariadb as mentioned.

New features are nice, but security of publicly exposed services is important.

[lastzero]

Docker Secrets are only available in swarm mode, not stand alone based on what I know. I also wouldn't know how we could improve the security of the mariadb service other than proving a more complex default configuration consisting of multiple files, updating all our documentation and asking all users to change their existing setup to use swarm mode or an env file?

[Stunkymonkey]

this is also relevant for non docker environments. e.g: NixOS

[inthreedee]

Docker secret files don't require swarm mode. Docker compose mounts the files provided as files within the container, which the services then access on the filesystem rather than relying on environment variables. It's not as secure as docker secrets used through swarm mode, but it's an improvement over using persistent environment variables and doesn't require anyone to make any changes to their existing setups unless they want to tighten their security a bit. This is meant to work for any secrets anyone wants to provide to the compose file.

For example, a compose file could be modified like so:

secrets:
  # Secrets are single-line text files where the sole content is the secret
  # Paths in this example assume that secrets are kept in local folder called ".secrets"
  DB_ROOT_PWD:
    file: .secrets/db_root_pwd.txt
  DB_PWD:
    file: .secrets/db_pwd.txt

services:
  mariadb:
    environment:
      MARIADB_PASSWORD_FILE: /run/secrets/DB_PWD
      MARIADB_ROOT_PASSWORD_FILE: /run/secrets/DB_ROOT_PWD
    secrets:
      - DB_ROOT_PWD
      - DB_PWD

I'll be honest though, I don't know what Photoprism needs to do on its end to support this or if it's already baked in as a feature of docker-compose?

[lastzero]

Right, there are more complicated and potentially more secure ways to use Docker Compose. We already provide ways to share examples and tutorials with the community though. At the same time, we don't want to exclude users who don't have the need / skills for this and we don't have time to update all our getting started docs to use these features and make it look like this is mandatory.

[lastzero]

For users that cannot or don't want to use environment variables, we have recently added these docs which hopefully are enough to get started? Is there anything missing?

👉 https://docs.photoprism.app/getting-started/config-files/

[Stunkymonkey]

For users that cannot or don't want to use environment variables, we have recently added these docs which hopefully are enough to get started? Is there anything missing?

point_right https://docs.photoprism.app/getting-started/config-files/

--admin-password-file would be nice. this way the secrets are never stored in memory and only available if the file permissions are right:
#2302