Default pg_hba is extremely insecure about postgres

[md5]

See #29

[iTech-Developer]

I understand that you can provide your own configuration, but what I mean here is that the defaults need to be reasonable, because many might not change the default configuration.

In most cases, trust should not be used except with 127.0.0.1

[yosifkit]

In almost every case running this image is the same as 127.0.0.1. Unless you forward the port with -p in docker run the database will not be accessible outside your linux machine. If you are worried about other containers accessing you database, you can turn on --icc=false in the docker daemon then only containers that are --linked can talk to each other.

[iTech-Developer]

Yes, you are right.

Just it is fairly common that people will export the database port with -p to access the database remotely in such case the default configuration is extremely insecure and people might not anticipate such insecure default behavior (issue #29 demonstrates this).

My suggestion is that it is always good to have a reasonable default configuration specially for something that will be used by so many people.

[mmarzantowicz]

Please correct me if I'm wrong, but with md5 authentication explicit user account and password needs to be created because "PostgreSQL database passwords are separate from operating system user passwords." So, there is no real security advantage in setting fixed password here in Dockerfile or entry point script over passing all users without any password.

[iTech-Developer]

By default there is no default password for PostgresSQL, and typically first thing people do after installation is to set a password. But with such extremely unsecured default, even after setting a password, still anyone in the world can connect without a password. Additionally, you do not need to include any passwords in the Dockerfile, you can pass the password as environment variable or generate it on the fly.

Check the comments on the docker hub, many are really frustrated from such insecure default configuration of the official image
https://registry.hub.docker.com/_/postgres/

[mmarzantowicz]

@iTech-Developer: Passing password as command line argument is not secure either. Randomly generated one is also no go because it's not flexible enough. I fully agree with you that default settings might look strange for someone new to Docker (count me as one) but alternatives you mentioned are not better (from security pov) at all. Taking this into account there is no gain in making docker image overcomplicated. IMHO LDAP or Kerberos is the only reasonable and secure way but also not the most popular one.

[iTech-Developer]

I agree with you, all what I am suggesting that we should have a reasonable default in the official image, not either super secure or no security at all!

Beside from issue #29 it is clear that some people did not expect such default insecure behavior

[yosifkit]

I did a little research and think we can do similar to mysql and have a POSTGRES_USER that would default to postgres and then require a POSTGRES_PASSWORD like we do with the root password for the myqsl image. To not break current users, we could offer a warning that there is no password set and then fall back to "trust" all the things.

If that sounds amenable, I can get on a PR (unless someone else wants to do it).

[tianon]

+1 from me -- sounds really simple and non-intrusive for existing users as
well

We'll just want to be sure to add the warning to the documentation too.

[pikeas]

+1, sane defaults are a good idea. At the very least, an obvious warning on the Docker registry would be nice.

[defunctzombie]

The fix for this issue makes launching these containers for dev annoying. There should be a flag to turn back on allowing user logins with passwords. Right now you have to inject your own pg_hba.conf.

[Starefossen]

Yes, this change is plain out stupid. The security model of how Docker links containers together provides all the necessary protection.

Someone clearly slept through their Docker class. Here is an excerpt from the Linking Containers Together page:

So what does linking the containers actually do? You've learned that a link allows a source container to provide information about itself to a recipient container. In our example, the recipient, web, can access information about the source db. To do this, Docker creates a secure tunnel between the containers that doesn't need to expose any ports externally on the container; you'll note when we started the db container we did not use either the -P or -p flags. That's a big benefit of linking: we don't need to expose the source container, here the PostgreSQL database, to the network.

[yosifkit]

@Starefossen actually links provide zero security unless you are actually running the docker daemon with --icc=false; with the default being true any container can talk to any other container on any port that they respond on by just using an IP address. Yes there is the "security" of the containers living behind the docker bridge NAT, but that might not always be the case especially with IPv6 coming in docker 1.5.

I'll admit that we might have gone too tight on the security that people were initially complaining was "too insecure" here. The original thought is that you are using something like fig to run your apps and so having a separate database per "service" seemed natural and the docker way, but is seems we ought to be a little more flexible for those users that desire to have their monolithic database for all their services to connect to. We are open to PR's, so make a suggestion.

[joantune]

This kinda sucks if you want multiple databases and users for one postgresql container which seems to me as a good way to do things (isn't it?) so now if you want any kind of user isolation from the apps, you should provide your pg_hba.conf because only the POSTGRES_USER has access..