The Berkeley Packet Filter (BPF) was created in 1992 at Lawrence Berkeley Labs as a way better filter and sort network packets. In the early 2000’s it was at the heart of the long-running SCO versus Linux lawsuit. Today, it’s just another raw interface included with Linux. Recently, however, BPF has become a bit of an interesting topic, as it’s become a popular replacement for IPTables.
Thomas Graf, CTO and co-founder at Covalent. is also the leader of the Cilium Project. Cilium offers API-aware networking and security for Kubernetes users based on BPF. Graf said that the power of BPF can be tough to utilize in Kubernetes, and so the Cilium Project is aimed at making that easier.
“It’s allowing you to translate declarative high-level intent such as policy, networking, load balancing, all of this high-level intent that is described with Kubernetes services. Cilium implements these high-level constructs with BPF in a most efficient and secure manner. It’s bringing the power of BPF in an easily consumable way, and implementing known Kubernetes interfaces,” said Graf.
He said that the project allows for greater control of network access around Kubernetes pods. “Cilium provides networking, load balancing, and security for Kubernetes. You can run Cilium and it will connect your pods, it will provide load balancing in a scalable manner that is many times more efficient than the standard Kube-Proxy implementation, for example. It also implements segmentation and security. It can enforce that only certain pods can talk to a certain external service. So it can only, for example, access the IPs of the data API. Or you can define that a certain pod can only talk on a certain port,” said Graf.
That’s just the beginning of the power of Cilium, however, said Graf. The project adds much more granular control over the ways in which Kubernetes pods can communicate with one another. Whereas the old world model was simply to open or close a port with a firewall, BPF and Cilium can affect specific controls upon pods to restrict their traffic.
“It also goes into the API call level. This is where we see this is the most essential, most important feature because if we apply traditional network security, which is basically saying: two services can talk to each other on a particular port, let’s say port 80… In a traditional firewall world, this means that you either open up the entire API surface so it is two services that do all API calls or none. What we allow you to do is to say ‘Not only can the two pods talk to each other, but they can only issue a certain API call,” said Graf.
In this Edition:
4:25: What is the Cilium implementation of BPF
6:42: How do you allow for that granularity of control?
10:16: How has the Cilium Project evolved and where is it going?
15:04: How does Cilium deal with state?
17:07: Who are your peers in this community?
Feature image via Pixabay.