About this image
This docker uses a custom ubuntu:trusty image as a base.
How to use this image
Run your docker, assuming you named your postgresql docker pg as we did above:
$ docker run --rm --name="pg" xcgd/postgresql
To run a specific version:
$ docker run --rm --name="pg95" xcgd/postgresql:9.5
This image ships data volumes for persistence. By default, they will be bound to docker vfs and thus removed along with the container.
You'd rather want to bind volumes to your local file system. This image comes with a facility where initdb is executed only if an empty data volume is found. Otherwise it is just mounted and used.
Let's pretend your persistent data is located under
/opt/instance1/dbdata/ on your host machine, you can use it with:
$ docker run --name="pg" -v /opt/instance1/dbdata:/var/lib/postgresql -d xcgd/postgresql
You'll note that we did not open ports to the outside world on the PostgreSQL container. This is for security reasons, NEVER RUN your PostgreSQL container with ports open to the outside world... Just link other containers (single host) or use an ambassador pattern (cluster).
This is really important to understand. PostgreSQL is configured to trust everyone so better keep it firewalled. And before yelling madness please consider this: If someone gains access to your host and is able to launch a container and open a port for himself he's got your data anyway... he’s on your machine. So keep that port closed and secure your host. Your database is as safe as your host is, no more.
Our containers don't provide a ssh or even a tty. Thus, the container cannot be compromised unless running a
docker exec as root from the host, which is another real concern.
If a motivated individual figures out a breach from the dockerized application itself and finds a way to execute some code, he will have to gain root access that way, get the etcd server address and run etcdctl or something similar with a crafted client certificate.
Nonetheless, security is a real topic and we are glad to discuss and debate the matter anytime. If you find a way to compromise a whole cluster, please report to our tracker.
Last remark: the last image comes with an updated confd version compatible with a consul backend if you don't want to use etcd at all ;)
I menat: one single compromised container.
however, the problem I see with ectd is that a compromised system has easyest acces to all configuration data ("the brain") wihtout difficulties... Not that much, that it is accessed from the outside world... (if I understood you right, that is what you meant?)
By "hidden", I meant hidden in some lower diff-levels in the fs layers, because even a ubuntu trusted, I have hard time explaining that it's over a GB. But maybe I actually missed something. ;)
Thanks again for your clever comments. You are perfectly right that we could work on improving the base image size, which is a naive full ubuntu:trusty, shiping loads of unnecessary stuff by default. Switching to a light debian-based image is in the roadmap.
xcgd/ubuntu4base image, this is a trusted build like any other we provide, that is without any hidden stuff ;) Both
etcdctl clients are enclosed as binary for clustering and automated configuration purpose in our own hosting platform running CoreOS. Providing a secure/private etcd service is pretty easy so I wouldn't worry about built-in ACL (in our case, a
nginx front prevents any companion like
curl to write in our private
Maybe you might use: https://github.com/kelseyhightower/confd instead and disable / remove curl and similar companions (iirc statically linked and compiled, so I bet there is at least no write method available)...
I'm would bet, integrating etcdctl on the base image isn't quite a good idea (etcd cluster got no ACL). Additionally, it seems that your ubuntu4base has builtin (hidden) sins, as both of your images (postgresql and odoo) are more than a GB in size.. Please consider squashing the Docker commits, maybe combined with some OS cleanup of unnecessary stuff...