AFAIK etcd only supports TLS client authentication, which is arguably a fraction of what it needs in order to be considered a secure store in any meaningful sense. Consul is miles ahead in this regard.
By all means, correct me if I'm mistaken.
Pods do not access etcd. Nothing that is not fully trusted has access. You don't need ACLs when the only users of etcd are 100% trusted (aka just kubernetes core components).
The kubernetes API provides secrets to pods and can do its own validation (and there's experimental support for that). It can provide its own auditing. That's where it actually matters, not etcd.
And your assumption that only K8S will access etcd isn't necessarily shared by others. In the model implementation, perhaps that is so; but in the real world, implementors may desire to share etcd with other applications. This too necessitates additional security options for etcd itself.
Basic separation of concerns would call for a separate instance of etcd.
In a complex environment, spinning up a new etcd should not be a big deal.
Now, having ACLs, is not a bad thing, but they should only be used to lock down the base infrastructure access even more, and still have a separate instance for other applications.
Can you please ensure it's in the Security section of the documentation? It's not mentioned there at all! https://coreos.com/etcd/docs/latest/op-guide/security.html
Also, "authentication" is not identical to "authorization" or "access control" -- and it's not obvious to the reader that discussion of one includes the other. The words "ACL" and/or "access control" really need to be specifically used in the title and body of the pertinent documentation to be easily locatable by the researcher.
Finally, it doesn't appear that the K8S API server can authenticate to etcd yet. (That's not etcd's fault, but it does contribute to my impression of the integration's overall security posture.) Again, please correct me if I'm mistaken.
https://github.com/coreos/etcd/blob/master/Documentation/v2/... and https://github.com/coreos/etcd/blob/master/Documentation/op-... are the two pages.
As a case in point, you were giving out about 2 different pieces of open source software in this thread.
Neither of which you have to pay for. Both of which are complex system that have taken many many people hours to build. As a return, is suggesting that you may submit a PR (or even a bug, with suggestions so that the people CoreOS hires to write docs know there is an issue)
"I (and others) would kindly appreciate it if you'd stop"
"If you'd like to find a place to help, I'd suggest"
"engineering teams need to do a better job of integrating community PRs "
"Finally, I'd like to see deadlines and decision-makers appointed"
"What facts do you think I don't possess?"
They don't owe me anything in particular, but I do wish more people would let their fruit ripen on the vine instead of in the grocery store (or worse, at the purchaser's house).
And judging by the comment scores, I'm not the only one who feels this way.
Conversely, you may note that I do get very excited and happy about products that are well-designed, well-documented, and aren't dumped onto an unsuspecting public before they are mature.
I think this article is pertinent: https://medium.com/@thejameskyle/dear-javascript-7e14ffcae36...
So if anyone's feelings have been hurt, please know that was not my intent.