Consider securing etcd

[pstadler]

Compromised containers could access and leak important data stored in etcd.

Related comment on Hacker News: https://news.ycombinator.com/item?id=14291817

[pstadler]

See: https://raesene.github.io/blog/2017/05/01/Kubernetes-Security-etcd/ via @raesene

[Informatic]

Taking into account that kubeadm is able to setup etcd itself on master now (without clustering, of course), is there really any advantage of having it setup manually here, considering all the security implications?

Isn't kubernetes master a SPOF anyway? (All the components talk to kube-apiserver, and that wouldn't be rescheduled to any other node when something breaks, as far as I understand)

Only advantage I can think of is data resiliency, but assuming master gets completly destroyed, you'd still loose kube-apiserver keypair and all... I wouldn't consider it better than sensible backup strategy :(

There's simply no need to make use of additional security layers as long as the service is bound to an end-to-end secured VPN interface.

As seen above, this is very misleading - I think this issue should be linked somewhere in that section, and possibly that full sentece be removed completely.

[pstadler]

Started working on it: https://github.com/hobby-kube/provisioning/pull/39/files

[pstadler]

@Informatic I don't like the idea of having an unclustered etcd running.

[pstadler]

@Informatic just wanted to add that all your points are valid. Will consider your input moving forward 👍🏻

[Govinda-Fichtner]

Are there any updates regarding this?