English for Cilium Networking

Cilium introduces a genuinely different model from traditional Kubernetes networking — identity-based security instead of IP-based rules, eBPF instead of iptables — and using the old vocabulary to describe it (calling a Cilium identity an “IP allowlist”) tends to confuse rather than clarify a discussion.

Key Vocabulary

eBPF program — a small, sandboxed program that Cilium loads into the Linux kernel to handle packet filtering, routing, and observability without the overhead of traditional iptables rule chains. “We moved off kube-proxy’s iptables mode entirely — Cilium’s eBPF programs handle service routing directly in the kernel, which is why we saw a real latency improvement under high connection churn.”

CiliumNetworkPolicy (CNP) — Cilium’s extended network policy resource that supports Layer 7 rules (HTTP methods, gRPC calls) in addition to the standard Kubernetes NetworkPolicy’s Layer 3/4 matching. “A standard NetworkPolicy can’t restrict this to just GET requests — we need a CiliumNetworkPolicy since that requires Layer 7 HTTP-aware filtering.”

Identity-based security — Cilium’s model of assigning a security identity to groups of pods based on labels, rather than filtering by IP address, so policies remain correct even as pods are rescheduled and IPs change. “The policy didn’t break during the rollout because Cilium enforces it based on pod identity, not IP — a plain iptables rule keyed on IP would have needed updating every time pods rescheduled.”

Hubble — Cilium’s observability component that provides real-time visibility into network flows, including which services are talking to each other and whether traffic was allowed or dropped by policy. “Instead of guessing why traffic was being dropped, we just checked Hubble and saw the exact flow being denied, along with the specific policy that denied it.”

Cluster mesh — Cilium’s feature for connecting multiple Kubernetes clusters into a single network domain, allowing pod-to-pod communication and shared network policies across cluster boundaries. “We’re using cluster mesh so a service in the EU cluster can call a service in the US cluster directly, with the same identity-based policies applying across both.”

Common Phrases

• “Is this being enforced at Layer 3/4 with a standard NetworkPolicy, or do we need a CiliumNetworkPolicy for Layer 7 filtering?”
• “Is the policy keyed on pod identity, or is there a stale IP-based rule somewhere that will break on the next reschedule?”
• “Have we checked Hubble to see whether this traffic is actually being dropped by policy, or is the failure happening somewhere else?”
• “Is this communication crossing cluster mesh, or are both services in the same cluster?”
• “Are we running kube-proxy alongside Cilium here, or has it been fully replaced by eBPF-based service routing?”

Example Sentences

Debugging a connectivity issue: “Traffic was being silently dropped between these two services — Hubble showed a policy-verdict of ‘denied’ pointing straight at the CiliumNetworkPolicy that was missing an egress rule for this destination.”

Explaining a policy design decision: “We wrote this as a CiliumNetworkPolicy instead of a standard NetworkPolicy because we needed to allow only POST /webhook calls specifically, which requires Layer 7 awareness.”

Describing an architecture choice: “We adopted cluster mesh so our two regional clusters can share identity-based policies directly, instead of routing all cross-region traffic through a separate gateway layer.”

Professional Tips

• Distinguish identity-based policy from IP-based rules explicitly — this is Cilium’s core value proposition, and glossing over it makes migration discussions less convincing.
• Reach for Hubble by name during a networking debugging session rather than describing it vaguely as “the dashboard” — it points teammates to a specific, precise diagnostic tool.
• Specify Layer 7 requirements when justifying a CiliumNetworkPolicy over a standard one — otherwise reviewers may reasonably ask why the built-in Kubernetes resource wasn’t enough.
• Name cluster mesh directly in architecture discussions about multi-cluster traffic — it’s a specific feature with specific trade-offs, not just “cross-cluster networking” in the abstract.

Practice Exercise

1. Explain the difference between identity-based and IP-based network security.
2. Describe what Hubble is used for and why it matters during a networking incident.
3. Write a sentence explaining when a CiliumNetworkPolicy is needed instead of a standard NetworkPolicy.

Applying the Vocabulary in a Code Review

Let’s talk about how this vocabulary – particularly around network policies and Hubble – manifests itself in a typical code review scenario. Imagine you’re reviewing a pull request that introduces a new Cilium policy to restrict outbound traffic from a specific service within your application cluster. The PR description mentions using “policy enforcement” and referencing “Hubble observability” for monitoring. During the review, you might see comments like this:

“@developer, great addition! Just wanted to flag that we’re relying heavily on the NetworkPolicy resource here. Let’s ensure we have comprehensive Hubble metrics configured to track traffic flowing through this policy – specifically focusing on egress connections. It’s crucial to understand why this restriction is in place and whether it aligns with our overall security posture. Could you add a comment explaining the rationale behind blocking outbound traffic to [External Service Name]? Also, let’s ensure we’re capturing relevant metrics around the policy’s effectiveness – are we seeing any unexpected traffic patterns?”

Notice how phrases like “policy enforcement,” “Hubble observability,” and the request for “comprehensive Hubble metrics” directly relate to the vocabulary introduced in this article. It’s not just about knowing the definitions; it’s about understanding how these concepts are used within the context of Cilium’s architecture and Kubernetes networking. This kind of detailed feedback is common when discussing network policies, especially when dealing with complex deployments involving multiple services and stringent security requirements. The goal isn’t simply to say “the policy is correct,” but rather to collaboratively assess its design, implementation, and operational monitoring. Furthermore, proactively asking about Hubble metrics demonstrates a commitment to proactive security and troubleshooting – key elements of professional English in this domain.

Another situation might arise during Slack conversations with the development team regarding an issue flagged by Hubble. Perhaps Hubble detected unusually high traffic volume to a particular destination, triggering a notification. The conversation could go something like this: “Hey team, Hubble’s showing a spike in traffic from our microservice ‘OrderProcessor’ to [External Payment Gateway]. Can we investigate if there’s a misconfiguration or an unexpected increase in demand?” Here, the understanding of “Hubble observability” isn’t just theoretical; it’s actively used as a diagnostic tool. The team leverages Hubble’s ability to visualize and analyze network traffic patterns to pinpoint the root cause of the problem – a critical skill when troubleshooting Kubernetes networking issues.

# Example Cilium Policy YAML (for illustrative purposes only)
apiVersion: cilium.io/v2
kind: NetworkPolicy
metadata:
  name: restrict-outbound-orderprocessor
spec:
  selector:
    matchLabels:
      app: OrderProcessor
  ingress:
  - from_port: 80
    to_ports:
    - 443
    protocol: TCP
    namespaceSelector:
      matchNames:
      - production

This simple YAML example demonstrates the practical application of network policies – a core element of the vocabulary. The selector targets traffic from the ‘OrderProcessor’ service, while the ingress rule defines the allowed outbound connections to external services like [External Payment Gateway]. The policy itself is a concrete manifestation of the abstract concepts discussed in this article, providing a tangible way to control network traffic and enhance security within the cluster.