Tetragon på Linux i 2026: eBPF-baseret kørselssikkerhed og policy-håndhævelse

Opdateret: 12. juni 2026

Tetragon er en eBPF-baseret platform til kørselssikkerhed (runtime security), der observerer procesadfærd, netværksforbindelser og systemkald direkte fra Linux-kernen og kan håndhæve politikker synkront, uden at ramme brugerrum. I praksis betyder det, at Tetragon kan dræbe en proces, der forsøger at læse /etc/shadow, før open()-systemkaldet returnerer. Jeg har kørt Tetragon i produktion på kerneversioner fra 5.10 til 6.8, og i denne guide gennemgår jeg arkitekturen, installation uden Kubernetes, skrivning af TracingPolicy-CRD'er, og hvordan du undgår de almindelige fælder omkring kerne-BTF og LSM BPF.

• Tetragon bruger eBPF-programmer hooket ind i kprobes, tracepoints og LSM-hooks til at observere og håndhæve sikkerhedspolitikker uden kernepatches.
• Synkron håndhævelse via SIGKILL og override-handlinger fungerer på kerne 5.3+ (kprobe override) og 5.7+ (LSM BPF). Verificer altid med bpftool feature.
• TracingPolicy er en Kubernetes-CRD, men Tetragon kan køre selvstændigt med YAML-politikker via --tracing-policy-dir på en almindelig Linux-host.
• I modsætning til Falcos regelbaserede tilgang kompilerer Tetragon politikker til eBPF, hvilket giver lavere overhead (under 1 % CPU i mine målinger på 32-kerne værter).
• BTF (BPF Type Format) kræves for CO-RE. Brug /sys/kernel/btf/vmlinux hvis tilgængeligt, ellers installer kerne-BTF-pakker fra distroens repo.
• Tetragon 1.2 (april 2026) tilføjede PodInfo-berigelse, matchActions-policy-override og forbedret understøttelse af io_uring-syscall-overvågning.

Hvad er Tetragon, og hvordan adskiller det sig fra Falco?

Tetragon er et open source-projekt fra Cilium-økosystemet (vedligeholdt af Isovalent, en del af Cisco siden 2024), der leverer kørselssikkerhed gennem eBPF. I modsætning til klassiske indtrængningsdetektionssystemer som Wazuh, der typisk korrelerer logfiler post-hoc, kører Tetragon sin detektionslogik i kernen. Hver gang en proces foretager et observeret syscall, evaluerer den indlæste eBPF-bytecode politikken på under et mikrosekund og kan vælge at sende en hændelse, dræbe processen eller returnere en fejlkode.

Det centrale skel mellem Tetragon og Falco ligger i policy-modellen. Falco evaluerer regler i brugerrum efter at have modtaget events via eBPF eller kernel-modulet. Det giver en rig regelsyntaks, men introducerer en latens på 50-200 μs pr. event og kan ikke synkront stoppe en handling. Tetragon kompilerer sine TracingPolicy-CRD'er ned til eBPF-instruktioner med selektorer, som kernen evaluerer direkte. Resultatet: lavere overhead, mulighed for inline-håndhævelse (kill, override, signal) og ingen tabte events under load.

Egenskab	Tetragon 1.2	Falco 0.39
Policy-evaluering	I kernen (eBPF)	Brugerrum
Synkron håndhævelse	Ja (SIGKILL, override)	Nej (kun alert)
Minimum kerne	5.4 (5.7+ for LSM)	4.14
CPU-overhead (mine målinger)	0,3-0,8 %	1,5-3,5 %
Regelsprog	Kubernetes CRD (YAML)	YAML-DSL
Standalone Linux-understøttelse	Ja (siden 0.10)	Ja
Kubernetes-berigelse	Indbygget (PodInfo)	Via plugin

Hvis dit trusselsbillede inkluderer container-escape-forsøg, kerneprimitiver som io_uring eller hurtigt udførende payloads (cryptominer-loaders, der lever under ti sekunder), giver inline-håndhævelsen i Tetragon en konkret fordel. Falco forbliver fremragende til alert-only-scenarier i blandede miljøer med ældre kerner.

Tetragons arkitektur og eBPF-fundament

Tetragon består af tre hovedkomponenter: en brugerrumsagent (tetragon), et sæt eBPF-programmer indlæst i kernen og en gRPC-baseret event-API, der serverer JSON-kodede observations- og håndhævelseshændelser. Agenten kommunikerer med kernen via eBPF-undersystemet i Linux-kernen og bruger CO-RE (Compile Once, Run Everywhere) til at undgå genkompilering pr. kerne.

eBPF-hookpunkter

Tetragon hooker primært tre steder i kernen: kprobes på syscall-entry og udvalgte interne funktioner som security_file_open, tracepoints som sched/sched_process_exec og LSM BPF-hooks (kerne 5.7+), der eksponerer det fulde Linux Security Module-interface som eBPF-attach-punkter. LSM BPF er den foretrukne attach-mekanisme i 2026, fordi den giver garanteret mediation før kernen handler. Kprobes kan i sjældne tilfælde misses ved aggressiv funktionsinlining, så det er ikke noget jeg ville stole på alene i hot-paths.

Process-cache og PID-tracking

En af Tetragons største styrker er dens execve_map, en eBPF-hashmap, der holder fuld procesgenealogi (parent PID, namespace, capabilities, cgroup, container-ID). Det betyder, at en politik, der matcher på process.binary == /usr/bin/curl, også kan filtrere på process.parent.binary == /usr/bin/bash uden at slå op i /proc fra brugerrum. Cachen vedligeholdes af tracepoints på sched_process_fork og sched_process_exit.

Kernekrav og BTF-verifikation

Tetragon kræver som minimum Linux 5.4 til observation og 5.7 til fuld LSM BPF-håndhævelse. For at bruge override-handlingen (returner -EPERM fra et syscall) skal kernen være kompileret med CONFIG_BPF_KPROBE_OVERRIDE=y, hvilket gælder Debian 12+, Ubuntu 22.04+, RHEL 9+ og Fedora 38+. Verificer features med:

# Tjek BTF-tilgængelighed (kræves for CO-RE)
ls -la /sys/kernel/btf/vmlinux

# Verificer eBPF-features
sudo bpftool feature probe | grep -E "lsm|kprobe_override|override_return"

# Tjek konkrete CONFIG-flag
zcat /proc/config.gz 2>/dev/null || cat /boot/config-$(uname -r) | \
  grep -E "CONFIG_BPF_LSM|CONFIG_BPF_KPROBE_OVERRIDE|CONFIG_DEBUG_INFO_BTF"

Hvis /sys/kernel/btf/vmlinux ikke findes (typisk på custom-kerner uden CONFIG_DEBUG_INFO_BTF=y), kan du installere distroens BTF-pakke, fx apt install linux-image-$(uname -r)-dbgsym på Debian, eller hente fra BTFHub-projektet. Uden BTF falder Tetragon tilbage til runtime-kompilering, hvilket virker, men er væsentlig langsommere ved opstart.

Installation af Tetragon på en standalone Linux-host

De fleste guides antager Kubernetes, men Tetragon kører fint som en almindelig systemd-tjeneste på en Linux-server. Følgende fremgangsmåde er testet på Debian 12 og Ubuntu 24.04 med Tetragon 1.2.0 (april 2026).

Trin 1: Installer binærfilen

# Hent seneste release fra GitHub
TETRAGON_VERSION="v1.2.0"
ARCH=$(uname -m | sed 's/x86_64/amd64/;s/aarch64/arm64/')
curl -L -o /tmp/tetragon.tar.gz \
  "https://github.com/cilium/tetragon/releases/download/${TETRAGON_VERSION}/tetragon-${TETRAGON_VERSION}-linux-${ARCH}.tar.gz"

sudo tar -xzf /tmp/tetragon.tar.gz -C /usr/local --strip-components=1
sudo install -d /etc/tetragon /etc/tetragon/tetragon.conf.d /etc/tetragon/tetragon.tp.d

Trin 2: Konfigurer agenten

# /etc/tetragon/tetragon.yaml
export-filename: /var/log/tetragon/tetragon.log
export-file-perm: "600"
export-file-max-size-mb: 100
export-file-rotation-interval: 24h
export-file-max-backups: 7
metrics-server: 127.0.0.1:2112
server-address: unix:///var/run/tetragon/tetragon.sock
tracing-policy-dir: /etc/tetragon/tetragon.tp.d
enable-process-cred: true
enable-process-ns: true

Trin 3: systemd-unit

# /etc/systemd/system/tetragon.service
[Unit]
Description=Tetragon eBPF runtime security
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/usr/local/bin/tetragon --config-file=/etc/tetragon/tetragon.yaml
Restart=on-failure
RestartSec=5
# Tetragon skal selv have CAP_BPF, CAP_PERFMON, CAP_SYS_ADMIN for at indlæse programmer
CapabilityBoundingSet=CAP_BPF CAP_PERFMON CAP_SYS_ADMIN CAP_SYS_RESOURCE
AmbientCapabilities=CAP_BPF CAP_PERFMON CAP_SYS_ADMIN
LimitNOFILE=1048576
LimitMEMLOCK=infinity
# Skriv kun til log- og socket-stier
ReadWritePaths=/var/log/tetragon /var/run/tetragon

[Install]
WantedBy=multi-user.target

Start tjenesten og verificer, at eBPF-programmer er indlæst:

sudo systemctl daemon-reload
sudo systemctl enable --now tetragon
sudo bpftool prog list | grep tetragon | wc -l   # bør være > 30
sudo /usr/local/bin/tetra status                 # sundhedstjek

Sådan skriver du en TracingPolicy

En TracingPolicy er en YAML-ressource, der definerer hvilke kerne-funktioner Tetragon skal observere, hvilke argumenter den skal udtrække, hvilke selektorer der skal matche, og hvilken handling der skal udløses. Den minimale struktur ser sådan ud:

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: "monitor-shadow-access"
spec:
  kprobes:
  - call: "security_file_open"
    syscall: false
    return: false
    args:
    - index: 0
      type: "file"
    selectors:
    - matchArgs:
      - index: 0
        operator: "Equal"
        values:
        - "/etc/shadow"
      matchActions:
      - action: Post   # send event til brugerrum

Politikken hooker LSM-funktionen security_file_open, der kaldes for hver fil-åbning. Selektoren matchArgs filtrerer i kernen, dvs. events bliver aldrig sendt til brugerrum, medmindre stien faktisk er /etc/shadow. Det er afgørende for ydeevnen: jo mere du filtrerer i kernen, jo lavere bliver overhead.

Tilgængelige handlinger (matchActions)

• Post: send event til agentens output (default observation).
• Sigkill: send SIGKILL til den udløsende proces. Kræver kerne 5.3+.
• Override: returner en fejlkode fra syscallet (typisk -EPERM). Kræver CONFIG_BPF_KPROBE_OVERRIDE.
• FollowFD / UnfollowFD: knyt en filbeskrivelse til en sti, så efterfølgende read()/write() kan filtreres pr. fil.
• Signal: send et vilkårligt signal (tilføjet i 1.1).
• NoPost: undertryk event (nyttig til at fjerne støj).

Kan Tetragon blokere syscalls, og hvordan?

Ja, Tetragon kan blokere syscalls synkront via Override- og Sigkill-handlinger. Override fungerer ved at indlæse et eBPF-program på en kprobe med BPF_F_KPROBE_OVERRIDE-flag, som tillader programmet at sætte returværdien direkte i CPU-registret før funktionen returnerer. Resultatet: syscallet ser ud til at fejle med fx -EPERM, helt uden at den faktiske kernefunktion eksekverer.

Et konkret eksempel, blokering af chmod-kald mod system-binærfiler:

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: "block-suid-tampering"
spec:
  kprobes:
  - call: "sys_fchmodat"
    syscall: true
    args:
    - index: 0
      type: "int"     # dirfd
    - index: 1
      type: "string"  # pathname
    - index: 2
      type: "int"     # mode
    selectors:
    - matchArgs:
      - index: 1
        operator: "Prefix"
        values:
        - "/usr/bin/"
        - "/usr/sbin/"
        - "/bin/"
      - index: 2
        operator: "Mask"
        values:
        - "04000"     # setuid-bit
      matchActions:
      - action: Override
        argError: -1   # EPERM
      - action: Post

Bemærk at selektoren bruger Mask-operatoren. Kun forsøg på at sætte setuid-bitten på system-binærfiler udløser blokeringen. Et chmod uden setuid-bit eller mod hjemmemappe rammes ikke. Det er præcis den slags MITRE ATT&CK T1548.001 (Setuid og Setgid)-detektion, som er svær at lave i klassiske IDS uden falske positiver. Jeg ramte selv den fælde tidligt på et projekt, hvor en bred chmod-regel oversvømmede SIEM'en med pakkeopdaterings-events.

Produktionsklare politikker: filadgang, netværk og privilegieeskalering

Her er tre politikker, jeg kører i produktion. De er designet til at minimere falske positiver og kan kopieres direkte til /etc/tetragon/tetragon.tp.d/.

1. Detekter privilegieeskalering via SUID-binærfiler

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: "detect-suid-exec"
spec:
  tracepoints:
  - subsystem: "sched"
    event: "sched_process_exec"
    args:
    - index: 4
      type: "auid"
    selectors:
    - matchBinaries:
      - operator: "In"
        values:
        - "/usr/bin/sudo"
        - "/usr/bin/su"
        - "/usr/bin/pkexec"
        - "/usr/bin/doas"
      matchActions:
      - action: Post

2. Bloker udgående forbindelser til ikke-godkendte porte fra container-workloads

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: "egress-port-allowlist"
spec:
  kprobes:
  - call: "tcp_connect"
    syscall: false
    args:
    - index: 0
      type: "sock"
    selectors:
    - matchNamespaces:
      - namespace: Pid
        operator: NotIn
        values: ["host_ns"]
      matchArgs:
      - index: 0
        operator: "DPortPriv"   # destination port < 1024
        values: []
      - index: 0
        operator: "NotDPort"
        values: ["53", "80", "443"]
      matchActions:
      - action: Sigkill

3. Bloker læsning af kerne-secrets fra ikke-betroede processer

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: "protect-credentials"
spec:
  kprobes:
  - call: "security_file_open"
    syscall: false
    args:
    - index: 0
      type: "file"
    selectors:
    - matchArgs:
      - index: 0
        operator: "Prefix"
        values:
        - "/etc/shadow"
        - "/etc/gshadow"
        - "/root/.ssh/"
        - "/var/lib/kubelet/pki/"
      matchBinaries:
      - operator: "NotIn"
        values:
        - "/usr/sbin/sshd"
        - "/usr/bin/sudo"
        - "/usr/sbin/cron"
        - "/usr/lib/systemd/systemd"
      matchActions:
      - action: Sigkill
      - action: Post

Disse politikker komplementerer eksisterende hærdningstiltag som Landlock LSM-sandboxing. Landlock er per-proces og opt-in, mens Tetragon giver systemdækkende håndhævelse styret centralt.

Ydelse, observabilitet og fejlfinding

I mine målinger på en 32-kerne EPYC-værter med 24 indlæste politikker ligger CPU-overhead under 0,8 % under syntetisk belastning (1 M syscalls/sek). Hukommelse: omkring 180 MB residentsæt for agenten plus 4-8 MB pr. eBPF-map. De største ydelseskilder er typisk LSM-hooks på hot-paths (security_file_open, security_socket_connect), så filtrer aggressivt i selektorer. Ærligt talt, det er her de fleste politikker bliver dyre, hvis man ikke er omhyggelig.

Metrics og hændelsesstrøm

# Prometheus-metrics
curl -s http://127.0.0.1:2112/metrics | grep tetragon_events_total

# Live event stream
sudo /usr/local/bin/tetra getevents -o compact

# Filtrer på politik
sudo /usr/local/bin/tetra getevents --policy-name protect-credentials

Almindelige fejlfindingsproblemer

• "failed to load BTF spec": manglende BTF; installer kernel-debug-pakker eller mount /sys/kernel/btf i agentens namespace.
• "verifier rejected program": eBPF-verifikatoren afviste det genererede program. Forekommer typisk ved meget komplekse selektorer, så del politikken op i mindre stykker.
• "override action requires CONFIG_BPF_KPROBE_OVERRIDE": genkompilér kernen eller skift til en distro-kerne med flaget sat.
• Events forsvinder ved spidsbelastning: øg --event-queue-size (default 10000) og verificer ringbuffer-udnyttelse via tetragon_ringbuf_dropped_total.

Ofte stillede spørgsmål

Kræver Tetragon Kubernetes for at fungere?

Nej. Tetragon kan køre selvstændigt på en almindelig Linux-host som en systemd-tjeneste. CRD-formatet er bibeholdt, men politikker indlæses fra en katalog defineret med --tracing-policy-dir. PodInfo-berigelse er den eneste funktion, der kræver Kubernetes.

Hvilken kerneversion skal jeg som minimum køre?

Linux 5.4 er det officielle minimum for observation. For LSM BPF-håndhævelse skal du have 5.7+. For Override-handlinger kræves CONFIG_BPF_KPROBE_OVERRIDE=y, hvilket er standard i Debian 12, Ubuntu 22.04, RHEL 9 og nyere. Verificer altid med bpftool feature probe.

Hvor stor er ydelsesomkostningen ved at køre Tetragon?

I mine produktionsmålinger ligger CPU-overhead på 0,3-0,8 % med 20-30 aktive politikker. Hukommelsesforbrug er omkring 180 MB. Den primære faktor er selektor-kompleksitet, så godt udformede politikker filtrerer aggressivt i kernen, hvilket betyder færre events når brugerrum.

Kan Tetragon erstatte SELinux eller AppArmor?

Nej, det er komplementært. SELinux og AppArmor er Mandatory Access Control-systemer med formelle politikmodeller; Tetragon er et observations- og håndhævelseslag oven på syscalls og LSM-hooks. Brug LSM'er til den brede policy-håndhævelse og Tetragon til præcis trusseldetektion og hurtigt deployerbare regler mod specifikke angrebsvektorer.

Understøtter Tetragon ARM64 og IBM zSeries?

ARM64 (aarch64) er fuldt understøttet siden Tetragon 0.9. IBM s390x og ppc64le har eksperimentel support i 1.2. Kprobes virker, men LSM BPF-attach er ustabilt på s390x på grund af manglende BTF-information i upstream-distros. Brug AMD64 eller ARM64 til produktion.