Mitglied werden – KI-Tutor mit vollen Antworten

Training Module

Container & Kubernetes Runtime Security mit Falco

In diesem 115-Minuten-Modul installiert ihr falco per DaemonSet auf einem selbst gebauten lokalen kind-Cluster und beobachtet damit Syscalls laufender Container in Echtzeit, ohne eine Zeile der überwachten Anwendung zu ändern. Im ersten Hands-on-Block provoziert ihr mit kubectl exec einen echten Alarm der Falco-Standardregel „Terminal shell in container“ und lest den Alarm-Output Feld für Feld: Nutzer, Befehl, Container, Priorität. Im zweiten Hands-on-Block schreibt ihr eine eigene Falco-Regel für einen selbst gebauten, eigentlich rein statischen Webserver-Container, der laut Anwendungsfall nie selbst eine abgehende Verbindung aufbauen sollte, provoziert die Anomalie gezielt mit wget und seht den Alarm live im Log, während ein harmloser Kontrolllauf ohne wget zu Recht stumm bleibt. Zum Abschluss ordnet ihr Runtime Security als dritte Pipeline-Ebene gegenüber Build-Zeit (Image Scanning) und Deploy-Zeit (Admission Control) ein. Die Session läuft komplett lokal mit kind: kein Cloud-Account, keine Kostenwirkung, die Trainingsumgebung muss allerdings privilegierte Container zulassen, dazu mehr im Buchungsgespräch.

Academy Briefing vereinbaren

Oder sofort per Mail an mail@mhm-dl.de

Format

115 Minuten, live (remote oder vor Ort), Input & zwei vollständige Hands-on-Blöcke auf einem selbst gebauten lokalen kind-Cluster

Teilnehmende

DevOps-/Platform-Engineers und Security-Verantwortliche, die nach Image Scanning und Admission Control jetzt die Runtime-Ebene hands-on schließen wollen

Voraussetzungen

Kein eigener Cloud-Account nötig: alles läuft lokal. Docker, kubectl und kind lokal installiert, Kubernetes-Grundkenntnisse vorausgesetzt, Trainingsumgebung muss privilegierte Container zulassen.

Warum dieses Training für deine Organisation wirkt

Dritte Ebene, echtes Hands-on

Wo die Tool-Taxonomie „Container Runtime Security“ nur als Stichwort nennt, installiert und bedient ihr hier Falco selbst: ein echter Alarm auf echten Syscalls eines laufenden Containers, kein Begriffsabriss.

Standardregel gegen eigene Regel

Ihr seht zuerst, dass Falco mit seinem Standard-Regelwerk sofort etwas erkennt, und lernt danach am selben Cluster, wie eine eigene, auf eure Anwendung zugeschnittene Regel entsteht, inklusive des Belegs, dass sie nicht pauschal jede Aktivität meldet.

Drei Zeitpunkte, drei Fragen

Image Scanning prüft vor dem Deployment, Admission Control entscheidet beim Start eines Pods, Falco beobachtet, was ein bereits laufender Container tatsächlich tut. Keine der drei Ebenen ersetzt eine andere.

Was Teilnehmende mitnehmen

  • Container Runtime Security als dritte Pipeline-Ebene (Runtime/Deployment) einordnen, abgegrenzt von Build-Zeit (Image Scanning) und Deploy-Zeit (Admission Control), Rückverweis auf die Tool-Taxonomie aus DevSecOps Werkzeuge & Compliance, keine Doppelerklärung.
  • eBPF-Grundprinzip verstehen: Kernel-Syscalls ohne Codeänderung der überwachten Anwendung beobachten, Unterschied klassischer Kernel-Modul-Treiber gegenüber dem modernen eBPF-Treiber (CO-RE).
  • Falco per privilegiertem DaemonSet in einem selbst gebauten kind-Cluster installieren und die Grundbegriffe der Rule-Engine lesen: condition, output, priority, macro.
  • Mit kubectl exec einen interaktiven Shell-Zugriff provozieren, den dadurch ausgelösten Standard-Alarm „Terminal shell in container“ im Falco-Log lesen und Nutzer, Befehl und Container dem Alarm-Output zuordnen.
  • Eine eigene Regel für einen konkreten Anwendungsfall schreiben (unerwartete abgehende Verbindung aus einem eigentlich rein statischen Webserver-Container), die Syntax (evt.type, container.name, Formatstring im output) korrekt anwenden.
  • Die Anomalie gezielt mit wget provozieren, den Alarm live im Log sehen, und mit einem Kontrolllauf ohne wget belegen, dass die Regel nicht pauschal jede Aktivität meldet.
  • Container Runtime Security gegenüber Build-Zeit und Deploy-Zeit klar abgrenzen, inklusive der jeweils passenden Reaktion (Fix vor dem Build, Ablehnung beim Start, Alarm während des Laufs).

Für wen dieses Modul ideal ist

  • • DevOps-/Platform-Engineers und Security-Verantwortliche, die nach Image Scanning und Admission Control jetzt die Runtime-Ebene hands-on statt nur begrifflich schließen wollen
  • • SOC-/Incident-Response-nahe Rollen, die verstehen wollen, wie ein Laufzeit-Alarm in Kubernetes technisch überhaupt entsteht
  • • Teams, die eine eigene, auf ihre Anwendung zugeschnittene Falco-Regel schreiben wollen statt nur Standard-Regeln ungeprüft zu übernehmen

Rahmendaten

  • • Dauer: 115 Minuten live (remote oder vor Ort)
  • • Format: Input, Live-Demo, zwei vollständige Hands-on-Blöcke auf einem selbst gebauten lokalen kind-Cluster
  • • Voraussetzungen: Kein eigener Cloud-Account nötig, Docker/kubectl/kind lokal installiert, Kubernetes-Grundkenntnisse vorausgesetzt, Trainingsumgebung muss privilegierte Container zulassen (Details im Buchungsgespräch)

Modulaufbau & Agenda

  1. Kick-off & Abgrenzung (10 min): Format, Ablauf und Abgrenzung zu DevSecOps Werkzeuge & Compliance (dort „Container Runtime Security“ nur als Stichwort in der Tool-Taxonomie), zu Container Image Scanning & Vulnerability Management mit Trivy (dort Binary/Artifact-Ebene vor dem Deployment) und zu Kubernetes Admission Controllers & Policy Engines sowie CI/CD Policy Gates (dort Deploy-Zeit-Entscheidung beim Start eines Pods, nicht Laufzeit-Verhalten danach). Hier stattdessen echtes Runtime-Hands-on auf einem laufenden Cluster.

  2. Konzept: eBPF & Falco-Architektur (25 min): Syscalls als gemeinsamer Nenner jedes Container-Verhaltens, eBPF als Kernel-Instrumentierung ohne Codeänderung der überwachten Anwendung, klassischer Kernel-Modul-Treiber gegenüber dem modernen eBPF-Treiber (CO-RE), Falco-Architektur (Treiber → Events → Rule-Engine → Output), Rule-Grundbegriffe condition/output/priority/macro, warum ein DaemonSet (ein Falco-Pod pro Node) und warum privilegierter Zugriff nötig ist.

  3. Hands-on 1: Falco-Installation & erster Alarm (35 min): einen lokalen kind-Cluster aufbauen, den Demo-Webserver-Container deployen, Falco per DaemonSet-Manifest installieren, mit kubectl exec -it einen interaktiven Shell-Zugriff provozieren, den Standard-Alarm „Terminal shell in container“ im Falco-Log lesen und den Feldern Nutzer/Befehl/Container zuordnen, Abgleich mit der Musterlösung.

  4. Hands-on 2: Eigene Regel schreiben & Anomalie provozieren (35 min): eine eigene Falco-Regel schreiben, die eine unerwartete abgehende Verbindung aus dem eigentlich rein statischen Demo-Webserver-Container erkennt, die Regel per ConfigMap nachladen, die Anomalie gezielt mit wget provozieren und den Alarm live sehen, danach mit einem Kontrolllauf ohne wget belegen, dass die Regel nicht pauschal jede Aktivität meldet, Abgleich mit der Musterlösung.

  5. Fazit & Ausblick (10 min): Runtime Security als dritte Pipeline-Ebene gegenüber Build-Zeit und Deploy-Zeit zusammenfassen, kurzer Ausblick auf Alert-Weiterleitung (z. B. an ein SIEM) ohne eigenes Hands-on dazu, offene Fragen, Kontaktmöglichkeit.

Abgrenzung: Dieses Modul behandelt bewusst keine erneute Tool-Taxonomie oder Compliance-Governance (dafür DevSecOps Werkzeuge & Compliance), kein Container Image Scanning auf Binary/Artifact-Ebene (dafür Container Image Scanning & Vulnerability Management mit Trivy), keine Admission-Webhook-Durchsetzung beim Deployment (dafür Kubernetes Admission Controllers & Policy Engines und CI/CD Policy Gates) und keine SIEM-/Detection-as-Code-Vertiefung (eigenständiges mögliches Folgethema, hier nur als Ausblick erwähnt, ohne Vertiefung).

Hands-on Inhalte (Auszug)

eBPF & Falco-Architektur

  • Syscalls als gemeinsamer Nenner jedes Container-Verhaltens
  • Moderner eBPF-Treiber (CO-RE) gegenüber klassischem Kernel-Modul
  • Kein Cloud-Account, keine Kostenwirkung

Falco-Installation & erster Alarm

  • Falco per DaemonSet auf einem selbst gebauten kind-Cluster installieren
  • kubectl exec -it provoziert die Standardregel „Terminal shell in container“
  • Alarm-Output Feld für Feld lesen: Nutzer, Befehl, Container, Priorität

Eigene Regel schreiben

  • Eigene Regel für unerwartete abgehende Verbindung aus dem Demo-Webserver-Container
  • condition/output/priority selbst formulieren
  • Regel per ConfigMap nachladen, ohne Falco neu zu bauen

Anomalie provozieren & belegen

  • Anomalie gezielt mit wget provozieren, Alarm live im Log
  • Kontrolllauf ohne wget: Regel bleibt zu Recht stumm
  • Runtime Security gegenüber Build-/Deploy-Zeit klar abgegrenzt

Dieses Modul ist Teil unserer Pilotphase. Gemeinsam mit euch definieren wir passende Metriken (z. B. Zeit bis zur korrekt gelesenen Standardregel, Ergebnis des Kontrolllaufs ohne wget) und werten sie im Anschluss transparent aus. Ergebnisse veröffentlichen wir, sobald sie belastbar sind.

Bereit, das Modul zu buchen?

Wir klären vorab, ob eure Trainingsumgebung privilegierte Container zulässt, und passen den Demo-Container auf eure tatsächliche Toolchain an.

Academy Briefing anfragen