Leveraging eBPF for Container Network Monitoring with Cilium
In modern Kubernetes environments, monitoring network traffic and securing containers can be challenging due to their dynamic nature. Cilium, powered by eBPF(Extended Berkeley Packet Filter), offers high-performance visibility and security for containerized applications. This article will guide you through setting up Cilium on a Docker Desktop-based Kubernetes cluster to monitor network traffic and detect suspicious outbound connections.
What is Cilium and eBPF?
Cilium is an open-source networking and security project that leverages eBPF to provide efficient and flexible network observability and enforcement. eBPF runs programs directly in the Linux kernel, enabling fine-grained monitoring of network activity with minimal performance overhead.
Setting Up Cilium on Docker Desktop Kubernetes
Before we dive into monitoring traffic, let’s get Cilium up and running on your Docker Desktop Kubernetes setup.
- Ensure Kubernetes is enabled in Docker Desktop:
- Open Docker Desktop settings and enable Kubernetes. After Kubernetes starts, verify with:
kubectl config current-context
Install Cilium using Helm:
Helm is the easiest way to install Cilium in Kubernetes. First, add the Cilium Helm repository:
helm repo add cilium https://helm.cilium.io/
helm repo update
Then install Cilium:
helm install cilium cilium/cilium --namespace kube-system
Verify Cilium is running:
kubectl get pods -n kube-system
Check Cilium’s status:
After installation, run the following to ensure Cilium is functioning correctly:
kubectl exec -n kube-system -it cilium-xxxxx -- cilium status
Monitoring Network Traffic with Cilium
Now that Cilium is installed, you can begin monitoring network traffic. Cilium’s monitor command gives you detailed, real-time visibility into all packets flowing through your cluster.
Start monitoring network traffic:
To see live network flows, run:
cilium monitor
You’ll start seeing information about network packets, such as source and destination IPs, ports, and protocols. This visibility is powered by eBPF, which runs directly in the kernel for low-latency, high-performance monitoring.
Simulating Suspicious Outbound Connection
Now let’s simulate a suspicious outbound network connection to demonstrate how Cilium can be used to monitor and potentially block unexpected traffic.
Run a container making an outbound HTTP request:
To simulate suspicious behavior, run a pod that makes an HTTP request to an external server (e.g., example.com):
kubectl run external-connect --image=curlimages/curl --restart=Never --stdin --tty --command -- curl http://example.com
Monitor traffic with Cilium:
With the pod making a connection, use Cilium’s monitor command to capture and analyze the network flow:
cilium monitor -t flow
You should see output like:
12:34:56.789 10.244.1.4 -> 93.184.216.34 HTTP
This shows an HTTP request from the pod (10.244.1.4) to the external IP (93.184.216.34, which resolves to example.com). While this may be harmless in some cases, in a real-world scenario, unexpected outbound traffic like this could be a sign of data exfiltration, malware activity, or an unauthorized connection attempt.
Applying Network Policies to Control Outbound Traffic
To enforce security, you can apply network policies in Cilium to control which services or pods are allowed to make outbound connections.
Create a network policy that restricts outbound traffic:
Here’s an example policy that blocks all outbound traffic except within the same namespace:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all-except-same-namespace
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
egress:
- to:
podSelector: {}
ingress:
- from:
podSelector: {}
Apply the network policy:
Apply the policy using kubectl:
kubectl apply -f deny-all-except-same-namespace.yaml
With this policy in place, any attempt by a pod to send traffic outside its namespace will be blocked, including the suspicious outbound request to example.com.
Monitor policy violations:
If the pod tries to make a connection outside the allowed network, Cilium will log a policy violation, helping you identify unauthorized traffic attempts:
cilium monitor --type drop
Cleaning Up
After the demo, you can clean up the resources:
Delete the test pod:
kubectl delete pod external-connect
Uninstall Cilium (if no longer needed):
helm uninstall cilium --namespace kube-system
Conclusion
By using Cilium with eBPF on Docker Desktop’s Kubernetes cluster, you can gain real-time visibility into network traffic, making it easier to detect suspicious outbound connections. With Cilium, monitoring becomes more efficient and detailed, providing granular insights into network flows. By applying network policies, you can also proactively block unauthorized outbound traffic, adding an extra layer of security to your containerized environment.
Cilium’s eBPF-based approach allows for high-performance monitoring and security enforcement with minimal overhead, making it an excellent choice for Kubernetes environments, whether for local demos or production use.
Published on:
Learn moreWe can help you with Leveraging eBPF for Container Network Monitoring with Cilium
If you want help implementing, troubleshooting, or improving this product, contact us and we’ll point you in the right direction.
Related posts
Vasanam Studio: How I Built a Bible Verse Video Generator for My Church as a Hobby Project
Every morning at 5 AM, the women of my church gather for prayer. At the end of the session, our pastor’s wife shares a Bible verse and sends a...
The demo worked. That was the problem.
Over a weekend I built a small Kubernetes demo to play with zero trust. Three little services calling each other in a chain, a login page in f...
Notes from building an agent on AgentCore end to end
I wanted a reason to use AgentCore end to end. Runtime, memory, guardrails, identity, the whole thing. A Bible Q&A agent felt like a good ...
Building a Rust gRPC AI Security Gateway for LLM Traffic
I wanted a small, honest implementation of the GenAI governance shape in code: a component on every LLM call that applies policy first, option...
Claude Code Security: The Smart Way to Integrate AI
Anthropic just dropped Claude Code Security, and if you’re anywhere near AppSec or DevSecOps, you’ve probably already seen the debate lighting...
How I Built a Semantic Cache Using Only AWS Services
LLM calls are expensive and slow, but here’s the thing - users ask the same questions in different ways all the time. “What’s your refund poli...
How to Build Better AI Agent Tools: Cut Costs by 70% (MCP Server Case Study)
Building tools for AI agents isn’t the same as building regular APIs. This guide shows you how to design tools that reduce token costs by 60-7...
Building a DevSecOps Pipeline on AWS (And You Can Too)
I have been working with CI/CD pipelines for a while now, and honestly, most of them just focus on getting code deployed fast. But what about ...
AWS DevOps Agent: AI-Powered Incident Investigation in Seconds
Stop spending 30 minutes investigating incidents. Let AI do it in seconds. Here is a hands-on demo you can practice in 15 minutes. The Proble...
DynamoDB Just Made Your Life Easier: Multi-Attribute Composite Keys Explained
AWS just dropped a feature on November 19, 2025 that is going to save you from one of DynamoDB’s most annoying workarounds: multi-attribute co...