Comment by michaelsbradley | Hacker News Reader

Comment by michaelsbradley | Hacker News Reader

michaelsbradley

The article How To Set Up a CoreOS Cluster on DigitalOcean[1] (written by a DigitalOcean employee) fails to mention what seems to me to be a serious security-related concern.

Since droplets with private networking enabled are on the same private network as other customers' droplets, then if "$private_ipv4" is specified for "addr" and "peer-addr" in cloud-config, isn't it critical that etcd be secured with TLS and client cert authentication?

See: CoreOS – Etcd: Reading and Writing over HTTPS[2]

I realize that delving into that aspect of coreos/etcd configuration is beyond the scope of an introductory "how to" article, but I believe that some strong mention should be given to this concern.

I made a comment[3] to this effect on DigitalOcean's website.

[1] https://www.digitalocean.com/community/tutorials/how-to-set-...

[2] https://coreos.com/docs/distributed-configuration/etcd-secur...

[3] https://www.digitalocean.com/community/tutorials/how-to-set-...

The article you linked to provides security for etcd.

However, what is the standard approach for securing Docker container to container communication across hosts. For example from an app server to a DB server.

Is IPSec setup within CoreOS network layer, or is the security provided by Docker? If so, what are the options?

I don't think CoreOS does anything special in this regard.

It should be possible via cloud-config to change the runtime config of the docker service[1], in which case one could set "--icc=false"[2] to enforce stricter rules about inter-container communication on a particular docker host (e.g. a coreos droplet).

[1] https://coreos.com/docs/launching-containers/building/custom...

[2] https://docs.docker.com/articles/networking/#between-contain...

EDIT:

Okay, I see you were asking about regulating network comm between containers on separate docker hosts, i.e. coreos instances.

That's a good question! I still don't think CoreOS addresses that concern in any special way at the level of iptables and routing (but I could be wrong). What it does give you is the ability to control service affinity with respect to your fleet "units". That way, you can be certain that docker containers which need to be "linked" in order to communicate properly (e.g. you have set "--icc=false") will run on the same host.

This is a really great point. I may raise it on one of the CoreOS mailing lists.

Reply on news.ycombinator.com