Labs Library

Kubernetes changes the way we think about networking. In an ideal Kubernetes world, the network would be entirely flat and all routing and security between the applications would be controlled by the Pod network, using Network Policies. In many Enterprise environments, though, the applications hosted on Kubernetes need to communicate with workloads living outside the Kubernetes cluster, which are subject to connectivity constraints and security enforcement. Because of the nature of these networks, traditional firewalling usually relies on static IP addresses (or at least IP ranges). This can make it difficult to integrate a Kubernetes cluster, which has a varying —and at times dynamic— number of nodes into such a network. Cilium’s Egress Gateway feature changes this, by allowing you to specify which nodes should be used by a pod in order to reach the outside world.

Encryption is required for many compliance frameworks. Kubernetes doesn’t natively offer pod-to-pod encryption. To offer encryption capabilities, it’s often required to implement it directly into your applications or deploy a Service Mesh. Both options add complexity and operational headaches. Cilium actually provides two options to encrypt traffic between Cilium-managed endpoints: IPsec and WireGuard. In this lab, you will be installing and testing both features and will get to experience how easy it is to encrypt data in transit with Cilium. You will also see how to encrypt specific pod-to-pod traffic using Isovalent Enterprise for Cilium.

In this lab, you will learn how to leverage KubeVirt to run virtual machines alongside containers in Kubernetes, while using Cilium for secure, scalable networking. The lab will guide you through integrating VMs with Kubernetes’ CNI via Cilium, implementing Zero Trust security policies, and enabling advanced networking features like live migration. By the end, you’ll understand how Cilium and KubeVirt provide seamless networking for both containerized and virtualized workloads in a cloud-native environment.

Cilium introduced support for Local Redirect Policies in version 1.11, providing a powerful mechanism to control traffic routing within your Kubernetes cluster. Since then, additional improvements have expanded the possibilities for topology-aware load balancing and node-local optimizations. In this lab, using a Star Wars-inspired theme based on the iconic “These are not the droids you’re looking for” scene, you’ll explore how these features can enhance service performance and reduce latency. You’ll start by deploying a sample application, then progress through hands-on exercises that demonstrate the use of Kubernetes’ new trafficDistribution feature and Cilium’s Local Redirect Policies to redirect traffic locally within nodes. Finally, you’ll implement a local DNS cache on each node to improve DNS resolution times. By the end of this lab, you’ll have a practical understanding of how to use these advanced traffic management features to optimize the flow of traffic across your cluster.

BGP support was initially introduced in Cilium 1.10 and subsequent improvements have been made since, such as the recent introduction of IPv6 support in Cilium 1.12. In Cilium 1.13, that support was enhanced with the introduction of Load Balancer IPAM and BGP Service address advertisements. In this lab, you will learn about both these new features and how they can simplify your network connectivity operations.

BGP support was initially introduced in Cilium 1.10 and subsequent improvements have been made since, such as the recent introduction of IPv6 support in Cilium 1.12 and Service IP Advertisements in Cilium 1.13. In Cilium 1.14, we introduced more BGP features, including: – BGP Timers Customization – eBGP Multihop – BGP Graceful Restart In Cilium 1.15, the following features are being added: – BGP Peering Security with MD5 – BGP Communities Support In this lab, the user will learn about both these new features and how they can simplify their network connectivity operations.

Learn how to connect your Kubernetes Clusters with your on-premises network using BGP. As Kubernetes becomes more pervasive in on-premise environments, users increasingly have both traditional applications and Cloud Native applications in their environments. In order to connect them together and allow outside access, a mechanism to integrate Kubernetes and the existing network infrastructure running BGP is needed. Cilium offers native support for BGP, exposing Kubernetes to the outside and all the while simplifying users’ deployments.

This lab is a follow-up to the introductory Cilium Gateway API lab. We highly recommend you do the Cilium Gateway API lab first, if you haven’t done it already. In this one, you will learn about some additional specific use cases for Gateway API: HTTP request & response header rewrite HTTP redirect, rewrite and mirror Cross-namespace routing gRPC routing East-West L7 routing with GAMMA

eBPF is the new standard to program Linux kernel capabilities in a safe and efficient manner without requiring to change kernel source code or loading kernel modules. It has enabled a new generation of high performance tooling to be developed covering networking, security, and observability use cases. The best way to learn about eBPF is to read the book “What is eBPF” by Liz Rice. And the best way to have your first experience with eBPF programming is to walk through this lab, which takes the opensnoop example out of the book and teaches you to handle an eBPF tool, watch it loading its components and even add your own tracing into the source eBPF code.

Security Observability is a new paradigm that utilizes eBPF, a Linux kernel technology, to allow Security and DevOps teams, SREs, Cloud Engineers, and Solution Architects to gain real-time visibility into Kubernetes and helps to secure your production environment with Tetragon. Tetragon is an open source Security Observability and Runtime Enforcement tool from the makers of Cilium. It captures different process and network event types through a user-supplied configuration to enable security observability on arbitrary hook points in the kernel; then translates these events into actionable signals for a Security Team. The best way to learn about Security Observability and Cilium Tetragon is to read the book “Security Observability with eBPF” by Jed Salazar and Natalia Reka Ivanko. And the best way to have your first experience with Tetragon is to walk through this lab, which takes the Real World Attack example out of the book and teaches you how to detect a container escape step by step!

Envoy is a powerful L7 proxy which can be used for many Service Mesh needs. Cilium uses Envoy for L7 Network Policies, L7 observability, L7 internal load-balancing, and even allows users to configure Envoy for their own needs.

Multicast support in Kubernetes has finally come to Cilium! In this lab, you will discover how to set it up, take advantage of it, and observe multicast traffic in Kubernetes, using Cilium and Tetragon in Isovalent Enterprise.

Migrating to Cilium from another CNI is a very common task. But how do we minimize the impact during the migration? How do we ensure pods on the legacy CNI can still communicate to Cilium-managed during pods during the migration? How do we execute the migration safely, while avoiding a overly complex approach or using a separate tool such as Multus? With the use of the new Cilium CRD CiliumNodeConfig, running clusters can be migrated on a node-by-node basis, without disrupting existing traffic or requiring a complete cluster outage or rebuild. In this lab, you will migrate your cluster from Calico to Cilium.

In this short lab, you will learn about Gateway API, a new Kubernetes standard on how to route traffic into a Kubernetes cluster. The Gateway API is the next generation of the Ingress API. Gateway API addresses some the Ingress limitations by providing an extensible, role-based and generic model to configure advanced L7 traffic routing capabilities into a Kubernetes cluster. In this lab, you will learn how you can use the Cilium Gateway API functionality to route HTTP and HTTPS traffic into your Kubernetes-hosted application, including load balancing / traffic splitting and TLS passthrough or termination.

In Cilium 1.13, we introduced support for LoadBalancer IP Address Management (LB-IPAM) and the ability to allocate IP addresses to Kubernetes Services of the type LoadBalancer. Cloud providers natively provide this feature for managed Kubernetes Services and therefore this feature is more one for self-managed Kubernetes deployments or home labs. LB-IPAM works seamlessly with Cilium BGP: the IP addresses allocated by Cilium can be advertised to BGP peers to integrate your cluster with the rest of your network. For users who do not want to use BGP or that just want to make these IP addresses accessible over the local network, we are introducing a new feature called L2 Announcements in Cilium 1.14. When you deploy a L2 Announcement Policy, Cilium will start responding to ARP requests from local clients for ExternalIPs and/or LoadBalancer IPs. Typically, this would have required a tool like MetalLB but Cilium now natively supports this functionality. Try it in this new lab!

Ever since its inception, Cilium has supported Kubernetes Network Policies to enforce traffic control to and from pods at L3/L4. But Cilium Network Policies even go even further: by leveraging eBPF, it can provide greater visibility into packets and enforce traffic policies at L7 and can filter traffic based on criteria such as FQDN, protocol (such as kafka, grpc), etc… Creating and manipulating these Network Policies is done declaratively using YAML manifests. What if we could apply the Kubernetes Network Policy operating model to our hosts? Wouldn’t it be nice to have a consistent security model across not just our pods, but also the hosts running the pods? Let’s look at how the Cilium Host Firewall can achieve this. In this lab, we will install SSH on the nodes of a Kind cluster, then create Cluster-wide Network Policies to regulate how the nodes can be accessed using SSH. The Control Plane node will be used as a bastion to access the other nodes in the cluster.

With the rise of Kubernetes adoption, an increasing number of clusters is deployed for various needs, and it is becoming common for companies to have clusters running on multiple cloud providers, as well as on-premise. Kubernetes Federation has for a few years brought the promise of connecting these clusters into multi-zone layers, but latency issues are more often than not preventing such architectures. Cilium Cluster Mesh allows you to connect the networks of multiple clusters in such as way that pods in each cluster can discover and access services in all other clusters of the mesh, provided all the clusters run Cilium as their CNI. This allows to effectively join multiple clusters into a large unified network, regardless of the Kubernetes distribution each of them is running. In this lab, we will see how to set up Cilium Cluster Mesh, and the benefits from such an architecture.

Achieving zero-trust network connectivity via Kubernetes Network Policy is complex as modern applications have many service dependencies (downstream APIs, databases, authentication services, etc.). With the “default deny” model, a missed dependency leads to a broken application. Moreover, the YAML syntax of Network Policy is often difficult for newcomers to understand. This makes writing policies and understanding their expected behavior (once deployed) challenging. Enter Isovalent Enterprise for Cilium: it provides tooling to simplify and automate the creation of Network Policy based on labels and DNS-aware data from Cilium Hubble. APIs enable integration into CI/CD workflows while visualizations help teams understand the expected behavior of a given policy. Collectively, these capabilities dramatically reduce the barrier to entry to creating Network Policies and the ongoing overhead of maintaining them as applications evolve. In this hands-on demo we will walk through some of those challenges and their solutions.

In this short hands-on discovery lab designed for Platform and DevOps Engineers, you will learn, in 15 minutes, several Cilium features, including: Observability Built-in Ingress and Gateway API Performance Monitoring Integration with Grafana And more!

In this short hands-on discovery lab designed for Cloud Network Engineers, you will learn, in 15 minutes, several Cilium networking features, including:   Dual Stack IPv4/IPv6 support with Cilium BGP Load-Balancer IPAM L2 Service Announcement Egress Gateway And more!

In this short hands-on discovery lab designed for SecOps Engineers, you will learn, in 15 minutes, several Cilium and Tetragon security features, including: Network Observability Network Policies Transparent Encryption Mutual Authentication Runtime Security Visibility and Enforcement with Tetragon and more!

Kubernetes is built on the premise that a Pod should belong to a single network. While this approach may work for the majority of use cases, enterprise and telco often require a more sophisticated and flexible networking model. There are many use cases where a Pod may require attachments to multiple networks with different properties via different interfaces. With Cilium Multi-Networking, you can connect your Pod to multiple networks, without having to compromise on security and observability. Start this interactive hands-on lab to experience the benefits of Cilium Multi-Networking.

BIG TCP – a revolutionary networking technology – is now available with Cilium to provide enhanced network performances for your nodes. In this interactive hands-on lab, you will learn how BIG TCP can improve throughput by 40-50% in your network.

In this interactive tutorial, learn eBPF with Liz Rice! Learn how to write your first eBPF Hello World program and dive into all the key concepts and tools of eBPF such as eBPF maps, bytecode, bpftool, xdp and the eBPF verifier.

Introduced in Cilium 1.14 is support for a much-requested feature: mutual authentication. From its inception, we looked at delivering an optimal effortless user experience to achieve mutual authentication. The result is simple: add 2 lines of YAML to your Cilium Network Policy, and that’s it – your workload communication is now secured with a mutual TLS handshake. Try it in this new Star Wars-inspired lab!

This lab provides an introduction to Isovalent Enterprise for Cilium capabilities related to connectivity observability. This track primarily focuses on Hubble Flow events that provide label-aware, DNS-aware, and API-aware visibility for network connectivity within a Kubernetes environment using Hubble CLI, Hubble UI and Hubble Timescape, which provides historical data for troubleshooting.

In this scenario, we are going to simulate the exploitation of a nodejs application, with the attacker spawning a reverse shell inside of a container and moving laterally within the Kubernetes environment.   We will demonstrate how the combined Process and Network Event Data: identify the suspicious Late Process Execution tie the suspicious processes to a randomly generated External Domain Name trace the Lateral Movement and Data Exfiltration of the attacker post-exploit

One of the most important thing when running applications in an environment like Kubernetes is to have good observability and deep insights. However, for many organizations it can be challenging to update existing applications to provide the observability you need. With Cilium, you can use the Hubble Layer 7 visibility functionality to get Prometheus metrics for your application without having to modify it at all. In this lab you will learn how Cilium can provide metrics for an existing application with and without tracing functionality, and how you can use Grafana dashboards provided by Cilium to gain insight into how your application is behaving.

Migrating to Cilium from another CNI is a very common task. But how do we minimize the impact during the migration? How do we ensure pods on the legacy CNI can still communicate to Cilium-managed during pods during the migration? How do we execute the migration safely, while avoiding a overly complex approach or using a separate tool such as Multus? With the use of the new Cilium CRD CiliumNodeConfig, running clusters can be migrated on a node-by-node basis, without disrupting existing traffic or requiring a complete cluster outage or rebuild. In this lab, you will migrate your cluster from an existing CNI to Cilium. While we use Flannel in this simple lab, you can leverage the same approach for other CNIs.

Learn how simple IPv6 can be installed and operated with Cilium and Hubble. With Kubernetes’ IPv6 support improving in recent releases and Dual Stack Generally Available in Kubernetes 1.23, it’s time to learn about IPv6 on Kubernetes. You might be wondering “How on Earth am I going to be able to operate this?” Good news – you’re in the right place. This lab will walk you through how to deploy a IPv4/IPv6 Dual Stack Kubernetes cluster and install Cilium and Hubble to benefit from their networking and observability capabilities. In particular, visibility of IPv6 flows is absolutely essential. IPv6’s slow adoption is primarily caused by fears it would be hard to operate and manage. As you will see, a tool such as Hubble will help operators visualize and understand their IPv6 network better.

Creating the right Network Policies can be difficult. In this lab, you will use Hubble metrics to build a Network Policy Verdict dashboard in Grafana showing which flows need to be allowed in your policy approach.

SCTP (Stream Control Transmission Protocol) is a transport-layer protocol used for communication between applications. It is similar to TCP, but it provides additional features such as multi-homing and message fragmentation. Applications that require reliable, ordered delivery of data, but also need the ability to handle multiple streams of data simultaneously can use SCTP. SCTP is primarily used by service providers and mobile operators. While SCTP support for Kubernetes Services, Endpoint and NetworkPolicy was introduced in Kubernetes 1.12, you still need a CNI to support it. Good news: basic support for SCTP was introduced in Cilium 1.13!

You already know that Cilium accelerates networking, and provides security and observability in Kubernetes, using the power of eBPF. Now Cilium is bringing those eBPF strengths to the world of Service Mesh. Cilium Service Mesh features eBPF-powered connectivity, traffic management, security and observability. In this lab, you will learn how you can use Cilium to deploy Ingress resources to dynamically configure the Envoy proxy provided with the Cilium agent. And all of the above without any Envoy sidecar injection into your pods!

Cilium is an open source software for transparently securing the network connectivity between application services deployed using Linux container management platforms like Docker and Kubernetes. At the foundation of Cilium is a new Linux kernel technology called eBPF, which enables the dynamic insertion of powerful security visibility and control logic within Linux itself. Because eBPF runs inside the Linux kernel, Cilium security policies can be applied and updated without any changes to the application code or container configuration. In this interactive, hands-on lab we provide you a fully fledged Cilium installation on a small cluster and a few challenges to solve. See for yourself how Cilium works and how it can help you by securing a moon-sized battlestation in a “Star Wars”-inspired challenge.

In this scenario, we are going to show how Isovalent Enterprise for Cilium can provide visibility into TLS traffic. In security audits, a company or team has to verify their application protects data in transit and doesn’t leak information during communication, especially when data leaves a sensitive internal network. Mechanisms like TLS ensure that data is encrypted in transit, but verifying that a TLS configuration is secure becomes a challenge for most companies. In this lab, you will learn how Isovalent Enterprise for Cilium can: Identify the version of TLS being used, informing us if an obsolete and insecure version is being used Report on the cipher being used Export events in JSON format to SIEM