cilium v1.13.2 releases: eBPF-based Networking, Security, and Observability

cilium: eBPF-based Networking, Security, and Observability

Cilium is open source software for providing and transparently securing network connectivity and load-balancing between application workloads such as application containers or processes. Cilium operates at Layer 3/4 to provide traditional networking and security services as well as Layer 7 to protect and secure the use of modern application protocols such as HTTP, gRPC, and Kafka. Cilium is integrated into common orchestration frameworks such as Kubernetes.

A new Linux kernel technology called eBPF is at the foundation of Cilium. It supports the dynamic insertion of eBPF bytecode into the Linux kernel at various integration points such as network IO, application sockets, and tracepoints to implement security, networking, and visibility logic. eBPF is highly efficient and flexible. To learn more about eBPF, visit eBPF.io.

Functionality Overview

Protect and secure APIs transparently

Ability to secure modern application protocols such as REST/HTTP, gRPC, and Kafka. Traditional firewalls operate 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.

Secure service to service communication based on identities

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.

Secure access to and from external services

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.

Simple Networking

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:
  • Native IPv6 networks
  • In conjunction with cloud network routers
  • If you are already running routing daemons

Load Balancing

Cilium implements distributed load balancing for traffic between application containers and to external services and is able to fully replace components such as kube-proxy. The load balancing is implemented in eBPF using efficient hashtables allowing for almost unlimited scale.

For north-south type load balancing, Cilium’s eBPF implementation is optimized for maximum performance, can be attached to XDP (eXpress Data Path), and supports direct server return (DSR) as well as Maglev consistent hashing if the load balancing operation is not performed on the source host.

For east-west type load balancing, Cilium performs efficient service-to-backend translation right in the Linux kernel’s socket layer (e.g. at TCP connect time) such that per-packet NAT operations overhead can be avoided in lower layers.

Bandwidth Management

Cilium implements bandwidth management through efficient EDT-based (Earliest Departure Time) rate-limiting with eBPF for container traffic that is egressing a node. This allows to significantly reduce transmission tail latencies for applications and to avoid locking under multi-queue NICs compared to traditional approaches such as HTB (Hierarchy Token Bucket) or TBF (Token Bucket Filter) as used in the bandwidth CNI plugin, for example.

Monitoring and Troubleshooting

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.
• Metrics export via Prometheus: Key metrics are exported via Prometheus for integration with your existing dashboards.
• Hubble: An observability platform is specifically written for Cilium. It provides service dependency maps, operational monitoring and alerting, and application and security visibility based on flow logs.

Changelog v1.13.2

This release addresses the following security issue:

• GHSA-pg5p-wwp8-97g8

Note: When updating to this release, make sure that you are using new helm chart version.

Summary of Changes

Known Issues:

• There is a known issue (#24502) with CiliumNetworkPolicies that makes the kube-apiserver entity unreliable. Until this is resolved, it is recommended to remain on Cilium v1.12 or earlier if you are using the kube-apiserver entity in your CiliumNetworkPolicies.

Minor Changes:

• envoy: Bump envoy to v1.23.8 (#24909, @sayboras)
• envoy: Bump envoy version to v1.23.7 (#24746, @sayboras)
• Move poststart eni script to agent pod from nodeinit pod (Backport PR #24547, Upstream PR #24134, @nebril)
• Provides operational state of BGP peers via CLI ‘cilium bgp peers’ (Backport PR #24821, Upstream PR #24612, @harsimran-pabla)
• Support L2-less devices with fast forward (bpf-based host routing) (Backport PR #24706, Upstream PR #23935, @jschwinger233)

• More…

Install & Use

Copyright 2021 Authors of Cilium