3 ms·
What etcd does and doesn't support doesn't matter here. Pods do not access etcd. Nothing that is not fully trusted has access. You don't need ACLs when the onl
by TheDong 10y ago
What etcd does and doesn't support doesn't matter here.
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.
- otterley 10y agoThe fact that you don't allow anything to connect to etcd besides the K8S components doesn't really make etcd itself inherently secure. It also implies that access to etcd is an all-or-nothing proposition, which doesn't work well in complex environments. People will need to get into etcd in order to perform debugging, maintenance, etc., and at big organizations, they will need differing levels of access depending on their respective roles. 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.
- mugsie 10y agoIf someone was actually interested in security, they would not allow tenant (or user / etc) defined components access the base infrastructure's etcd, even if it had ACLs. 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.