Cilium is open source software for transparently securing the network
connectivity between application services deployed using Linux container
management platforms like Docker and Kubernetes.

At the foundation of Cilium is a new Linux kernel technology called BPF, which
enables the dynamic insertion of powerful security visibility and control logic
within Linux itself. Because BPF runs inside the Linux kernel, Cilium
security policies can be applied and updated without any changes to the
application code or container configuration.

The development of modern datacenter applications has shifted to a
service-oriented architecture often referred to as microservices, wherein a
large application is split into small independent services that communicate
with each other via APIs using lightweight protocols like HTTP. Microservices
applications tend to be highly dynamic, with individual containers getting
started or destroyed as the application scales out / in to adapt to load changes
and during rolling updates that are deployed as part of continuous delivery.

This shift toward highly dynamic microservices presents both a challenge and an
opportunity in terms of securing connectivity between microservices.
Traditional Linux network security approaches (e.g., iptables) filter on IP
address and TCP/UDP ports, but IP addresses frequently churn in dynamic
microservices environments. The highly volatile life cycle of containers causes
these approaches to struggle to scale side by side with the application as load
balancing tables and access control lists carrying hundreds of thousands of
rules that need to be updated with a continuously growing frequency. Protocol
ports (e.g. TCP port 80 for HTTP traffic) can no longer be used to
differentiate between application traffic for security purposes as the port is
utilized for a wide range of messages across services.

An additional challenge is the ability to provide accurate visibility as
traditional systems are using IP addresses as primary identification vehicle
which may have a drastically reduced lifetime of just a few seconds in
microservices architectures.

By leveraging Linux BPF, Cilium retains the ability to transparently insert
security visibility + enforcement, but does so in a way that is based on
service / pod / container identity (in contrast to IP address identification in
traditional systems) and can filter on application-layer (e.g. HTTP). As a
result, Cilium not only makes it simple to apply security policies in a highly
dynamic environment by decoupling security from addressing, but can also
provide stronger security isolation by operating at the HTTP-layer in addition
to providing traditional Layer 3 and Layer 4 segmentation.

The use of BPF enables Cilium to achieve all of this in a way that is highly
scalable even for large-scale environments.

Ability to secure modern application protocols such as REST/HTTP, gRPC and
Kafka. Traditional firewalls operates at Layer 3 and 4. A protocol running on a
particular port is either completely trusted or blocked entirely. Cilium
provides the ability to filter on individual application protocol requests such
as:

Allow all HTTP requests with method GET and path /public/.*. Deny all
other requests.

Allow service1 to produce on Kafka topic topic1 and service2 to
consume on topic1. Reject all other Kafka messages.

Require the HTTP header X-Token:[0-9]+ to be present in all REST calls.

See the section Layer 7 Policy in our documentation for the latest list of
supported protocols and examples on how to use it.

Modern distributed applications rely on technologies such as application
containers to facilitate agility in deployment and scale out on demand. This
results in a large number of application containers to be started in a short
period of time. Typical container firewalls secure workloads by filtering on
source IP addresses and destination ports. This concept requires the firewalls
on all servers to be manipulated whenever a container is started anywhere in
the cluster.

In order to avoid this situation which limits scale, Cilium assigns a security
identity to groups of application containers which share identical security
policies. The identity is then associated with all network packets emitted by
the application containers, allowing to validate the identity at the receiving
node. Security identity management is performed using a key-value store.

Label based security is the tool of choice for cluster internal access control.
In order to secure access to and from external services, traditional CIDR based
security policies for both ingress and egress are supported. This allows to
limit access to and from application containers to particular IP ranges.

A simple flat Layer 3 network with the ability to span multiple clusters
connects all application containers. IP allocation is kept simple by using host
scope allocators. This means that each host can allocate IPs without any
coordination between hosts.

The following multi node networking models are supported:

Overlay: Encapsulation-based virtual network spanning all hosts.
Currently VXLAN and Geneve are baked in but all encapsulation formats
supported by Linux can be enabled.

When to use this mode: This mode has minimal infrastructure and integration
requirements. It works on almost any network infrastructure as the only
requirement is IP connectivity between hosts which is typically already
given.

Native Routing: Use of the regular routing table of the Linux host.
The network is required to be capable to route the IP addresses of the
application containers.

When to use this mode: This mode is for advanced users and requires some
awareness of the underlying networking infrastructure. This mode works well
with:

Distributed load balancing for traffic between application containers and to
external services. The loadbalancing is implemented using BPF using efficient
hashtables allowing for almost unlimited scale and supports direct server
return (DSR) if the loadbalancing operation is not performed on the source
host.
Note: load balancing requires connection tracking to be enabled. This is the
default.

The ability to gain visibility and to troubleshoot issues is fundamental to the
operation of any distributed system. While we learned to love tools like
tcpdump and ping and while they will always find a special place in our
hearts, we strive to provide better tooling for troubleshooting. This includes
tooling to provide:

Event monitoring with metadata: When a packet is dropped, the tool doesn’t
just report the source and destination IP of the packet, the tool provides
the full label information of both the sender and receiver among a lot of
other information.

Policy decision tracing: Why is a packet being dropped or a request rejected.
The policy tracing framework allows to trace the policy decision process for
both, running workloads and based on arbitrary label definitions.