Managed Security fuer Kubernetes: SOC, Runtime-Schutz und was sich wirklich lohnt

TL;DR

• Ein internes 24/7-SOC kostet mindestens 250.000 EUR/Jahr an Personalkosten allein. Managed Security Services starten ab ca. 2.500 EUR/Monat.
• Runtime Security (Falco, Tetragon) erkennt anomales Verhalten in laufenden Containern. Image Scanning allein reicht nicht.
• Die groessten Quick Wins: Admission Controller fuer Policy Enforcement, automatisiertes Image Scanning in der CI/CD-Pipeline und zentrale Log-Aggregation.
• Managed Services lohnen sich vor allem fuer Teams unter 5 Ops-Leuten, die keinen dedizierten Security-Engineer haben.
• DSGVO-Compliance erfordert Datenverarbeitung in der EU und einen sauberen Auftragsverarbeitungsvertrag. Das gilt auch fuer Security-Telemetriedaten.

Wann ein Managed Security Service Sinn macht

Nicht jedes Team braucht einen Managed Security Service. Aber die meisten Kubernetes-Betreiber unterschaetzen den Aufwand, der hinter ernsthafter Container-Security steckt.

Ein typischer Kubernetes-Cluster hat dutzende Angriffsflaechen: der API-Server, die Kubelet-API, Container-Runtimes, Netzwerkverkehr zwischen Pods, Supply-Chain-Risiken durch Drittanbieter-Images, und Fehlkonfigurationen in RBAC, SecurityContexts und NetworkPolicies. Das alles zu ueberwachen, zu bewerten und darauf zu reagieren, ist ein Vollzeitjob -- oder mehrere.

Die Entscheidung zwischen Inhouse und Managed haengt von drei Faktoren ab:

Teamgroesse: Unter 5 Ops/DevOps-Engineers ist ein dedizierter Security-Engineer selten realistisch. Die Security-Aufgaben verteilen sich auf alle, werden aber von niemandem priorisiert.

Reaktionszeit: Security-Incidents passieren nachts und am Wochenende. Ohne Bereitschaftsmodell vergeht wertvolle Zeit zwischen Erkennung und Reaktion.

Compliance-Anforderungen: Regulierte Branchen (Finanz, Gesundheit, KRITIS) verlangen nachweisbare Sicherheitsprozesse. Ein externes SOC liefert Audit-Trails und Berichte, die intern aufwendig zu erstellen waeren.

Was ein Managed Security Service umfasst

Die Bezeichnung "Managed Security" ist breit. Hier eine Aufschluesselung der typischen Komponenten:

1. Runtime Security

Runtime Security erkennt anomales Verhalten in laufenden Containern. Das geht ueber statische Analyse hinaus: Es wird beobachtet, was ein Container tatsaechlich tut, nicht nur was er theoretisch tun koennte.

Typische Erkennungen:

• Shell wird in einem Container gestartet, der normalerweise keine Shell braucht
• Prozess liest /etc/shadow oder andere sensitive Dateien
• Container macht ausgehende Netzwerkverbindungen zu unbekannten IPs
• Binary wird zur Laufzeit heruntergeladen und ausgefuehrt

Die beiden relevanten Open-Source-Tools:

Ein Beispiel fuer eine Falco-Regel, die das Starten einer Shell in einem Container erkennt:

- rule: Terminal shell in container
  desc: Detect shell execution in a container
  condition: >
    spawned_process and
    container and
    proc.name in (bash, sh, zsh, csh, dash) and
    not container.image.repository in (allowed_shell_images)
  output: >
    Shell spawned in container
    (user=%user.name container=%container.name
    image=%container.image.repository
    shell=%proc.name parent=%proc.pname)
  priority: WARNING
  tags: [container, shell]

2. Image Scanning in der CI/CD-Pipeline

Schwachstellen in Container-Images zu finden, bevor sie in Produktion landen, ist der effizienteste Ansatz. Die Kosten eines Fixes steigen exponentiell mit jeder Phase: In der Build-Pipeline ist es ein Dependency-Update, in Produktion ist es ein Emergency-Rollout.

# Trivy-Scan in der CI/CD-Pipeline (GitHub Actions Beispiel)
- name: Scan container image
  run: |
    trivy image \
      --severity HIGH,CRITICAL \
      --exit-code 1 \
      --ignore-unfixed \
      --format table \
      ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }}

Der --exit-code 1 sorgt dafuer, dass die Pipeline fehlschlaegt, wenn HIGH- oder CRITICAL-Schwachstellen gefunden werden. --ignore-unfixed filtert Schwachstellen heraus, fuer die es noch keinen Fix gibt -- damit die Pipeline nicht wegen unloesbarerer Probleme blockiert.

3. Admission Controller fuer Policy Enforcement

Admission Controller fangen API-Anfragen ab, bevor Kubernetes sie ausfuehrt. Damit lassen sich Sicherheitsrichtlinien zentral durchsetzen:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-privileged-containers
spec:
  validationFailureAction: Enforce
  background: true
  rules:
    - name: no-privileged
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "Privileged containers are not allowed."
        pattern:
          spec:
            containers:
              - securityContext:
                  privileged: "false"
    - name: no-host-network
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "Host network access is not allowed."
        pattern:
          spec:
            hostNetwork: "false"

Diese Kyverno-Policy verhindert, dass privilegierte Container oder Container mit Host-Netzwerkzugriff deployed werden koennen. Egal ob ein Entwickler versehentlich oder absichtlich privileged: true setzt -- der API-Server lehnt das Deployment ab.

Fuer tiefergehende Policy-Strategien empfehlen wir unseren Artikel zur Kubernetes Compliance Automation.

4. Log-Aggregation und SIEM-Anbindung

Ohne zentrale Logs ist Incident Response Blindflug. Ein Managed Security Service sammelt typischerweise:

• Kubernetes Audit Logs (API-Server-Zugriffe)
• Container-Logs (stdout/stderr)
• Runtime-Security-Events (Falco/Tetragon)
• Netzwerk-Flow-Logs (Cilium Hubble)
• Node-Level-Logs (systemd, kubelet)

Diese Daten werden in ein SIEM (Security Information and Event Management) eingespeist, wo Korrelation und Alerting stattfinden. Fuer kleinere Teams reicht oft eine Kombination aus Loki/Grafana mit Alert-Rules. Groessere Setups nutzen dedizierte SIEMs wie Elastic Security oder Splunk.

Details zur Observability-Architektur finden Sie in unserem Artikel zum Kubernetes Observability Stack.

5. 24/7-SOC (Security Operations Center)

Das SOC ist der teuerste und gleichzeitig wertvollste Teil eines Managed Security Service. Geschulte Analysten bewerten Alerts, fuehren Incident Response durch und eskalieren bei Bedarf.

Ein realistischer Vergleich:

Die Personalkosten fuer ein internes 24/7-SOC sind der Hauptfaktor. Fuer Rund-um-die-Uhr-Abdeckung braucht es mindestens 4-5 Analysten (Schichtbetrieb, Urlaub, Krankheit). Bei durchschnittlichen Gehaeltern von 60.000-80.000 EUR fuer Security-Analysten in Deutschland kommt man schnell auf die genannten Summen.

Build vs. Buy: Entscheidungsmatrix

Nicht jede Komponente muss extern eingekauft werden. Manche Dinge lassen sich mit vertretbarem Aufwand intern umsetzen, andere nicht.

Der pragmatische Ansatz: Image Scanning und Admission Controller intern betreiben, Runtime Security und SOC extern einkaufen. Das gibt dem Team Kontrolle ueber die Build-Pipeline und lagert die aufwendige Ueberwachung und Reaktion aus.

Anbieter evaluieren: Worauf es ankommt

Bei der Wahl eines Managed Security Providers fuer Kubernetes gibt es einige harte Kriterien:

Kubernetes-Expertise: Viele Security-Anbieter kommen aus der klassischen IT-Security und haben Container- und Kubernetes-Know-how erst spaeter aufgebaut. Fragen Sie nach konkreter Erfahrung mit CRDs, Operators, Service Meshes und CNI-Plugins.

Datenstandort: Fuer DSGVO-Compliance muessen Telemetriedaten innerhalb der EU verarbeitet werden. Fragen Sie explizit, wo die SIEM-Infrastruktur laeuft und ob ein Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO angeboten wird.

Integration: Der Service muss sich in Ihren bestehenden Stack integrieren. Kann der Anbieter Daten aus Ihrem CNI-Plugin, Ihrem Monitoring-Stack und Ihrer CI/CD-Pipeline aufnehmen? Oder verlangt er einen komplett eigenen Stack?

Transparenz: Sie sollten Zugriff auf alle Rohdaten und Dashboards haben, nicht nur auf monatliche PDF-Reports. Fragen Sie nach API-Zugang und Self-Service-Portalen.

Exit-Strategie: Was passiert, wenn Sie den Anbieter wechseln wollen? Sind Ihre Daten exportierbar? Laesst sich der Security-Stack auch ohne den Anbieter weiterbetreiben?

Implementierung in drei Phasen

Phase 1: Quick Wins (Woche 1-4)

Sofort umsetzbare Massnahmen mit grossem Effekt:

# Kyverno installieren
helm repo add kyverno https://kyverno.github.io/kyverno/
helm install kyverno kyverno/kyverno -n kyverno --create-namespace

# Trivy Operator fuer kontinuierliches Image Scanning
helm repo add aqua https://aquasecurity.github.io/helm-charts/
helm install trivy-operator aqua/trivy-operator \
  -n trivy-system --create-namespace \
  --set trivy.severity="HIGH,CRITICAL"

# Kubernetes Audit Logging aktivieren (API-Server Flag)
# --audit-policy-file=/etc/kubernetes/audit-policy.yaml
# --audit-log-path=/var/log/kubernetes/audit.log
# --audit-log-maxage=30
# --audit-log-maxbackup=10

Phase 2: Monitoring und Detection (Woche 5-8)

Falco oder Tetragon installieren, mit dem Team die Default-Regeln durchgehen und False Positives tunen. Log-Aggregation einrichten und erste Alert-Rules definieren.

In dieser Phase zeigt sich, ob ein Managed Service noetig ist. Wenn das Team die Alerts nicht zeitnah bewerten kann oder die Tuning-Arbeit liegen bleibt, ist das ein klares Signal.

Phase 3: SOC-Anbindung (Woche 9-12)

Wenn ein Managed SOC angebunden wird: Datenfeeds konfigurieren, Incident-Response-Playbooks abstimmen, Eskalationswege definieren und einen Testlauf mit einem simulierten Incident durchfuehren.

DSGVO-Anforderungen an Security-Telemetriedaten

Ein Aspekt, der oft uebersehen wird: Security-Telemetriedaten koennen personenbezogene Daten enthalten. Kubernetes Audit Logs protokollieren, welcher User welche API-Anfrage gestellt hat. Container-Logs koennen Benutzernamen, IPs oder andere identifizierbare Informationen enthalten.

Das bedeutet:

• Der Managed Security Provider ist Auftragsverarbeiter im Sinne der DSGVO
• Ein Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO ist Pflicht
• Daten muessen in der EU verarbeitet werden (oder es braucht eine rechtliche Grundlage fuer den Transfer)
• Aufbewahrungsfristen fuer Logs muessen definiert sein
• Betroffenenrechte (Auskunft, Loeschung) muessen auch fuer Security-Logs umsetzbar sein

Fuer eine tiefergehende Betrachtung der Compliance-Themen empfehlen wir unseren Artikel zur DSGVO-Compliance fuer Kubernetes.

Kosten realistisch einschaetzen

Managed Security Services fuer Kubernetes bewegen sich typischerweise in folgenden Bereichen:

Dazu kommen interne Aufwaende: Jemand muss die Alerts bewerten, an Reviews teilnehmen und Empfehlungen umsetzen. Ein Managed Service nimmt Arbeit ab, aber nicht alle Arbeit.

Die Kosten sollten gegen das Risiko abgewogen werden. Ein Sicherheitsvorfall mit Datenverlust kostet ein mittelstaendisches Unternehmen im Schnitt sechsstellige Betraege -- Bussgelder, Forensik, Benachrichtigungen, Reputationsschaden. Im Vergleich dazu sind 3.000 EUR/Monat fuer proaktiven Schutz eine ueberschaubare Investition.

Fuer die Gesamtkostenbetrachtung Ihrer Kubernetes-Infrastruktur inklusive Security lohnt sich ein Blick auf unseren Hosting-Kostenvergleich.

Was Sie selbst tun koennen -- auch ohne Managed Service

Auch ohne externen Provider koennen Sie die Sicherheit Ihres Clusters erheblich verbessern:

1. Pod Security Standards aktivieren: Seit Kubernetes 1.25 sind Pod Security Admission Controller eingebaut. Setzen Sie mindestens das "restricted"-Profil fuer Produktions-Namespaces.
2. NetworkPolicies einrichten: Deny-all-Baseline pro Namespace, dann gezielte Allow-Regeln. Details dazu in unserem Artikel zu Kubernetes Network Security.
3. RBAC minimieren: Keine Cluster-Admin-Rechte fuer Entwickler. Least Privilege konsequent durchsetzen. Mehr dazu unter RBAC Enterprise.
4. Secrets nicht in ConfigMaps: Nutzen Sie External Secrets Operator oder HashiCorp Vault.
5. Audit Logging aktivieren: Die Daten sind wertlos, wenn sie nicht existieren.

Fazit

Managed Security fuer Kubernetes ist kein Luxus, sondern eine pragmatische Antwort auf den Fachkraeftemangel im Security-Bereich. Die Frage ist nicht "ob", sondern "welche Komponenten" extern eingekauft werden.

Der empfohlene Weg: Quick Wins (Image Scanning, Admission Controller) intern umsetzen, Runtime Security und SOC-Anbindung evaluieren, und dann eine informierte Entscheidung treffen.

Wenn Sie eine unabhaengige Einschaetzung Ihrer aktuellen Sicherheitslage brauchen oder Unterstuetzung bei der Auswahl eines Managed Security Providers, sprechen Sie uns an unter /kontakt.