Kubernetes Security 2026: Hardening-Checkliste

25.10.2026 · IT-Wissen

Kubernetes Security 2026: Container sind keine automatisch abgeschotteten Sicherheitszonen. Wer Anwendungen mit Kubernetes betreibt, verwaltet neben dem eigentlichen Anwendungscode auch API-Zugänge, Cluster-Rollen, Netzwerkrouten, Secrets, Container-Images und eine komplexe Control Plane. Ein Fehler an einer dieser Stellen kann mehrere Services gleichzeitig betreffen. Kubernetes Security 2026 erfordert deshalb klare Verantwortlichkeiten zwischen DevOps, Platform Engineering und Informationssicherheit. Dieser Beitrag entwickelt eine praxistaugliche Hardening-Strategie: von Pod Security Standards über RBAC und Netzwerkregeln bis zu Supply-Chain-Kontrollen, Monitoring und zuverlässigem Restore.

GORTNET Fachredaktion · Stand: 25. Oktober 2026 · Technischer Praxisleitfaden

Warum Kubernetes ein anderes Sicherheitsmodell braucht

Ein klassischer Server bildet oft eine relativ stabile Sicherheitsgrenze: Betriebssystem, Applikation und Administrator sind bekannt. In Kubernetes ändern sich Pods und Dienste laufend, Berechtigungen werden aus Manifests erzeugt und Anwendungen kommunizieren über dynamische IP-Adressen. Ein Container läuft möglicherweise nur wenige Minuten, kann währenddessen aber Zugangsdaten lesen oder eine privilegierte API-Anfrage senden. Sicherheitsprüfungen dürfen deshalb nicht auf die einmalige Härtung von Nodes beschränkt werden.

Das Betriebsteam muss die Ebenen unterscheiden. Auf Cluster-Ebene sind API-Server, etcd, Node-Betriebssysteme und Komponenten-Updates relevant. Auf Namespace-Ebene geht es um Isolation und Zugriffsrechte. Auf Workload-Ebene zählen Images, Sicherheitskontexte, Secrets und Kommunikationsbeziehungen. Schließlich braucht die Organisation eine Governance für Entwicklerzugänge und automatisierte Deployments. Für jede Ebene sollten Mindeststandards dokumentiert und überprüfbar automatisiert werden.

Kubernetes Security 2026: Control Plane und API absichern

Der Kubernetes-API-Server ist die zentrale Kontrollschnittstelle. Er darf weder durch unkontrollierte öffentliche Erreichbarkeit noch durch zu großzügige Cluster-Admin-Konten zu einem universellen Angriffsziel werden. Begrenzen Sie Managementzugriffe nach Netzwerk und Identität, verlangen Sie starke Authentifizierung und halten Sie Admin-Konten von normalen Anwendungsidentitäten getrennt. Bei Managed-Kubernetes-Diensten muss die gemeinsame Verantwortung mit dem Cloud-Anbieter ausdrücklich geklärt sein.

Audit-Logs sollten sicher außerhalb des einzelnen Clusters aufbewahrt werden, damit Änderungen an Rollen, Secrets und Deployment-Konfigurationen auch nach einem Vorfall nachvollziehbar bleiben. Prüfen Sie zusätzlich die Absicherung von etcd und die Verschlüsselung gespeicherter Daten. Ein Backup der Control Plane, das dieselben kompromittierten Schlüssel benötigt wie das ausgefallene Cluster, ist kein belastbarer Notfallplan.

RBAC: Rollen nach tatsächlichen Aufgaben definieren

Role-Based Access Control (RBAC) unterscheidet Roles und ClusterRoles sowie die zugehörigen Bindings. Für die meisten Anwendungen sollten Berechtigungen möglichst auf einen Namespace begrenzt werden. Entwickler, Deployment-Pipelines, Monitoring und Support benötigen unterschiedliche Rechte. Besonders vorsichtig sollten Sie bei Verben wie create, patch, delete und beim Zugriff auf Secrets oder Rollenbindungen sein; auch manche vermeintlich lesenden Berechtigungen können sensitive Daten offenlegen.

Prüfen Sie bestehende ClusterRoleBindings und insbesondere Gruppen mit cluster-admin. Eine dauerhaft vergebene globale Berechtigung mag bequem sein, ist aber selten betrieblich notwendig. Definieren Sie einen dokumentierten Weg für zeitlich begrenzte Ausnahmeberechtigungen und kontrollieren Sie die Entfernung nach Projektende. Der Grundsatz lautet: Ein kompromittiertes Servicekonto soll nur den eng begrenzten Aufgabenbereich der Anwendung betreffen können.

ServiceAccounts und Workload Identity richtig nutzen

Anwendungen sollen nicht mit persönlichen Administrator-Zugangsdaten arbeiten. Erstellen Sie separate ServiceAccounts für unterschiedliche Workloads und vermeiden Sie, dass jeder Pod standardmäßig dieselbe Identität verwendet. Wenn ein Pod die Kubernetes-API nicht benötigt, sollten überflüssige API-Tokens nicht automatisch bereitgestellt werden. Prüfen Sie auch, ob Tokenablauf, Projektion und Berechtigungen zu Ihrem verwendeten Kubernetes- und Cloud-Setup passen.

Für Cloud-Ressourcen bieten Provider je nach Plattform Workload-Identity-Mechanismen an, die langfristige Zugangsschlüssel reduzieren. Solche Identitäten müssen aber genauso regelmäßig geprüft werden wie Servicekonten im Cluster. Dokumentieren Sie, welche Anwendung auf welchen Speicher, welche Queue oder welchen Secrets-Dienst zugreifen darf. Eine pauschale Cloud-Administratorrolle für jeden Pod wäre keine Verbesserung gegenüber einem fest gespeicherten API-Schlüssel.

Pod Security Standards: Baseline und Restricted

Kubernetes definiert drei Pod-Security-Profile: Privileged, Baseline und Restricted. Das Profil Privileged erlaubt sehr weitreichende Konfigurationen und gehört nur in bewusst kontrollierte Ausnahmen. Baseline reduziert bekannte Wege zur Privilegienerweiterung, während Restricted stärkere Härtungsregeln für typische Anwendungs-Pods vorsieht. Die konkrete Eignung hängt vom Workload und dem unterstützten Betriebssystem ab.

Aktivieren Sie Pod Security Admission sinnvollerweise zuerst in einem Audit- oder Warnmodus für bestehende Namespaces. Prüfen Sie, welche Deployments wegen Host-Zugriff, Privileged-Containern oder fehlenden SecurityContexts gegen die gewünschte Policy verstoßen. Erst danach sollte die Erzwingung schrittweise erfolgen. Ein sofortiges clusterweites Restricted-Enforcement kann Infrastrukturkomponenten oder produktive Anwendungen blockieren. Ausnahmen werden nach Zweck dokumentiert und regelmäßig überprüft.

Container-Hardening: Read-Only, Non-Root und Ressourcenlimits

Container sollten, sofern die Anwendung es unterstützt, ohne Root-Rechte laufen. Reduzieren Sie Linux-Capabilities, verhindern Sie unnötige Privilegienerhöhung und nutzen Sie geeignete Seccomp-Profile. Ein schreibgeschütztes Root-Dateisystem erschwert bestimmte Manipulationen, verlangt aber, dass temporäre und persistent benötigte Schreibpfade ausdrücklich geplant werden. Prüfen Sie die Anwendung gründlich, bevor Sie restriktive Einstellungen flächendeckend ausrollen.

Ressourcenanforderungen und Limits helfen außerdem, unbeabsichtigte Störungen und bestimmte Ressourcenmissbräuche einzugrenzen. Sie ersetzen keine Isolation: Ein fehlerhaft konfigurierter Pod kann auch innerhalb seines Limits gefährliche API-Rechte besitzen. Für kritische Dienste sollten Health Checks, geregelte Neustarts, Verfügbarkeit über mehrere Nodes sowie kontrollierte Rolling Updates Teil derselben Betriebsstrategie sein.

NetworkPolicies: Ost-West-Verkehr wirklich begrenzen

Ohne passende Netzwerkregeln können Container je nach Clusterkonfiguration in großem Umfang miteinander kommunizieren. Kubernetes NetworkPolicies ermöglichen die Definition zugelassener Ein- und Ausgänge anhand von Pod- und Namespace-Labels oder Netzwerkbereichen. Wichtig: Ihre Umsetzung hängt vom verwendeten CNI-Netzwerkplugin ab. Eine definierte Policy allein garantiert noch nicht, dass das tatsächliche Cluster sie durchsetzt.

Beginnen Sie mit einer Bestandsaufnahme der legitimen Kommunikationswege. Eine Pilotanwendung benötigt möglicherweise nur DNS, den eigenen Datenbankdienst und eine definierte externe API. Anschließend können Sie für geeignete Namespaces eine Default-Deny-Strategie aufbauen und erforderliche Verbindungen ausdrücklich freigeben. Prüfen Sie Egress genauso wie Ingress, denn Datenabfluss und Command-and-Control-Verbindungen nutzen häufig ausgehende Kommunikation. Sicherheitsänderungen sollten mit realen Anwendungstests abgesichert werden.

Secrets sind keine verschlüsselte Ablage von Haus aus

Kubernetes Secrets speichern sensible Werte wie Passwörter, Zertifikate und Tokens als eigene API-Objekte. Die häufig verwendete Base64-Darstellung in YAML-Dateien ist jedoch keine Verschlüsselung. Kubernetes weist darauf hin, dass Secret-Daten in etcd ohne zusätzliche Konfiguration unverschlüsselt gespeichert werden können. Deshalb müssen Encryption-at-Rest, schmale RBAC-Rechte und sichere API-Kommunikation gemeinsam betrachtet werden.

Vermeiden Sie Klartext-Secrets in Git-Repositories, Build-Logs und Ticketanhängen. Ein externer Secret-Manager kann je nach Architektur eine sinnvolle Ergänzung sein, aber auch dort bleiben Zugriffsrechte und Rotation entscheidend. Erstellen Sie einen Plan für die Erneuerung kompromittierter Zugangsdaten: Welche Anwendung muss neu gestartet werden, wie werden alte Tokens ungültig und wie verhindert man, dass der Fehler über ein altes Deployment-Manifest zurückkehrt?

Image-Security und sichere Software-Lieferkette

Verwenden Sie vertrauenswürdige Basisimages, möglichst klar definierte Versionen und reproduzierbare Build-Prozesse. Scannen Sie Images vor der Freigabe auf bekannte Schwachstellen und achten Sie auf nicht mehr gepflegte Abhängigkeiten. Eine Software Bill of Materials (SBOM) erleichtert die Zuordnung betroffener Komponenten zu Images. Signaturen und geeignete Admission-Kontrollen können zusätzlich sicherstellen, dass nur zugelassene Artefakte in produktive Namespaces gelangen.

Ein grüner Scanner ersetzt keine fachliche Risikoentscheidung. Manche CVEs betreffen einen nicht genutzten Codepfad, andere werden trotz niedriger Basisschwere durch exponierte Konfigurationen kritisch. Verbinden Sie Scan-Ergebnisse mit tatsächlicher Laufzeitexposition, Internet-Erreichbarkeit, möglicher Ausnutzung und der Bedeutung des Dienstes. Trennen Sie das Freigabeverfahren für den Quellcode von der Berechtigung, die Produktionsumgebung zu verändern.

Monitoring: Laufzeitereignisse und Cluster-Audit korrelieren

Metriken zu CPU und Speicherauslastung reichen für Security Monitoring nicht aus. Achten Sie auf verdächtige Exec-Sitzungen, unerwartete Änderungen an Rollen und Secrets, neue privilegierte Pods, ungewohnte Container-Prozesse sowie auffälligen Netzwerkverkehr. Kubernetes-Audit-Logs, Netzwerk-Telemetrie und geeignete Runtime-Security-Sensoren liefern unterschiedliche Perspektiven. Die Ereignisse müssen jedoch in einem zentralen Analyseprozess zusammengeführt werden.

Definieren Sie wenige, aber aussagekräftige Alarmfälle: Ein ServiceAccount erhält cluster-admin; ein Prod-Deployment nutzt ein unbekanntes Image; oder ein Container startet in einer kritischen Umgebung mit erweiterten Host-Rechten. Für jeden Alarm sollte ein Runbook festlegen, welche Informationen vorliegen, wann isoliert wird und wie der Dienst ohne Datenverlust wiederhergestellt werden kann.

Backup, Restore und Business Continuity im Cluster

Sichern Sie nicht ausschließlich Datenbankvolumes und vergessen Sie dabei die Cluster-Konfiguration. Für ein vollständiges Recovery sind je nach Architektur Deployment-Manifests, GitOps-Konfigurationen, persistente Daten, Secrets, Schlüssel und gegebenenfalls etcd relevant. Entscheidend ist die Wiederherstellbarkeit über Systemgrenzen hinweg: Ein Datenbank-Volume allein ist wenig hilfreich, wenn Zugriffsrichtlinien oder externe Abhängigkeiten fehlen.

Testen Sie die Wiederherstellung in einem isolierten Namespace oder Cluster. Überprüfen Sie, ob Anwendung und Daten auf einem kontrollierten Stand starten, ob ein frisch aufgebauter Cluster die gleichen Security-Policies erhält und ob im Desasterprozess übermäßige Notfallberechtigungen benötigt werden. Dokumentieren Sie RTO und RPO pro Geschäftsdienst statt nur für das Cluster als technische Einheit.

Kubernetes Security 2026: 30-Tage-Hardening-Plan

Woche eins: Versionen, Cluster-Zugänge, Namespaces, Workloads und kritische Daten erfassen. Woche zwei: RBAC-Bindings, ServiceAccounts und Secret-Speicherung überprüfen; überflüssige Cluster-Admin-Rechte entfernen. Woche drei: Pod Security Admission und NetworkPolicies in einer Pilotumgebung testen, Image-Freigaben und Signaturen planen. Woche vier: Alarmregeln, Restore-Test, Rollback und technische Abnahme dokumentieren.

Priorisieren Sie Risiken, die eine tatsächliche Cluster-Übernahme oder großen Datenabfluss erlauben. Nicht jedes niedrige Konfigurationsrisiko benötigt sofort eine Änderung, und eine nicht getestete Policy kann erhebliche Produktionsausfälle verursachen. Die wichtigste Management-Kennzahl ist deshalb nicht die Anzahl gefundener Verstöße, sondern der Anteil kritischer Risiken mit überprüfbarer, erfolgreich getesteter Gegenmaßnahme.

FAQ zur Absicherung von Kubernetes

Ist ein Managed Kubernetes Cluster automatisch sicher? Nein, der Betreiber bleibt für viele Workload-, Identitäts- und Konfigurationsentscheidungen zuständig. Reicht ein Container-Image-Scanner? Nein; auch Berechtigungen, Laufzeit, Netzwerk und Secrets müssen geschützt werden. Kann ich NetworkPolicies ohne CNI-Unterstützung nutzen? Eine Policy kann angelegt werden, aber die gewünschte Durchsetzung hängt vom Netzwerkplugin ab.

Warum sollte man nicht sofort alle Namespaces auf Restricted setzen? Weil bestimmte Infrastruktur-Workloads besondere Rechte benötigen und ungeprüfte Änderungen Ausfälle verursachen können. Wer trägt die Verantwortung? Plattform- und Anwendungsteams brauchen dokumentierte Zuständigkeiten mit zentralen Sicherheitsanforderungen und einem abgestimmten Ausnahmeprozess.

Fazit: Sicherheitsregeln müssen im Betrieb funktionieren

Ein wirksames Kubernetes Security 2026-Konzept kombiniert vorbeugende Kontrollen mit Messbarkeit: nachweislich reduzierte Rechte, getestete Netzisolierung, sichere Secrets, überprüfte Images und wiederholbare Notfallabläufe. Beginnen Sie mit einer Pilotanwendung und skalieren Sie erst nach Abnahme. So bleibt Security Teil der Plattformqualität statt eine nachträgliche Blockade für Entwickler.

Passende Beiträge und Leistungen

Für einen unabhängigen Architektur- und Sicherheitscheck GORTNET kontaktieren.

Technische Referenzen

Wirkung und Syntax einzelner Maßnahmen hängen von Kubernetes-Version, CNI-Implementierung, Cloud-Anbieter und Workload ab. Vor produktiven Änderungen stets kompatible Dokumentation und Tests verwenden.

Kubernetes Security 2026: Cluster, Pods und Secrets absichern