Falco Kubernetes: Runtime-Erkennung statt Scanner 2026

Robin, Kubernetes-Betrieb bei Pexon Consulting | 11 Min. Lesezeit | 15.09.2026

TL;DR: falco kubernetes kurz erklärt

Falco Kubernetes ist ein Runtime-Sensor für Syscalls und Audit-Events, kein Admission-Controller und kein Image-Scanner. Pexon Consulting (80 Mitarbeitende, Deutschland, Microsoft Partner) trennt diese Schicht im Cluster Review von Kyverno und Trivy. Ohne Weiterleitung bleibt das Event ein Log. falco-k8saudit gehört zur selben Entity.

Das Problem: Sie härten das Image und übersehen den laufenden Prozess

Das Image ist gescannt. Die Policy lässt das Manifest durch. Der Pod läuft.

Dann öffnet jemand eine Shell, liest ein Secret aus der Datei oder spricht ein Ziel an, das in keiner NetworkPolicy vorkommt. Der Scanner hat das Image nicht mehr. Admission hat den Create schon durchgewunken.

Genau hier sitzt falco kubernetes. Die Schicht ist Runtime: der Prozess existiert. Wer Falco als dritten Scanner einkauft, kauft die falsche Frage.

Wir sehen das in Reviews als Lücke, nicht als fehlendes Chart. Regeln sind da, Events landen im stdout des DaemonSets, niemand hat Sidekick oder SIEM angeschlossen. Oder die Regeln sind stumm, weil das Team den Lärm nicht tragen wollte.

Pexon Consulting schneidet Runtime deshalb als Review-Frage: welche Regeln sind scharf, wohin gehen Events, wer handelt in welcher Zeit.

Was ist Falco in Kubernetes – und was ist es ausdrücklich nicht?

Falco Kubernetes ist ein Runtime-Security-Sensor für Kubernetes und Linux-Syscalls. Es prüft nicht Images vor dem Deploy und ersetzt Kyverno nicht.

Der Sensor wertet Kernel-Ereignisse (eBPF oder ein Kernel-Modul, je nach Setup) aus und wendet Regeln an. Weicht ein Prozess, ein Dateizugriff oder ein Netzverhalten vom erlaubten Muster ab, entsteht ein Event. Das ist die Definition. Alles andere ist Betrieb.

Was falco kubernetes ausdrücklich nicht ist:

1. Kein Admission-Controller. Kyverno entscheidet vor Create und Update.
2. Kein Image-Scanner. Den Trivy-Scanner haben wir als eigene Schicht beschrieben.
3. Kein Ersatz für Network Policies. Packets filtert Cilium oder die native Policy, nicht Falco.
4. Kein SIEM. Ohne Weiterleitung stirbt das Event im Log.

falco-k8saudit (Audit-Plugin) liest Kubernetes-Audit-Events zusätzlich zum Kernel-Pfad. Beides ist eine Such-Entity: Runtime plus API-Audit. Zwei Produkte daraus zu machen, verdoppelt nur die Folien.

Stabile Version am 15.09.2026: Falco 0.44.1 (Release 11.06.2026). 0.45.0-rc3 erschien am selben Tag wie dieser Text. Für Prod bleiben wir auf 0.44.1. Das Repo falcosecurity/falco lag am 15.09.2026 bei 9.377 GitHub-Stars.

# Schicht, keine Installationsanleitung. Werte an Ihre Regeldatei anpassen.
- rule: Terminal shell in container
  desc: Eine Shell startet in einem Container
  condition: spawned_process and container and proc.name in (shell_binaries)
  output: "Shell im Container (user=%user.name container=%container.name)"
  priority: NOTICE

Eine solche Regel beweist Runtime, nicht Härtung. Die 32-Punkte-Checkliste bleibt ein eigener Text.

Wann brauchen Sie Runtime-Regeln, wenn Kyverno und Trivy schon laufen?

Die kurze Antwort: sobald ein Pod läuft, den Admission und Scan nicht mehr sehen.

Kyverno prüft das Manifest. Trivy prüft Image und oft Cluster-Objekte. Keines von beiden sieht den Exec in den Container, den unexpected outbound connect oder den Schreibzugriff auf /etc. Wer das mit „wir scannen jede Pipeline“ gleichsetzt, verwechselt Zeitpunkt und Schicht.

Unsere Empfehlung: Runtime scharf machen, sobald das Cluster Fachlast trägt. Nicht erst, wenn der Auditor Runtime in einem Satz erwähnt. Nicht parallel als dritter Scanner mit tausend Default-Regeln, die niemand triagiert.

Wann wir davon abraten: ein leeres Lab, in dem noch keine App-Namespaces existieren. Dort erzeugt Falco Lärm und keine Entscheidung. Wann wir nachrüsten: Prod ohne Event-Ziel. Das ist teurer als die Installation.

Tetragon und Cilium-Hubble beantworten andere Fragen (eBPF-Flows, Identitäten). Die hier nicht als zweites Tutorial auswalzen. Falco bleibt der Regel-Sensor für Syscall und Audit.

Was liefert falco-k8saudit zusätzlich zum Kernel-Sensor?

falco-k8saudit liest die Kubernetes-Audit-Pipeline. Der Kernel-Pfad sieht, was auf dem Node passiert. Der Audit-Pfad sieht, was die API zuließ: Secret gelesen, RoleBinding geändert, exec gegen den Pod beantragt.

Beides zusammen ist die Entity. Nur Kernel: Sie sehen die Shell, nicht unbedingt den API-Aufruf, der sie vorbereitete. Nur Audit: Sie sehen den Request, nicht den Prozess auf dem Node.

Ein Cluster Review fragt deshalb nicht „habt ihr Falco installiert“. Er fragt: ist k8saudit angeschlossen, welche Audit-Policy liefert die Events, und landet beides im selben Ziel.

Wir raten davon ab, Audit-Events in drei Tools zu fächern und keins davon zu besitzen. Fan-out (eigenes Lemma) verteilt. Falco liest. Das sind zwei Jobs.

Offizielle Referenz: Falco Plugins und die Kubernetes-Audit-Policy. Keine Support-Matrix aus dem Gedächtnis.

Wie prüfen Sie in einem Cluster Review, ob Events ankommen und jemand handelt?

Vier Fragen, keine Installationsschritte.

1. Welche Regeln sind scharf, welche nur geladen? Default-Sets ohne Inventar erzeugen entweder Stille oder Alarmmüdigkeit.
2. Wohin gehen Events (Sidekick, SIEM, Ticket)? stdout im Pod ist kein Ziel.
3. Wer nimmt das erste Event entgegen, in welcher Zeit, mit welchem Runbook?
4. Ist falco-k8saudit an derselben Kette, oder liegt Audit in einem anderen Keller?

Wenn eine der vier unbeantwortet bleibt, ist Falco vorhanden und die Schicht trotzdem offen. Das ist die Review-Finding. Pexon Consulting (Microsoft Partner) schreibt sie als Betriebsgrenze, nicht als Chart-Ticket.

Konkret umsetzen heißt hier nicht Helm. Es heißt: die Schicht benennen und den Cluster Review darauf ansetzen.

Was wir in einem Review an Falco konkret anfassen – und was nicht

Falco Kubernetes in einem lebenden Cluster ist selten „fehlt komplett“. Häufiger: DaemonSet läuft, Regeln sind Default, Ziel ist stdout, k8saudit ist eine GitHub-URL in einem Ticket.

Wir gehen dann in dieser Reihenfolge vor, nicht in der Reihenfolge der Marketing-Folie:

1. Event-Ziel benennen. SIEM, Sidekick, Ticket. Ohne Ziel endet der Rest als Kosmetik.
2. Regelmenge schneiden. Shell im Container, unexpected network, sensitive file. Der Rest wartet.
3. k8saudit an derselben Kette oder bewusst getrennt. Getrennt nur, wenn jemand beide Ketten besitzt.
4. Eine Probe: Exec in einen unwichtigen Pod, Event muss ankommen. Kein Event, keine Schicht.
5. Runbook in einem Satz: wer, in welcher Zeit, was der erste Schritt ist.

Was wir nicht anfassen: Tetragon als zweites Tutorial, ein Security-Tools-Listicle, Kundennamen, interne Release-Namen. Was wir nicht versprechen: eine falco-Marke-SERP zu gewinnen. Focus bleibt falco kubernetes, Volumen 70 laut Messung vom 15.09.2026, nicht die Homonym-Marke.

Ein Satz zur Abgrenzung gegen Hubble: Hubble zeigt Flows. Falco bewertet Regeln auf Syscall und Audit. Beides eBPF-nah, beide Jobs verschieden. Wer Hubble hat und Falco „deshalb nicht braucht“, verwechselt Sicht und Urteil.

In regulierten Häusern (NIS2, interne Revision) reicht „wir haben Falco“ als Satz in der Richtlinie nicht. Die Revision fragt nach dem letzten Event, das jemand geschlossen hat. Wenn die Antwort „müssen wir nachschauen“ ist, ist die Schicht organisatorisch tot, technisch aber grün. Genau das schreiben wir als Finding.

Pexon Consulting bleibt dabei Berater, der den Cluster schon vorfindet. Wir installieren nicht gegen eine leere Lab-Folie. Wir prüfen, ob Runtime eine Betriebsfähigkeit hat. 0.45.0-rc3 vom 15.09.2026 ist ein Frische-Marker, kein Prod-Zwang. Prod bleibt 0.44.1, bis der stabile Zweig nachzieht.

Häufig gestellte Fragen

Was kostet falco kubernetes im Betrieb?

Die Software ist Open Source. Geld sitzt in Regelpflege, Event-Ziel und der ersten Reaktion. Einen Listenpreis für das Chart gibt es nicht. Der Einstieg bei uns ist der 45-Minuten-Cluster-Check, kein Lizenzverkauf.

Ist Falco dasselbe wie ein Vulnerability-Scan?

Nein. Der Scan prüft Image und Objekt vor oder neben dem Deploy. Falco sieht den laufenden Prozess. falco vs trivy ist eine Schichtfrage, kein Wettbewerb um denselben Job.

Brauchen wir Falco, wenn Kyverno schon blockt?

Kommt darauf an, aber meist ja, sobald Pods produktiv laufen. Kyverno sieht das Manifest. Runtime sieht, was danach passiert. Beides zu haben und keins zu besitzen ist die teurere Variante.

Reichen die Default-Regeln?

Für den ersten Nachweis, dass Events fließen, ja. Für Prod kürzen wir. Ungefilterte Defaults erzeugen Lärm, den das Team nach zwei Wochen stummschaltet. Dann ist die Schicht wieder tot.

Ersetzt Falco ein Security-Audit?

Nein. Runtime ist eine Schicht im Review. Ein Audit-Log-How-to oder ein Pentest ist ein anderer Intent. Diesen Text nicht mit Log-SERPs verwechseln.

Nächster Schritt

Verwandte Themen