What the article doesn’t spell out is that at least on etcd 2.x, activating user/password authentication is a true performance killer. So if you want ACLs a bit more complex than “client has a valid TLS certificate to connect with”, you had to either take the huge performance hit, or get creative and proxy etcd via nginx to support a better auth model[1].

Even then, etcd has never been designed as something that could be exposed directly to the internet, I wouldn’t blame the developers for not foreseeing people ignoring the most basic security principles (like: don’t have any of your datastores directly exposed to the internet); but I would blame them for attaching an auth model post-facto to etcd, and for the fact that, along all the 2.x series, auth was basically unusable (see e.g. https://github.com/coreos/etcd/issues/5840 or https://github.com/coreos/etcd/issues/3223) and has been “fixed” in 3.1 and following releases by allowing to do RBAC based on the common name of a client TLS certificate…