↓ Skip to main content
EN

FR

EN

First Contact with Tetragon
  1. Tetragons/

First Contact with Tetragon

·1066 words·6 mins·
Joseph Ligier
Author
Joseph Ligier
CNCF ambassador | Kubestronaut 🐝
Table of Contents
Close Encounters with Tetragon - This article is part of a series.
Part 1: This Article

In this series of articles, we’ll explore Tetragon, a tool for securing Kubernetes clusters.

Here are the questions you’ll be able to answer after reading these articles:

  • Is this tool right for your Kubernetes cluster?
  • How do you install it?
  • How does it work?
  • How can you extend its core features?

In this first article, we’ll take a look at what Tetragon is all about.

Tetragon logo
Tetragon

What is Tetragon?
#

What’s This Thing?
#

Have you ever wondered what’s actually happening in each of your Kubernetes cluster pods at any given moment? Which processes are running? Who launched them? With what arguments?

And if one of your pods were compromised, how would you detect malicious behavior before it causes damage?

This is exactly where Tetragon comes in.

Tetragon can be considered an EDR (Endpoint Detection and Response) for Kubernetes. It provides visibility and detection of runtime processes and events—that is, all actions occurring inside a pod during its execution: process launches, file access, network connections, system calls, etc.

It was created by the company Isovalent, which is also behind Cilium, a CNI plugin for Kubernetes clusters. Like Cilium, Tetragon is based on eBPF.

eBPF logo

What is eBPF?
#

eBPF programs are programs that run within the Linux kernel. They are attached (or “hooked”) to specific points in the kernel. Every time the Linux kernel passes through a hook, the program is triggered.

eBPF hook
Example of eBPF hooks (represented by a bee)

These programs are relatively difficult to write because they require knowledge of low-level system programming.

If you want to learn more, I’ve created articles on how to program in eBPF with Rust without knowing eBPF or Rust.

eBPF in tetragon

How does Tetragon use eBPF?
#

Tetragon is essentially an “eBPF program generator”:

  • You create tracing policies (in YAML);
  • Tetragon translates them into eBPF programs and installs them in the Linux kernel of each server;
  • every time the event described in the tracing policies occurs, Tetragon will generate a log containing all available information.

This means you won’t need to know a low-level language. However, understanding eBPF and having a solid grasp of the Linux kernel is essential to becoming a Tetragon expert.

Cilium is also an eBPF program generator, but it creates network eBPF hooks (specifically TC and XDP types) at the network interface level. Tetragon generates other types of eBPF programs (tracing and security) such as Tracepoints, kProbes, LSM, etc. Every action detected in the kernel that matches your policy is an event, the core of runtime detection.

Now that we’ve covered how Tetragon works in theory, let’s move on to the practical side.

Tetragon Demo 🚀
#

To follow along with the demo in the rest of this article, you’ll need access to a Linux system. I installed it on a Lima VM on my Mac. If you’re already running Linux, I recommend installing it on a Linux VM to avoid messing up your personal environment.

Installation on a Server
#

We’ll show you how to install Tetragon outside of Kubernetes. This will help you better understand how it works without needing to know Kubernetes.

We’ll install the latest version of Tetragon (1.6.0 at the time of writing). We’ll create variables so the installation remains compatible with new versions:

VERSION=v1.6.0
ARCH=amd64 #other choice arm64

Feel free to check if there are newer versions.

We download and extract the tar.gz file:

curl -LO https://github.com/cilium/tetragon/releases/download/$VERSION/tetragon-${VERSION}-${ARCH}.tar.gz
tar -xvf tetragon-${VERSION}-${ARCH}.tar.gz

We then install Tetragon:

cd tetragon-${VERSION}-${ARCH}/
sudo ./install.sh

This will simply copy the binaries to the correct directories, configure systemd, etc.

To uninstall it, there is another script: uninstall.sh.

Let’s Take a Look at Tetragon Events
#

Even before you create your own tracing policies, Tetragon already generates default events. Using the official tetra command-line tool, you can retrieve these events in real time:

tetra getevents -o compact

With this command, you’ll see the logs generated by Tetragon. Here, without any configuration, you’ll be able to observe:

  • all processes starting in real time (🚀)
  • all processes terminating in real time (💥)

Thus, upon installation, Tetragon already injects eBPF programs into the Linux kernel, allowing it to log the entire lifecycle of processes.

For example, here is what I see in my VM:

🚀 process lima-default /usr/sbin/iptables -t nat -S
💥 exit    lima-default /usr/sbin/iptables -t nat -S 0
🚀 process lima-default /usr/bin/touch /var/lib/apt/periodic/upgrade-stamp
🚀 process lima-default /usr/bin/apt-config shell MaxAge APT::Archives::MaxAge
🚀 process lima-default /usr/bin/dpkg --print-foreign-architectures
🚀 process lima-default /usr/bin/apt-config shell MaxAge APT::Periodic::MaxAge
🚀 process lima-default /usr/bin/dpkg --print-foreign-architectures
🚀 process lima-default /usr/bin/apt-config shell MinAge APT::Archives::MinAge
🚀 process lima-default /usr/sbin/iptables -t nat -S
💥 exit    lima-default /usr/sbin/iptables -t nat -S 0
  • The first column is an emoji indicating the process status (🚀 or 💥)
  • The second column is its translation (process or exit)
  • The third column is the server name
  • The fourth column is the command name and its arguments
  • If the process is in exit state, the last column is the command’s exit code (0 if everything goes well)

You can also change the standard output to generate more standard logs in JSON format, and then all you need to do is install tools like Prometheus, Grafana, or Fluentbit to process them asynchronously.

In this series of articles, we won’t be covering the configuration of monitoring tools, which is essential for production environments (Example article on the topic). Instead, we will focus primarily on Tetragon and its features.

Introduction to Tracing Policies
#

Installing Tetragon already allows you to observe quite a few things. However, certain more specific pieces of information are not automatically available, for example:

  • knowing which pod is communicating with a specific IP address;
  • checking whether a particular file has been modified.

To do this, you need to define tracing policies. Furthermore, these tracing policies allow you to go even further: in addition to monitoring, Tetragon can take action before the binary has even finished executing.

Tetragon can then act proactively by preventing a process from accessing a resource, for example.

There are quite a few examples you can explore in the official documentation. Feel free to check it out if you’d like to explore the possibilities offered by Tracing Policies further.

We’ve introduced Tetragon:

  • how it works in general;
  • how to install it on a Linux server;
  • its default behavior;
  • and how to extend its capabilities using Tracing Policies.

In the next section, we’ll install Tetragon in its natural environment: Kubernetes.

Close Encounters with Tetragon - This article is part of a series.
Part 1: This Article