November 24, 2019

298 words 2 mins read

Network-independent ACLs: Why Security Shouldn't Depend on Your Network [I]

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 …

Talk Title Network-independent ACLs: Why Security Shouldn't Depend on Your Network [I]
Speakers Bernard Van De Walle (Engineer/Product, Aporeto)
Conference CloudNativeCon + KubeCon Europe
Conf Tag
Location Berlin Congress Center
Date Mar 28-30, 2017
URL Talk Page
Slides Talk Slides
Video

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.

comments powered by Disqus