Network-independent ACLs: Why Security Shouldn't Depend on Your Network [I]
The conventional view is that Security and ACLs are implemented in the network, through a set of typical firewall rules that rely on the IP and Port number. In Kubernetes, everything is a label and p …
|Network-independent ACLs: Why Security Shouldn't Depend on Your Network [I]
|Bernard Van De Walle (Engineer/Product, Aporeto)
|CloudNativeCon + KubeCon Europe
|Berlin Congress Center
|Mar 28-30, 2017
The conventional view is that Security and ACLs are implemented in the network, through a set of typical firewall rules that rely on the IP and Port number. In Kubernetes, everything is a label and pod communications are defined as a set of labels allowed to communicate with each other. (Through the definition of network policies). This model fully abstracts the pod network information (IP/Port) from the pod’s identity (pod’s labels). With the traditional approach, the NetworkPolicies are implemented by the Kubernetes networking backend (Flannel, Calico, …) that translates the policies into a set of IPs/Ports that need to be constantly updated. However, another approach is possible by using the labels associated with each pods directly as metadata on the networking stack (transparently from the networking backend). NetworkPolicies then become a simple API-level authentication scheme that is completely independent from the network backend. This talk will go over the pros and cons of each model, describing specific use-cases where it makes sense to use the one or the other. It will introduce a new way of implementing those NetworkPolicies that doesn’t rely at all on network primitives, but only on the set of labels associated to each pod. Networking should be used for reachability between cluster nodes. but security and network policies should not always be tied to your networking.