Customize your schedule by session topic and skill level: Session Topic - Refer to the "Type" filter list to the right to find a session based on topic. Talk Difficulty - Sessions are categorized as [B]eginner, [I]ntermediate or [A]dvanced at the end of each talk title.
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.
Working initially on massive production core/edge network routers, I saw the evolution of networking and security from fully physical to the new models emerging today: SDN, virtual networks and massive scaling for micro-services. After spending 4 years implementing a well-recognized... Read More →
