--- title: "Kubernetes Security und Container Hardening | SKAFFON" description: "Kubernetes-Security-Assessment und Hardening: RBAC, Pod Security, Netzwerkrichtlinien, Image-Prüfung, Runtime-Schutz. Mit Prüfkatalog und Befundbericht." url: https://skaffon.de/cybersecurity/kubernetes-security/ --- ![Verschlossene Serverschränke mit Netzwerkkabeln und grün leuchtenden Statusanzeigen in einem dunklen Rechenzentrum](/_astro/serverschrank-verkabelung-abgeschlossene-racks.DvaAr4lf_1MrJ3b.jpg) 1. [Startseite](/) 2. [Cybersecurity](/cybersecurity/) 3. Kubernetes Security und Container Hardening 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](/projekt-anfragen/) [Zum Prüfkatalog](/cybersecurity/kubernetes-security/#pruefkatalog) - Für IT-Leitung, CTO und Plattformverantwortliche - Assessment standardmäßig lesend - Härtung als IaC und GitOps Autor: [Ibrahim Yesilay](/unternehmen/ibrahim-yesilay/), Gründer und Geschäftsführer Stand: 13.11.2026 Auslö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](/cybersecurity/nis2-beratung/)) 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. Prüfgegenstand ## Wo wir im Cluster ansetzen Das Assessment ergänzt unsere [Cloud-Security-Prüfung](/cybersecurity/cloud-security/): Dort geht es um Cloud-Konto, Netz und Dienste, hier um Cluster und Workloads. Ablauf ## 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](/leistungen/gitops-argocd/)), 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. Prü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](https://kubernetes.io/docs/concepts/security/security-checklist/). Er wird auf Ihr Bedrohungsmodell und Ihre Plattform angepasst. __Prüfkatalog Kubernetes-Härtung mit Prüfweg und Einstufung__ | Bereich | Prüfpunkt | Prüfweg | Stufe | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------- | ----- | | Zugang zum Cluster | Kubernetes-API, kubelet-API und etcd sind nicht öffentlich aus dem Internet erreichbar | Netzprüfung von außen, Konfigurationsauszug | K | | Zugang zum Cluster | Gruppe system:masters wird nach dem Bootstrapping nicht für Benutzer oder Komponenten verwendet | Rollen- und Zertifikatsprüfung | K | | RBAC | Keine Platzhalterrechte auf alle Ressourcen; cluster-admin nur, wo erforderlich | Auswertung aller (Cluster-)Rollenbindungen | K | | RBAC | Rechte zum Anlegen und Ändern von Workloads nur, wo erforderlich; Lese- und Listenrechte auf Secrets begrenzt (auch list und watch legen Inhalte offen) | Rechteanalyse je Namespace | H | | RBAC | Service-Account-Tokens werden nur eingehängt, wenn die Workloads sie brauchen | Prüfung der Pod-Spezifikationen | M | | Workloads | Pod-Security-Standard baseline oder restricted ist für alle Namespaces angewendet und durchgesetzt | Namespace-Labels, Admission-Konfiguration | H | | Workloads | Keine privilegierten Container, keine hostPath\-Volumes, kein Host-Netzwerk ohne Begründung | Auswertung der laufenden Workloads | K | | Workloads | Speicherlimits gesetzt; Seccomp-Profil aktiviert, AppArmor oder SELinux, wo unterstützt | Pod-Spezifikationen, Knotenkonfiguration | M | | Netz | Netzwerkplugin unterstützt Netzwerkrichtlinien; Standardrichtlinie je Namespace verweigert zunächst alles (Ingress und Egress) | CNI-Konfiguration, Richtlinienauswertung | H | | Netz | Zugriff der Workloads auf die Metadaten-API der Cloud ist gefiltert; LoadBalancer und ExternalIPs sind eingeschränkt | Netzprüfung aus einem Pod | H | | Images | Nur Images aus freigegebenen Registries; Signaturprüfung beim Deployment | Admission-Richtlinien, Registry-Konfiguration | H | | Images | Images werden bei Build und Betrieb auf bekannte Schwachstellen gescannt; Basis-Images sind aktuell | Scan-Bericht (Trivy) | H | | Geheimnisse | Geheimnisse liegen nicht im Klartext in Git; Zugriff und Rotation sind geregelt | Repository- und Cluster-Prüfung | K | | Laufzeit | Laufzeit-Erkennung für verdächtiges Verhalten (zum Beispiel Falco), Audit-Log der API aktiviert | Konfiguration, Testalarm | M | | Zertifikate | Zertifikate werden automatisch ausgestellt und erneuert (cert-manager); Wurzelzertifikat geschützt | Konfiguration und Ablaufprüfung | M | | Betrieb | Regelmäßiger Review der Zugriffe, Upgrade-Prozess für Cluster und Knoten | Prozessprüfung | M | Die Einstufung (K = kritisch, H = hoch, M = mittel) ist unsere praktische Ersteinschätzung und kein CVSS-Ersatz. Beispiel Pod Security Admission ## Pod-Sicherheitsstufen: erst beobachten, dann durchsetzen Pod Security Admission ist seit Kubernetes 1.25 stabil ([Dokumentation](https://kubernetes.io/docs/concepts/security/pod-security-admission/)). 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: ```yaml 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](/_astro/hoelzernen-steuerrads-schiffssteuer-fuer.NWn4ECGr_Z2UWlm.jpg) Beschreibung der Stufen: [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/) Beispiel 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: ```yaml 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. Und Cilium? Mit Cilium lassen sich Richtlinien zusätzlich auf Anwendungsebene und per Identität formulieren. Ob das für Sie sinnvoll ist, hängt von Netzwerkplugin und Anforderungen ab. Werkzeuge ## Welche Werkzeuge wir je Prüfbereich einsetzen Laut [Kyverno-Dokumentation](https://kyverno.io/docs/introduction/) 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. Plattform ## 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. - ### [STACKIT Kubernetes Engine](/stackit/managed-kubernetes/) Managed Kubernetes auf STACKIT und die Aufteilung der Verantwortung. Weiter - ### [Talos Linux und Omni](/infrastruktur/talos-omni/) Für Cluster mit Talos Linux verändert sich, wo Härtung ansetzt. Weiter - ### [Air-Gapped Kubernetes](/infrastruktur/air-gapped-kubernetes/) Für isolierte Umgebungen verändert sich, wo Härtung ansetzt. Weiter Abgrenzung ## 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. Vorbereitung ## 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. Angrenzende Themen ## Was an Kubernetes Security angrenzt - ### [Cybersecurity im Überblick](/cybersecurity/) Alle Sicherheitsbereiche von SKAFFON auf einer Seite. Weiter - ### [DevSecOps und Lieferketten](/cybersecurity/devsecops-supply-chain/) Der Absicherungsrahmen für die Software-Lieferkette. Weiter - ### [Kubernetes-Beratung](/leistungen/kubernetes-beratung/) Aufbau der Plattform selbst. Weiter - ### [Managed Kubernetes](/managed-services/managed-kubernetes/) Betrieb der Plattform durch SKAFFON. Weiter Anfrage ## Welche Cluster sollen wir uns ansehen? Beschreiben Sie Ihre Cluster und Ihr Ziel. [Projekt anfragen](/projekt-anfragen/) [Cybersecurity-Überblick](/cybersecurity/)