The Docker Hub readme instructs users to treat a container with $POSTGRES_PASSWORD supplied as immediately usable, which can only be true if the user's intention was to grant their application superuser access to the database (and is only possible because the variable name belies its true function). Creating an unprivileged user is an afterthought relegated to below-the-fold, requires an init script be mounted, and the example doesn't even demonstrate setting up an auth mechanism for the new user. At the bare minimum I'd expect an environment-based facility to create an unprivileged user (I've included my own init script below for reference).
Additionally, the instructions on running the container itself unprivileged are also below the fold, and the most apparently useful of the options given is a link to a half-decade-old pull request which includes no documentation and has since been almost completely reworked in master. I still haven't figured out how to make rootless postgres work as yet.
Finally, the Hub readme (despite not informing users of how to run either the container or the database itself securely) is truncated for exceeding the 25,000 word limit on Docker Hub.
The postgres Docker image needn't provision the Fort Knox of configurations, but users ought to at least be reasonably informed, particularly about security implications, and given the information/tools to provision a container utilizing the bare minimum security good practice. Is there a process that can be kicked off for reconsidering some of these approaches please?
I'm happy to open this issue over at docker-library/docs if necessary, but since this involves issues with the image itself this seemed a more appropriate place.
Thank you.
init-db.sh
#!/bin/bash
set -euo pipefail
psql -v ON_ERROR_STOP=1 --username postgres --dbname postgres --set pass="$DB_PASSWORD" <<-EOF
CREATE USER '$DB_USER' WITH ENCRYPTED PASSWORD :'pass';
CREATE DATABASE '$DB_USER' WITH OWNER '$DB_USER' TEMPLATE template0 ENCODING UTF8 LC_COLLATE 'en_US.UTF-8' LC_CTYPE 'en_US.UTF-8';
EOF
Hi,
The Docker Hub readme instructs users to treat a container with
$POSTGRES_PASSWORDsupplied as immediately usable, which can only be true if the user's intention was to grant their application superuser access to the database (and is only possible because the variable name belies its true function). Creating an unprivileged user is an afterthought relegated to below-the-fold, requires an init script be mounted, and the example doesn't even demonstrate setting up an auth mechanism for the new user. At the bare minimum I'd expect an environment-based facility to create an unprivileged user (I've included my own init script below for reference).Additionally, the instructions on running the container itself unprivileged are also below the fold, and the most apparently useful of the options given is a link to a half-decade-old pull request which includes no documentation and has since been almost completely reworked in master. I still haven't figured out how to make rootless postgres work as yet.
Finally, the Hub readme (despite not informing users of how to run either the container or the database itself securely) is truncated for exceeding the 25,000 word limit on Docker Hub.
The postgres Docker image needn't provision the Fort Knox of configurations, but users ought to at least be reasonably informed, particularly about security implications, and given the information/tools to provision a container utilizing the bare minimum security good practice. Is there a process that can be kicked off for reconsidering some of these approaches please?
I'm happy to open this issue over at docker-library/docs if necessary, but since this involves issues with the image itself this seemed a more appropriate place.
Thank you.
init-db.sh