Cilium Host Policies
Learn a complete Cilium host policy example for a RKE2-based Kubernetes cluster
Learn a complete Cilium host policy example for a RKE2-based Kubernetes cluster
Learn how to install Cilium in Kubernetes with KubeKey and visualize network traffic with Hubble
As more crucial workloads are being migrated to Kubernetes, network performance benchmarks are becoming an important selection criteria when deciding what network layer to leverage in a Kubernetes cluster. In this blog post, we'll explore the performance characteristics of Cilium based on extensive benchmarks that we have run in the past few weeks. Upon popular request, we are also including measurements for Calico to allow for a direct comparison.
You've probably heard about the new Man in the Middle (MITM) vulnerability in Kubernetes. If you're unfamiliar, a MITM vulnerability works by redirecting a victim's legitimate network traffic through a secret attacker on the network, where the attacker can eavesdrop or actively tamper with the victim's data before sending it to its intended destination. There have been several MITM vulnerabilities in Kubernetes, most of which take advantage of the default overly-permissive CAP_NET_RAW permissions in Kubernetes. However this vulnerability is unique in two ways:1. MITM attacks generally make use of common types of network vulnerabilities, whereas this vulnerability affects the API layer of Kubernetes itself. 2. Unlike most vulnerabilities that are assigned a Common Vulnerabilities and Exposures (CVE), there's no patch or hotfix you can deploy to protect your environment. This vulnerability is also unique in another way:if you're running Cilium without kube-proxy, you aren't vulnerable to it at all. Let's talk about how.
Multitenancy is a common pattern in Kubernetes. Many organizations deploy Kubernetes-as-a-Service, where one cluster houses many tenants and workloads. This pattern might sound familiar, as cloud computing services like AWS, Azure, and GCP have enabled multiple customers (tenants) to run their business-critical workloads in a single cluster for years.
Recently a vulnerability was discovered by Etienne Champetier that impacted several Kubernetes CNIs. The vulnerability worked by having an attacker pod send rogue IPv6 “Router Advertisement” packets to the host worker node, causing the node to route its IPv6 traffic through the attackers pod (commonly known as “Man-In-The-Middle”). Fortunately for users of Cilium, this vulnerability didn’t impact their environments because of several built-in and on-by-default security features provided by Cilium.In this blog post, we’ll discuss how on-by-default Cilium features automatically protect against these common types of network attacks.
In this guide, we will walk through the steps required to build a multi-node Kubernetes cluster on your local workstation or laptop using K3s and Cilium. Then we'll show how you can use Hubble to inspect traffic in the cluster and visualize data exposed by the superpowers of eBPF and Cilium. We will also show you how to restrict the flow of traffic between applications. Finally, we will see how Cilium and Hubble can provide detailed information to help you solve problems related to compliance and regulations.
DNS is a common cause for outages and incidents in Kubernetes clusters. For real-world stories, swing by Kubernetes Failure Stories. How do you debug and troubleshoot DNS issues? How do you know a problem is related to DNS? This guide provides a step by step tutorial on how to systematically troubleshoot DNS issues in Kubernetes clusters. We will be using [Hubble] to identify and inspect DNS issues as well as set up monitoring so we can locate DNS issues early on to react even before incidents occur.
This is a deep dive into ClusterMesh, Cilium's multi-cluster implementation.
For live conversation and quick questions, join the Cilium Slack workspace. Don’t forget to say hi!
Join slack workspace