SCTP on Cilium

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.

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: Traffic splitting HTTP request header rewrite HTTP response header rewrite Cross-namespace routing

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.

Kubernetes does not natively support gRPC Load Balancing out of the box. Learn how to use Cilium’s embedded Envoy proxy to achieve load-balancing for L7 services, with a simple annotation.

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.

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.

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.

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.

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.

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 track, we provide you a fully fledged Cilium installation on a small cluster, together with a few challenges to solve. See yourself how Cilium works, and how it can help you securing your moon-sized battlestation in a “Star Wars”-inspired challenge.

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 Cilium Tetragon. Cilium 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 Cilium 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!

In this scenario, we are going to show how Isovalent Cilium Enterprise 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 Cilium Enterprise can 1) identify the version of TLS being used, informing us if an obsolete and insecure version is being used, 2) report on the cipher being used and 3) export events in JSON format to SIEM.

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

This lab provides an introduction to Isovalent Cilium Enterprise 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.

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.

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.

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.

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 Cilium Enterprise: 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.