You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Hi,
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
The text was updated successfully, but these errors were encountered: