4 ms·

The comment you're replying to doesn't say that etcd is insecure; just that access to etcd is equivalent in power to Kubernetes API access. It's hard to have a

by soamv 10y ago

The comment you're replying to doesn't say that etcd is insecure; just that access to etcd is equivalent in power to Kubernetes API access. It's hard to have a productive discussion in such a confrontational tone, especially when you don't really have all the facts. If you have questions about how to secure Kubernetes communication with etcd, feel free to ask!

otterley 10y ago
What facts do you think I don't possess? Does etcd have an ACL capability yet? Does it possess auditing capability? 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.
- 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 ago
    The 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 ago
      If 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.
- robszumski 10y ago
  etcd does contain ACLs: https://coreos.com/etcd/docs/latest/v2/auth_api.html https://coreos.com/etcd/docs/latest/v2/auth_api.html
  - otterley 10y ago
    First, I apologize for my ignorance re: etcd ACL functionality. I did try to research it, but... 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 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.
    - mugsie 10y ago
      The great thing about open source is that you can make changes when you see some thing that is wrong :) https://github.com/coreos/etcd/blob/master/Documentation/v2/auth_api.md https://github.com/coreos/etcd/blob/master/Documentation/v2/... and https://github.com/coreos/etcd/blob/master/Documentation/op-guide/security.md https://github.com/coreos/etcd/blob/master/Documentation/op-... are the two pages.
      - otterley 10y ago
        Open-source doesn't mean free labor. CoreOS is a for-profit enterprise; it's in their own best interest to hire people to produce great documentation.
        mugsie 10y ago
        Open Source also does not mean free products and support. 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)

by soamv 10y ago

otterley 10y ago

What facts do you think I don't possess? Does etcd have an ACL capability yet? Does it possess auditing capability? 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.

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 ago
  The 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 ago
    If 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.
robszumski 10y ago
etcd does contain ACLs: https://coreos.com/etcd/docs/latest/v2/auth_api.html https://coreos.com/etcd/docs/latest/v2/auth_api.html
- otterley 10y ago
  First, I apologize for my ignorance re: etcd ACL functionality. I did try to research it, but... 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 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.
  - mugsie 10y ago
    The great thing about open source is that you can make changes when you see some thing that is wrong :) https://github.com/coreos/etcd/blob/master/Documentation/v2/auth_api.md https://github.com/coreos/etcd/blob/master/Documentation/v2/... and https://github.com/coreos/etcd/blob/master/Documentation/op-guide/security.md https://github.com/coreos/etcd/blob/master/Documentation/op-... are the two pages.
    - otterley 10y ago
      Open-source doesn't mean free labor. CoreOS is a for-profit enterprise; it's in their own best interest to hire people to produce great documentation.
      - mugsie 10y ago
        Open Source also does not mean free products and support. 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)