Session at ContainerDay Security 2023 on the 8th of March in Hamburg. Cilium is the next generation, eBPF powered open-source Cloud Native Networking solution, providing security, observability, scalability, and superior performance. Cilium is an incubating project under CNCF and the leading CNI for Kubernetes. In this session we will introduce the fundamentals of Cilium Network Policies and the basics of application-aware and Identity-based Security. We will discuss the default-allow and default-deny approaches and visualize the corresponding ingress and egress connections. Using the Network Policy Editor we will be able to demonstrate how a Cilium Network Policy looks like and what they mean on a given Kubernetes cluster. Additionally, we will walk through different examples and demonstrate how application traffic can be observed with Hubble and show how you can use the Network Policy Editor to apply new Cilium Network Policies for your workloads. Finally, we’ll demonstrate how Tetragon provides eBPF-based transparent security observability combined with real-time runtime enforcement.

1. Enhancing Network and Runtime
Security with Cilium and Tetragon
ContainerDay Security
Speaker: Raymond de Jong
@dejongraymond

2. Agenda
● Cilium & eBPF Introduction
● Security
● Multi-Cluster Security
● Observability
● Getting it done…

3. Cilium & eBPF
Introduction

4. ● Open Source Projects ● Company behind Cilium
● Provides Cilium Enterprise

6. Makes the Linux kernel
programmable in a
secure and efficient way.
“What JavaScript is to the
browser, eBPF is to the
Linux Kernel”

7. Run eBPF programs on events
Attachment points
● Kernel functions (kprobes)
● Userspace functions (uprobe)
● System calls
● Tracepoints
● Sockets (data level)
● Network devices (packet level)
● Network device (DMA level) [XDP]
● ...

8. What is Cilium?
At the foundation of Cilium is the new Linux kernel
technology eBPF, which enables the dynamic
insertion of powerful security, visibility, and
networking control logic within Linux itself. Besides
providing traditional network level security, the
flexibility of BPF enables security on API and process
level to secure communication within a container or
pod.
Read More
● Networking & Load-Balancing
○ CNI, Kubernetes Services, Multi-cluster, VM Gateway
● Network Security
○ Network Policy, Identity-based, Encryption
● Observability
○ Metrics, Flow Visibility, Service Dependency

10. - Networking
- Security
- Observability
- Service Mesh & Ingress
-based:
Foundation
Created by
Technology

11. Security

12. Identity-based Security

13. API-aware Authorization

14. API-Aware Network Policy Example

15. Cassandra Cilium Network Policy Example

16. DNS-aware Cilium Network Policy

17. Matching Capabilities
Kubernetes
● Pod labels
● Namespace name & labels
● ServiceAccount name
● Service names
● Cluster names
DNS Names
● FQDN and regular expression
CIDR
● CIDR blocks with exceptions
Cloud Providers
● Instance labels
● VPC/Subnet name/tags
● Security group name
Logical Entities
● Everything inside cluster
● Everything outside cluster
● Local host
● ...

18. Network Policy Editor - https://editor.cilium.io

19. Multi-Cluster Security

20. Cluster Mesh - Introduction

21. Cluster Mesh - Identity Aware Security

22. Cluster Mesh - External VM & BM Security

23. Cluster Mesh - Cilium Network Policies

24. Cluster Mesh - Cilium Network Policies

25. Observability

26. What is Hubble?

27. Service Map

28. Flow Visibility
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
tiefighter 1/1 Running 0 2m34s
xwing 1/1 Running 0 2m34s
deathstar-5b7489bc84-crlxh 1/1 Running 0 2m34s
deathstar-5b7489bc84-j7qwq 1/1 Running 0 2m34s
$ hubble observe --follow -l class=xwing
# DNS lookup to coredns
default/xwing:41391 -> kube-system/coredns-66bff467f8-28dgp:53 to-proxy FORWARDED (UDP)
kube-system/coredns-66bff467f8-28dgp:53 -> default/xwing:41391 to-endpoint FORWARDED (UDP)
# ...
# Successful HTTPS request to www.disney.com
default/xwing:37836 -> www.disney.com:443 to-stack FORWARDED (TCP Flags: SYN)
www.disney.com:443 -> default/xwing:37836 to-endpoint FORWARDED (TCP Flags: SYN, ACK)
www.disney.com:443 -> default/xwing:37836 to-endpoint FORWARDED (TCP Flags: ACK, FIN)
default/xwing:37836 -> www.disney.com:443 to-stack FORWARDED (TCP Flags: RST)
# ...
# Blocked HTTP request to deathstar backend
default/xwing:49610 -> default/deathstar:80 Policy denied DROPPED (TCP Flags: SYN)
Flow Metadata
‒ Ethernet headers
‒ IP & ICMP headers
‒ UDP/TCP ports, TCP flags
‒ HTTP, DNS, Kafka, ...
Kubernetes
‒ Pod names and labels
‒ Service names
‒ Worker node names
DNS (if available)
‒ FQDN for source and
destination
Cilium
‒ Security identities and
endpoints
‒ Drop reasons
‒ Policy verdict matches

29. Hubble Metrics

30. Strategies for Designing Network Policies

31. Key Types of Kubernetes Network Risk Exposure

32. Minimizing Risk: Reduce Unused Access
Primary Goal: Reduce unused network access that creates exposure
without being required for the application to function properly.

33. Risk Reduction Example - Wide blast radius

34. Risk Reduction Example - Limited blast radius

35. Initial Per-Namespace Strategy
● Allow all ingress/egress communication within a namespace.
● Use Hubble Observability to identify and permit:
○ Which (service + port) within the namespace are “public services”:
■ Allow from cluster-only.
■ Allow from “world” (type LB/NP) or ingress namespace.
○ Egress Access to:
■ Other services in the cluster (optional, limit ports).
■ Other services in the external private network (optional, limit ports).
■ Other services on the Internet (optional, limit ports).
● Coarse-grained nature of policies mean that policies need only change rarely
when an app changes a core aspect of it’s communication pattern.

36. Example Baseline + Coarse-grained Per Namespace Policies

37. Using Hubble Observability Data to Build Policies

38. Transitioning from “Coarse” to “Fine-Grained” Policies
● Prioritize namespaces based on:
○ Most security-sensitive applications.
○ Measurement of exposure vs. used connectivity.
● Transition for egress outside the cluster:
○ Access to all private network → Access to specific FQDNs or smaller CIDRs
(with port).
○ Access to Internet → Access to specific FQDNs or small CIDRs (with port)
● Transitions within the cluster:
○ Shift rules that allow all to/from cluster to allowing to/from specific
namespaces or services.

39. Example Baseline + Fine-grained Per Namespace Policies

40. Network Policy Guardrails
Maintain control while granting application teams self-service management of
Network Policy.

41. Getting it Done…
Transitioning from Observability to Enforcement

42. Challenges for Adopting Network Policies
● Where to start? What policies reduce risk with least friction?
● How to troubleshoot Network Policies?
● How to keep Network Policies up-to-date as applications evolve?
● How to prevent applications teams from simply “allowing everything”
● How can security teams prove “default deny” policies are always enforced?
● How can security teams be alerted on denied connections?

43. Overview
● Phase 1: Deploy your Application
● Phase 2: Observe Flows with Hubble
● Phase 3: Create Cilium Network Policies → Today’s Demo
● Phase 4: Enforce

44. Tetragon

45. @lizrice
Cilium Tetragon
● New open source project in Cilium
● eBPF based = high performance and zero modifications required to app
● Hooks into kernel functions after parameters are copied
● Adds contextual information about Kubernetes objects
● Preventative capabilities
github.com/cilium/tetragon

46. Tetragon

47. OSS Community
eBPF-based Networking,
Observability, Security
cilium.io
cilium.slack.com
Regular news
Learn more!
Base technology
The revolution in the Linux kernel,
safely and efficiently extending the
capabilities of the kernel.
ebpf.io
What is eBPF? - ebook
For the Enterprise
Hardened, enterprise-grade
eBPF-powered networking,
observability, and security.
isovalent.com/product
isovalent.com/labs

48. Thank you!