Virtualization Technology News and Information
VMblog Expert Interview: Isovalent on the Launch of Cilium 1.14


With the recent launch of Cilium 1.14, VMblog spoke with Roland Wolters, Head of Technical Marketing at Isovalent, to find out more about this release and the community.

VMblog:  Tell VMblog readers a little bit about Cilium, how it relates to eBPF, what kind of adoption it has and why it's such an interesting project in cloud-native?

Roland Wolters:  Cilium provides enhanced networking, security, and observability for cloud-native environments such as Kubernetes clusters. It has become the de-facto standard for secure and observable cloud native connectivity and has been selected as the default in several managed Kubernetes offerings of major public cloud providers including Google Kubernetes Engine, Google Anthos, and Amazon EKS Anywhere. The reason for this massive adoption is the level of detail, efficiency, and control that Cilium brings. Cilium is built around the capabilities of eBPF for dynamically programming the kernel the moment you need it. Cilium uses these eBPF primitives for high performance networking, deep observability across the stack but also deep into the node's OS, for tracing and observability. Last but not least, this level of insight enables Cilium to not only see just IPs and ports of containers - but namespaces. Now you can write your network policies, you can read your logs in the language of the cloud-native environments (namespaces, tags), instead of IPs which are volatile and don't really tell you anything without further digging.

VMblog:  You just released Cilium 1.14, and one of the most talked about features is mutual authentication support. What's the significance of mutual authentication in cloud-native network infrastructure and security?

Wolters:  Cilum already offered features for encryption, with the choice of Wireguard or IPsec. But the identity bit was missing. You could secure connections with policies, but if you wanted to bring your zero trust security to the next level, the workload identity still needed to be proven, so that you could trust it. In the past, this could only be achieved with yet another tool that needed to be evaluated, tested, integrated, maintained, etc. 

In the world of cloud-native, it's all about machine identity and automating the issuance of certificates for microservices. In Kubernetes, you have a different system and framework to manage identities and certificates. You have Vault for authentication, you have Cert-Manager for management of certificates, you have SPIFFE for implementing identity, and SPIRE for implementing SPIFFE APIs. With Cilium 1.14 we saw an opportunity to integrate all of this as native primitives in Cilium so that platform teams can seamlessly achieve mutual authentication across the Cilium Mesh.

VMblog:  Why is Cilium 1.14's mutual authentication support a breakthrough for platform engineering teams and how does it work?

Wolters:  Now, with Cilium's in-built mutual authentication, we take the burden of evaluating, integrating, maintaining, and operating yet another tool off of the platform engineers. We have the required mutual authentication inbuilt - and that backed industry standard backed mutual auth (SPIFFE, SPIRE). The platform engineers just have to add a few flags in their setup, and then can activate mutual auth with a simple policy for the app developer teams that require it. This simplicity and integration into the CNI can mean a lot for everyone who has extended security requirements - especially if they have to add mutual auth to existing workloads. Add 2 lines of YAML to your Cilium Network Policy, and that's it - your workload communication is now authorized with a mutual TLS handshake. It's effortless mutual authentication, and you can check it out in a Star Wars- themed lab that we created

VMblog:  The Cilium community references a concept of "networking beyond Kubernetes." What does that mean?

Wolters:  Kubernetes is awesome, and we love it. But not every workload is running on Kubernetes. And the larger the Kubernetes platform grows, the more connections it usually needs to the outside world. Think of bare metal servers running critical databases on-premise, or the many VMs running various services in the public cloud which have not (yet) been migrated to K8s, and might never be. Users still want to leverage Cilium's eBPF-based powers in those environments. If you own the platform, you want to connect workloads, whether they are running on Kubernetes or traditional VMs, or whatever infrastructure or cloud they are running on. 

Outside of K8s, rules and policies are usually based on IPs. eBPF lets Cilium achieve what was impossible using legacy networking and security technologies like iptables (traditional Linux firewalling) or traditional userspace proxies (like haproxy, nginx, etc.). And because eBPF operates at the Linux layer, and is not tied to underlying hardware or hypervisors, it can be the foundation for a consistent set of networking, security, and observability capabilities for workloads running on any cloud, private or public.


Published Friday, July 28, 2023 7:35 AM by David Marshall
Filed under: ,
There are no comments for this post.
To post a comment, you must be a registered user. Registration is free and easy! Sign up now!
<July 2023>