4 ms·

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-re

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-up-a-coreos-cluster-on-digitalocean https://www.digitalocean.com/community/tutorials/how-to-set-... [2] https://coreos.com/docs/distributed-configuration/etcd-security/ https://coreos.com/docs/distributed-configuration/etcd-secur... [3] https://www.digitalocean.com/community/tutorials/how-to-set-up-a-coreos-cluster-on-digitalocean?comment=17485 https://www.digitalocean.com/community/tutorials/how-to-set-...

knite 12y ago
This is a really great point. I may raise it on one of the CoreOS mailing lists.
akbar501 12y ago
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?
- michaelsbradley 12y ago
  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/customizing-docker/ https://coreos.com/docs/launching-containers/building/custom... [2] https://docs.docker.com/articles/networking/#between-containers 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.

knite 12y ago

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

akbar501 12y ago

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?

michaelsbradley 12y ago
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/customizing-docker/ https://coreos.com/docs/launching-containers/building/custom... [2] https://docs.docker.com/articles/networking/#between-containers 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.