About Cilium and eBPF
Cilium is an open source technology and a highly scalable Kubernetes Container Network Interface (CNI) that provides cloud-native networking connectivity, security, and observability for container-based workloads, such as in Kubernetes and Docker. To provide advanced networking and security controls, Cilium leverages the Linux kernel technology eBPF.
What is eBPF?
eBPF is a revolutionary Linux kernel technology that lets you safely run sandboxed programs in the operating system kernel. With eBPF, you can extend the kernel's capabilities at runtime without changing the kernel code or loading kernel modules.
eBPF programs are event-driven and are run only when the event occurs, such as when a certain system call is initiated. To add the program to an event, pre-defined kernel hooks and probes are used. The hook or probe loads the eBPF program and validates it for its safety. For a program to be considered safe, it must not crash or harm the kernel and must always run to completion. If the program is considered safe, it is translated into machine-specific instructions by using the Just-in-Time (JIT) compiler. For more information about the eBPF architecture and how programs are compiled, see the eBPF documentation.
Because eBPF programs run within the kernel, they come with the following benefits:
- Privileged process only: Only kernel processes can load eBPF programs.
- Safe for the kernel: All programs must pass the safety validation step before they are run in the kernel. A program is considered safe if it does not crash or harm the kernel, and always runs to completion. In addition, eBPF programs have limited access to kernel functions and resources.
- Flexibility: Because eBPF programs do not require changes to the kernel source code or the development of new kernel modules, you can enhance kernel capabilities more quickly without maintaining custom kernel modules or waiting for new kernel releases to be released.
- Efficient: eBPF programs are translated into machine-readable instructions which makes them as efficient as natively compiled kernel code or code that is loaded as a kernel module.
- Enhanced monitoring and tracing: Because eBPF programs run in the kernel, they can detect, monitor and trace incoming and outgoing packets as well as system calls. You can use this data to send only a subset of data to a user program, or allow and block certain packets or system calls.
eBPF was initially developed for user programs, such as
tcpdump, to filter the TCP/IP network packets that are sent from the kernel space into the user space. With the trend of containerizing software and building cloud-native applications, eBPF is used for a wide variety of use cases, such as:
- High performance networking
- Advanced load balancing for cloud-native, multicluster and multi-cloud environments
- Security enforcement at container runtime
- Application tracing
- Performance monitoring and troubleshooting
You can write your own eBPF programs in bytecode, or leverage projects, such as BumbleBee to create the eBPF program for you.
How is eBPF used in Cilium?
Cilium provides an abstraction on top of the eBPF API that lets you implement intelligent networking policies and load balancing between workloads without the need to write actual eBPF code. Instead, you specify your network definition and policies in a YAML or JSON file, and let Cilium translate these definitions into eBPF programs.
As a Kubernetes CNI, Cilium is deployed as a daemon set on each node of the Kubernetes cluster. The daemon set enforces the networking policies you define and is responsible to translate your network definitions into eBPF programs. You can choose to enforce network policies on layer 3 or 4, but Cilium can also protect apps that use layer 7 protocols, such as HTTP, gRPC, or Kafka. Pods can communicate with each other over an overlay network with VXLAN tunnling for packet encapsulation or by utilizing the routing tables of the Linux host.
How does Cilium fit into the OSI model?
With Cilium, you can choose to apply network policies on layer 3, 4, and 7 of the OSI network model. For layer 3 and 4 network policies, unallowed packets are automatically dropped on the respective layer. Because the application layer (layer 7) is not involved in this communication, the client that sends the request does not receive an HTTP response code that can be used to analyze the reason a request was denied.
For network policies that are applied on layer 7, such as an access policy that allows only app A to talk to app B, denied requests return an HTTP response code to the client that includes the reason for the denial.