Projekt anfragen
Verschlossene Serverschränke mit Netzwerkkabeln und grün leuchtenden Statusanzeigen in einem dunklen Rechenzentrum

Kubernetes Security

Kubernetes Security und Container Hardening

SKAFFON prüft Kubernetes-Cluster auf Sicherheitslücken in Konfiguration, Zugriff, Netz, Workloads und Images und härtet sie anschließend: mit Richtlinien als Code, Netzwerkrichtlinien, Pod-Sicherheitsstufen, Image-Prüfung und Laufzeiterkennung. Sie erhalten einen Befundbericht mit priorisierten Maßnahmen und umgesetzte Richtlinien, die auch nach dem Projekt greifen.

Projekt anfragen Zum Prüfkatalog
  • Für IT-Leitung, CTO und Plattformverantwortliche
  • Assessment standardmäßig lesend
  • Härtung als IaC und GitOps

Autor: Ibrahim Yesilay, Gründer und Geschäftsführer Stand:

01Auslöser

Fünf Situationen, in denen ein Cluster zum Sicherheitsthema wird

Typische Anlässe, aus denen Teams mit produktiven Clustern ein Assessment beauftragen.

  • Rechte sind gewachsen

    Der Cluster ist schnell gewachsen. Wer welche Rechte hat und welche Workloads privilegiert laufen, weiß niemand genau.

  • Jeder Pod spricht mit jedem

    Ohne Netzwerkrichtlinien dürfen alle Pods miteinander sprechen; ein kompromittierter Dienst kann sich frei bewegen.

  • Images ohne Herkunftsnachweis

    Images kommen aus verschiedenen Registries, ohne Prüfung und ohne Nachweis der Herkunft.

  • Ein Audit verlangt Belege

    Ein Kunde, ein Audit oder eine Vorschrift (zum Beispiel NIS2) verlangt belegbare Maßnahmen für Container-Plattformen.

  • Die Migration ändert den Cluster

    Die Umgebung wird auf eine andere Plattform migriert, und die Sicherheitskonfiguration soll dabei nicht auf dem Stand „funktioniert“ stehenbleiben.

02Prüfgegenstand

Wo wir im Cluster ansetzen

Das Assessment ergänzt unsere Cloud-Security-Prüfung: Dort geht es um Cloud-Konto, Netz und Dienste, hier um Cluster und Workloads.

Härtungsebenen eines Kubernetes-Clusters Sechs Prüfbereiche von außen nach innen: Zugang, RBAC, Netz, Workloads, Images und Geheimnisse, Laufzeit. 1 Zugang zum Cluster 2 RBAC und Service-Accounts 3 Netz: Default-Deny-Richtlinien 4 Workloads: Pod-Sicherheitsstufen 5 Images prüfen und signieren Geheimnisse, Zertifikate 6 Laufzeit-Erkennung Jeder Bereich wird im Assessment einzeln belegt und eingestuft. Kubernetes-Härtung: Prüfbereiche von außen nach innen
Härtungsebenen eines Kubernetes-Clusters Sechs Prüfbereiche von außen nach innen: Zugang, RBAC, Netz, Workloads, Images und Geheimnisse, Laufzeit. Kubernetes-Härtung:Prüfbereiche von außen nach innen 1 Zugang zum Cluster 2 RBAC und Service-Accounts 3 Netz:Default-Deny-Richtlinien 4 Workloads:Pod-Sicherheitsstufen 5 Images prüfenund signieren Geheimnisse, Zertifikate 6 Laufzeit-Erkennung Jeder Bereich wird im Assessmenteinzeln belegt und eingestuft.

03Ablauf

Vom Lesezugriff zur erzwungenen Richtlinie

Härtung reproduzierbar zu machen heißt: erst verstehen, dann als Code ändern, dann durchsetzen.

  1. 01

    Cluster erfassen

    1

    Cluster-Version und -Topologie, Zugangswege, Namespaces, Rollen, Workloads, Netzwerkplugin, Registries und vorhandene Richtlinien.

  2. 02

    Gegen den Katalog prüfen

    2

    Das Assessment folgt dem Prüfkatalog unten, standardmäßig lesend, mit Konfigurationsauszügen als Beleg.

  3. 03

    Befundbericht erhalten

    3

    Einstufung und Belege je Befund, dazu ein priorisierter Maßnahmenplan mit Aufwand und Abhängigkeiten.

  4. 04

    Als Code härten

    4

    Umsetzung als IaC- und GitOps-Änderungen (zum Beispiel über GitOps mit Argo CD), damit die Härtung reproduzierbar und überprüfbar bleibt.

  5. 05

    Richtlinien durchsetzen

    5

    Durchsetzung beim Ausrollen, zunächst im Audit-Modus, dann im Erzwingungsmodus.

  6. 06

    Nachprüfen und übergeben

    6

    Erneute Prüfung, Dokumentation und Einweisung Ihres Teams.

04Prüfkatalog

16 Prüfpunkte, vom API-Zugang bis zum Upgrade-Prozess

Der Katalog ist unser Standard-Prüfumfang, angelehnt an die Sicherheits-Checkliste der Kubernetes-Dokumentation. Er wird auf Ihr Bedrohungsmodell und Ihre Plattform angepasst.

Prüfkatalog Kubernetes-Härtung mit Prüfweg und Einstufung
BereichPrüfpunktPrüfwegStufe
Zugang zum ClusterKubernetes-API, kubelet-API und etcd sind nicht öffentlich aus dem Internet erreichbarNetzprüfung von außen, KonfigurationsauszugK
Zugang zum ClusterGruppe system:masters wird nach dem Bootstrapping nicht für Benutzer oder Komponenten verwendetRollen- und ZertifikatsprüfungK
RBACKeine Platzhalterrechte auf alle Ressourcen; cluster-admin nur, wo erforderlichAuswertung aller (Cluster-)RollenbindungenK
RBACRechte zum Anlegen und Ändern von Workloads nur, wo erforderlich; Lese- und Listenrechte auf Secrets begrenzt (auch list und watch legen Inhalte offen)Rechteanalyse je NamespaceH
RBACService-Account-Tokens werden nur eingehängt, wenn die Workloads sie brauchenPrüfung der Pod-SpezifikationenM
WorkloadsPod-Security-Standard baseline oder restricted ist für alle Namespaces angewendet und durchgesetztNamespace-Labels, Admission-KonfigurationH
WorkloadsKeine privilegierten Container, keine hostPath-Volumes, kein Host-Netzwerk ohne BegründungAuswertung der laufenden WorkloadsK
WorkloadsSpeicherlimits gesetzt; Seccomp-Profil aktiviert, AppArmor oder SELinux, wo unterstütztPod-Spezifikationen, KnotenkonfigurationM
NetzNetzwerkplugin unterstützt Netzwerkrichtlinien; Standardrichtlinie je Namespace verweigert zunächst alles (Ingress und Egress)CNI-Konfiguration, RichtlinienauswertungH
NetzZugriff der Workloads auf die Metadaten-API der Cloud ist gefiltert; LoadBalancer und ExternalIPs sind eingeschränktNetzprüfung aus einem PodH
ImagesNur Images aus freigegebenen Registries; Signaturprüfung beim DeploymentAdmission-Richtlinien, Registry-KonfigurationH
ImagesImages werden bei Build und Betrieb auf bekannte Schwachstellen gescannt; Basis-Images sind aktuellScan-Bericht (Trivy)H
GeheimnisseGeheimnisse liegen nicht im Klartext in Git; Zugriff und Rotation sind geregeltRepository- und Cluster-PrüfungK
LaufzeitLaufzeit-Erkennung für verdächtiges Verhalten (zum Beispiel Falco), Audit-Log der API aktiviertKonfiguration, TestalarmM
ZertifikateZertifikate werden automatisch ausgestellt und erneuert (cert-manager); Wurzelzertifikat geschütztKonfiguration und AblaufprüfungM
BetriebRegelmäßiger Review der Zugriffe, Upgrade-Prozess für Cluster und KnotenProzessprüfungM

Die Einstufung (K = kritisch, H = hoch, M = mittel) ist unsere praktische Ersteinschätzung und kein CVSS-Ersatz.

05Beispiel Pod Security Admission

Pod-Sicherheitsstufen: erst beobachten, dann durchsetzen

Pod Security Admission ist seit Kubernetes 1.25 stabil (Dokumentation). Es kennt drei Modi: enforce (Verstöße führen zur Ablehnung), audit (Verstöße werden im Audit-Log annotiert, aber erlaubt) und warn (Verstöße führen zu einer Warnung, werden aber erlaubt). Stufen sind privileged, baseline und restricted.

Der Einstieg ohne Betriebsunterbrechung: zuerst audit und warn, Verstöße auswerten, dann enforce. So sieht das als Namespace-Label aus:

apiVersion: v1
kind: Namespace
metadata:
  name: beispiel-anwendung
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted
  • baseline verhindert bekannte Rechteausweitungen bei minimalen Einschränkungen.
  • restricted folgt aktuellen Härtungs-Best-Practices.
Schwarzweiß-Aufnahme eines hölzernen Schiffssteuerrads, Sinnbild für den Steuermann, nach dem Kubernetes benannt ist
Beschreibung der Stufen: Pod Security Standards

06Beispiel Netzwerkrichtlinie

Default-Deny im Netz: danach ist auch DNS gesperrt

Eine Standardrichtlinie, die allen Verkehr in einem Namespace verweigert, ist der Ausgangspunkt jeder Netzsegmentierung im Cluster:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: beispiel-anwendung
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Das Beispiel wirkt nur, wenn das Netzwerkplugin Netzwerkrichtlinien unterstützt. Es blockiert auch DNS: Danach brauchen Sie für jede Anwendung gezielte Freigaben (mindestens DNS und die tatsächlich benötigten Ziele). Wir führen Standard-Verweigerung deshalb schrittweise ein: erst Verkehr beobachten, dann Freigaben ableiten, dann erzwingen.

07Werkzeuge

Welche Werkzeuge wir je Prüfbereich einsetzen

Laut Kyverno-Dokumentation kann Kyverno Kubernetes-Ressourcen validieren, mutieren, generieren und aufräumen sowie Container-Images und ihre Metadaten für die Lieferketten-Sicherheit verifizieren.

Richtlinien als Code

  • Kyverno

Netz

  • Cilium

Image- und Abhängigkeitsscans

  • Trivy

Laufzeiterkennung

  • Falco

Zertifikate

  • cert-manager

Alle sind austauschbar; wir wählen nach Ihrer Plattform und Ihren Vorgaben und führen kein Werkzeug als Selbstzweck ein. Welche Richtlinienform bei Kyverno passt (klassische ClusterPolicy oder die neueren CEL-basierten Richtlinientypen), richtet sich nach der Kyverno-Version in Ihrem Cluster.

08Plattform

Wo Härtung ansetzt, wenn Sie nicht selbst die Control Plane betreiben

Bei Diensten wie STACKIT Kubernetes Engine verantwortet der Anbieter die Control Plane in dem Umfang, den sein Dienst beschreibt. Das Assessment erfasst, was in Ihrer Verantwortung liegt: Workloads, Rollen, Netzrichtlinien, Images und Knoten-Konfiguration, soweit zugänglich.

09Abgrenzung

Prüfen und härten, nicht angreifen

Das Assessment arbeitet lesend, mit befristeten, minimal berechtigten Zugängen und ohne Zugriff auf Inhalte Ihrer Daten. Änderungen gehen nur über abgestimmte Änderungsprozesse (IaC und GitOps), zunächst im Audit-Modus.

Das bekommen Sie

  • Ein Assessment ohne Angriffe und ohne Ausnutzung von Schwachstellen.
  • Einstellungen, die Anwendungen brechen können, führen wir nicht ohne Vorlauf und Test auf Produktivsystemen ein.
  • Belegte Befunde und Härtung, die in Ihrem Repository nachvollziehbar bleibt.

Das ist es nicht

  • Ein Penetrationstest mit Ausnutzung von Schwachstellen oder eine Red-Team-Übung. Das ist eine eigene Disziplin.
  • Ein Zertifikat oder Gutachten für Dritte.
  • Ein Werkzeug, das ohne Konzept und Pflege alles erkennt und behebt. Werkzeuge liefern Befunde; Bewertung und Behebung bleiben technische Arbeit.
  • Ein Sicherheitsbetrieb (SOC), der Alarme rund um die Uhr bearbeitet.

10Vorbereitung

Was wir vor dem ersten Befund von Ihnen brauchen

Den Aufwand bestimmen vor allem die Zahl der Cluster und Namespaces, die Zahl der Anwendungsteams, der Anteil von Altlasten (privilegierte Workloads, fehlende Limits), die Tiefe der Umsetzung (nur Assessment, Assessment mit Hardening, Hardening mit Betrieb) und die Reife von GitOps und Registry. Nach einem Erstgespräch erstellen wir ein Angebot mit klar abgegrenztem Leistungsumfang.

  • Lesender Zugriff auf Cluster (RBAC nach Least Privilege), Registries und Repositories; Zugang zu Netz- und Cloud-Konfiguration.
  • Architekturunterlagen und Ansprechpersonen für Plattform und Anwendungsteams.
  • Einen Freigabeprozess für Änderungen an produktiven Clustern.
  • Ihre Anforderungen an Schutzbedarf und gesetzliche Vorgaben.

11Angrenzende Themen

Was an Kubernetes Security angrenzt

Anfrage

Welche Cluster sollen wir uns ansehen?

Beschreiben Sie Ihre Cluster und Ihr Ziel.

Projekt anfragen Cybersecurity-Überblick