Ist Ihr Kubernetes-Cluster sicher oder läuft er gerade?Standardmäßige Kubernetes-Konfigurationen geben der Benutzerfreundlichkeit Vorrang vor der Sicherheit. Ohne absichtliche Härtung sind Cluster anfällig für Container-Escapes, Privilegieneskalation, laterale Bewegungen und Datendiebstahl. Diese Checkliste deckt alle Sicherheitskontrollen ab, die Sie für Produktions-Kubernetes-Umgebungen implementieren müssen.
Wichtige Erkenntnisse
- Standardmäßig ist Kubernetes nicht sicher:Standardkonfigurationen ermöglichen privilegierte Container, uneingeschränkten Netzwerkzugriff und umfassende API-Serverberechtigungen.
- RBAC ist Ihre erste Verteidigung:Beschränken Sie den API-Serverzugriff auf das für jedes Dienstkonto und jeden Benutzer erforderliche Minimum.
- Netzwerkrichtlinien verhindern seitliche Bewegungen:Ohne Netzwerkrichtlinien kann jeder Pod mit jedem anderen Pod kommunizieren – ein flaches Netzwerk innerhalb Ihres Clusters.
- Pod-Sicherheitsstandards ersetzen PSP:Pod Security Admission (PSA) erzwingt Sicherheitsbeschränkungen für alle Pods.
- Die Sicherheit der Lieferkette ist wichtig:Überprüfen Sie die Herkunft von Bildern, suchen Sie nach Schwachstellen und setzen Sie Bildrichtlinien durch Zugangskontrolle durch.
Kubernetes Sicherheitscheckliste
API Serversicherheit
- Aktivieren Sie RBAC und deaktivieren Sie die anonyme Authentifizierung
- Verwenden Sie eine starke Authentifizierung (OIDC, zertifikatbasiert) – keine Basisauthentifizierung oder statische Token
- Beschränken Sie den API-Serverzugriff auf bekannte IP-Bereiche (verwaltetes Kubernetes: Verwenden Sie autorisierte Netzwerke)
- Aktivieren Sie die Überwachungsprotokollierung für alle API-Serveranfragen
- Deaktivieren Sie Alpha-/Betafunktionen in Produktionsclustern
- Konfigurieren Sie Zulassungscontroller: PodSecurity, ResourceQuota, LimitRange
Best Practices für RBAC
- Befolgen Sie die geringste Berechtigung: keine ClusterAdmin-Bindungen für Dienstkonten
- Verwenden Sie nach Möglichkeit Namespace-Rollen anstelle von ClusterRoles
- Überprüfen Sie RBAC regelmäßig mit Tools wie kubectl-who-can und rbac-lookup
- Erteilen Sie niemals Platzhalterberechtigungen (Verben: ["*"], Ressourcen: ["*"])
- Beschränken Sie den Zugriff auf Geheimnisse – gewähren Sie das Abrufen/Auflisten von Geheimnissen nur den Pods, die sie benötigen
- Verwenden Sie separate Dienstkonten pro Anwendung (nicht das Standarddienstkonto)
Netzwerksicherheit
- Implementieren Sie NetworkPolicies mit standardmäßiger Ablehnung in allen Namespaces
- Nur erforderlichen ein- und ausgehenden Datenverkehr pro Anwendung zulassen
- Verwenden Sie ein CNI, das NetworkPolicies unterstützt (Calico, Cilium, Antrea)
- Verschlüsseln Sie die Kommunikation zwischen Pods mit Service Mesh mTLS (Istio, Linkerd)
- Beschränken Sie den ausgehenden Datenverkehr auf bekannte externe Endpunkte (verhindern Sie die Datenexfiltration)
- Isolieren Sie sensible Arbeitslasten in dedizierten Namespaces mit strengen Richtlinien
Pod-Sicherheit
- Pod-Sicherheitszulassung auf Namespace-Ebene aktivieren (eingeschränktes Profil erzwingen)
- Container als Nicht-Root ausführen (runAsNonRoot: true)
- Verwenden Sie das schreibgeschützte Root-Dateisystem (readOnlyRootFilesystem: true)
- Alle Funktionen löschen, nur das hinzufügen, was benötigt wird (löschen: ["ALL"])
- Privilegieneskalation deaktivieren (allowPrivilegeEscalation: false)
- Legen Sie Ressourcenlimits (CPU, Speicher) für alle Container fest, um Ressourcenmissbrauch zu verhindern
- Mounten Sie das Dienstkonto-Token nicht, es sei denn, es ist erforderlich (automountServiceAccountToken: false)
Bildsicherheit
- Scannen Sie alle Bilder vor der Bereitstellung auf Schwachstellen (Trivy, Snyk)
- Verwenden Sie minimale Basis-Images (distroless, Alpine), um die Angriffsfläche zu reduzieren
- Containerbilder signieren und Unterschriften beim Einlass überprüfen (Mitunterzeichnung, Notation)
- Nur Bilder aus vertrauenswürdigen Registern zulassen (durch Zugangskontrolle erzwingen)
- Verwenden Sie niemals das Tag „:latest“ – zur Reproduzierbarkeit an bestimmte Bildübersichten anheften
- Erstellen und aktualisieren Sie Basis-Images regelmäßig neu, um Sicherheitspatches zu integrieren
Geheimnismanagement
- Speichern Sie keine Geheimnisse in Umgebungsvariablen oder ConfigMaps
- Externe Geheimnisverwaltung verwenden (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault)
- Wenn Sie Kubernetes Secrets verwenden, aktivieren Sie die Verschlüsselung im Ruhezustand (EncryptionConfiguration)
- Rotieren Sie Geheimnisse regelmäßig mit automatischer Rotation durch externe Geheimoperatoren
- Beschränken Sie den RBAC-Zugriff auf Geheimnisse – die meisten Pods sollten nicht in der Lage sein, alle Geheimnisse aufzulisten
Überwachung und Erkennung
- Aktivieren Sie die Kubernetes-Überwachungsprotokollierung und leiten Sie sie an SIEM
- weiter Stellen Sie eine Laufzeitsicherheitsüberwachung bereit (Falco, Sysdig)
- Überwachen Sie: unerwartete Prozessausführung, Netzwerkverbindungen, Dateiänderungen, Rechteausweitung
- Warnung bei: Neue ClusterRoleBinding-Erstellung, geheimer Zugriff durch unerwartete Pods, Container-Exec-Befehle
- Implementieren Sie Verstöße gegen die Pod-Sicherheitsrichtlinie als SIEM-Warnungen
CIS Kubernetes Benchmark
Das Center for Internet Security (CIS) veröffentlicht detaillierte Sicherheitsbenchmarks für Kubernetes. Verwenden Sie kube-bench, um Ihren Cluster automatisch anhand von CIS-Benchmarks zu bewerten. Behandeln Sie alle kritischen und wichtigen Erkenntnisse vor dem Produktionseinsatz. Verwaltete Kubernetes-Dienste (EKS, AKS, GKE) verarbeiten einige Benchmark-Elemente automatisch, für kundenverantwortliche Elemente ist jedoch noch eine Konfiguration erforderlich.
Wie Opsio Kubernetes sichert
- Bewertung der Clustersicherheit:Wir bewerten Ihre Kubernetes-Cluster anhand von CIS-Benchmarks und Best Practices von Cloud-Anbietern.
- Härtungsimplementierung:Wir implementieren alle Punkte der Checkliste, einschließlich RBAC, Netzwerkrichtlinien, Pod-Sicherheit und Überwachung.
- Laufzeitüberwachung:Unser SOC überwacht Kubernetes-Cluster auf Sicherheitsereignisse und anomales Verhalten.
- Richtliniendurchsetzung:Wir setzen OPA/Gatekeeper oder Kyverno ein, um Sicherheitsrichtlinien automatisch durchzusetzen.
- Laufende Geschäftsführung:Regelmäßige Sicherheitsüberprüfungen, Neubewertung des CIS-Benchmarks und Aktualisierungen der Sicherheitskonfiguration.
Häufig gestellte Fragen
Was ist die wichtigste Kubernetes-Sicherheitskontrolle?
Netzwerkrichtlinien mit Default-Deny. Ohne Netzwerkrichtlinien kann jeder Pod mit jedem anderen Pod kommunizieren – ein kompromittierter Webanwendungs-Pod kann direkt auf den Datenbank-Pod, den Überwachungsstapel und den Kubernetes API-Server zugreifen. Durch Default-Deny-Netzwerkrichtlinien wird der Explosionsradius jeder Container-Kompromittierung sofort reduziert.
Sollte ich aus Sicherheitsgründen ein Service Mesh verwenden?
Service Mesh (Istio, Linkerd) fügt mTLS zwischen Diensten hinzu und bietet Verschlüsselung und Authentifizierung für die gesamte Kommunikation zwischen Pods. Wenn Sie mit sensiblen Daten umgehen oder Compliance-Anforderungen für die Verschlüsselung während der Übertragung erfüllen müssen, ist Service Mesh wertvoll. Für einfachere Umgebungen können Netzwerkrichtlinien allein ausreichend sein.
Wie gehe ich sicher mit Geheimnissen in Kubernetes um?
Verwenden Sie einen externen Secrets-Manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) mit einem Kubernetes Secrets-Operator (External Secrets Operator, Vault Secrets Operator). Dies hält Geheimnisse von Git fern, bietet Audit-Protokollierung, ermöglicht Rotation und zentralisiert die Geheimnisverwaltung über Kubernetes- und Nicht-Kubernetes-Workloads hinweg.