Leitfaden zur Kubernetes-Sicherheit: 9 Best Practices zur Sicherung Ihres Clusters

Wie wir in unserer Hands-on Einführung in Kubernetesbeschrieben haben, führte die Umstellung auf Microservice-Architekturen zum Bedarf an einem Orchestrierungswerkzeug, das für die Verwaltung des Lebenszyklus von Containern verwendet werden kann. Seit seiner Veröffentlichung im Jahr 2015 wurde Kubernetes schnell zu einer Art Standard für eine solche Orchestrierung.

Mit der zunehmenden Verbreitung haben auch die Sicherheitsbedenken zugenommen, wie eine Red Hat-Umfrage vom Mai dieses Jahres. Die Ergebnisse dieser Umfrage zeigen, dass:

• 93 % der Umfrageteilnehmer haben in den letzten 12 Monaten mindestens einen Sicherheitsvorfall in ihren Kubernetes-Umgebungen erlebt, 53 % davon aufgrund einer festgestellten Fehlkonfiguration

• 55 % der Befragten haben die Anwendungsbereitstellung aufgrund von Sicherheitsbedenken verzögert oder verlangsamt.

In diesem Artikel gehe ich auf einige der besten Sicherheitspraktiken ein, die während und nach der Einrichtung eines Kubernetes-Clusters beachtet werden sollten.

Bewährte Praktiken für Kubernetes-Sicherheit

Beginnen wir mit den Hosts, die den Cluster selbst bilden. Der gesamte Zugang zu diesen Hosts muss gesichert sein. So sollten Sie beispielsweise eine SSH-Schlüsselauthentifizierung einrichten und den Root-Zugang sowie die Passwortauthentifizierung deaktivieren. Sie können eine Firewall einrichten und auch alle anderen Maßnahmen ergreifen, um die Infrastruktur zu sichern, die Kubernetes hostet. Wenn diese gefährdet ist, ist natürlich alles gefährdet.

In diesem Blog konzentrieren wir uns jedoch mehr auf die Sicherheit von Kubernetes.

1. Absicherung des Kubernetes-API-Servers

Im Zentrum aller Operationen innerhalb eines Kubernetes-Clusters steht der Kube-Apiserver. Wir interagieren mit ihm über das Kube-Kontrolldienstprogramm oder indem wir direkt auf die API zugreifen, und auf diese Weise können wir fast jede Operation im Cluster durchführen. Das ist also die erste Verteidigungslinie - die Kontrolle des Zugriffs auf den API-Server selbst.

Wir müssen zwei Arten von Entscheidungen treffen: Wer kann auf den Kube-Apiserver zugreifen und was können sie tun?

Ihre Zeit ist begrenzt, also verschwenden Sie sie nicht damit, das Leben eines anderen zu leben. Lassen Sie sich nicht von einem Dogma einfangen - das bedeutet, mit den Ergebnissen anderer Menschen zu leben.

Steve Jobs

2. Authentifizierung

Es gibt verschiedene Möglichkeiten, sich beim API-Server zu authentifizieren. Kubernetes verwaltet Benutzerkonten nicht nativ, sondern ist auf eine externe Quelle wie eine Datei mit Benutzerdetails, Zertifikate oder Identitätsdienste von Drittanbietern angewiesen:

• Verwendung von Dateien mit Benutzerdaten wie Benutzernamen und Kennwörtern oder Token - Dieser Authentifizierungsmechanismus ist unsicher und wird NICHT empfohlen, da er die Daten im Klartext speichert.

• Zertifikate - Die TLS-Verschlüsselung ist ein Muss für die Kommunikation mit dem API-Server und es wird nicht empfohlen, die Verwendung von Zertifikaten im Allgemeinen zu überspringen. Eigentlich erwartet Kubernetes, dass die gesamte API-Kommunikation im Cluster standardmäßig verschlüsselt ist, und als Best Practice sollten Sie TLS-Verschlüsselung nicht nur für den API-Server, sondern auch für die Kommunikation zwischen allen verschiedenen Komponenten innerhalb des Clusters verwenden.

• Externe Authentifizierungsanbieter - Natürlich können Sie auch externe Authentifizierungsanbieter wie z. B. LDAP oder Kerberos verwenden, was ebenfalls als Sicherheitsstrategie gilt.

• Audit-Protokollierung - Kubernetes enthält ein integriertes Protokollierungssystem, mit dem Sie den Zugriff auf den API-Server und andere Kubernetes-Ressourcen verfolgen können. Dies kann nützlich sein, um Sicherheitsvorfälle zu erkennen und auf sie zu reagieren und Fehlkonfigurationen oder verdächtiges Verhalten zu identifizieren.

3. Autorisierung

• Node-Autorisierung - Dies ist ein spezieller Autorisierungsmodus, der speziell API-Anfragen von Kubelets autorisiert.

• Attributbasierte Zugriffskontrolle (ABAC) - Dieser Autorisierungsmodus verbindet einen Benutzer oder eine Gruppe von Benutzern mit einer Reihe von Berechtigungen. Allerdings müssen Sie jedes Mal, wenn Sie eine Änderung in der Sicherheit hinzufügen oder vornehmen möchten, die entsprechende Richtliniendatei manuell bearbeiten und den Kube-Apiserver neu starten. Daher sind die attributbasierten Zugriffskontrollkonfigurationen schwer zu verwalten.

• Rollenbasierte Zugriffskontrolle (RBAC) - Dieser Modus bietet einen eher standardisierten Ansatz für die Verwaltung des Zugriffs innerhalb des Kubernetes-Clusters, indem ein Rollenobjekt über eine Rollendefinitionsdatei erstellt wird und die Regeln für die angegebenen Ressourcen und die zulässigen Aktionen für diese Ressourcen definiert werden. Der nächste Schritt besteht darin, einen Benutzer mit dieser Rolle zu verknüpfen, und zwar mit einem anderen Objekt namens Rollenbindung.

4. Netzwerk-Politiken

Standardmäßig ist Kubernetes mit einer "All-Allow-Regel " konfiguriert, die den Datenverkehr von jedem Pod zu jedem anderen Pod oder Dienst innerhalb des Clusters zulässt.

Als beste Sicherheitspraxis empfiehlt es sich, für jeden Pod eine Netzwerkrichtlinie zu erstellen und den ein- und ausgehenden Datenverkehr nur auf die erforderliche Richtlinie zu beschränken. Ein gängiger Ansatz sind einige globale Richtlinien, die für alle Pods gelten, und Pod-spezifische Richtlinien, die alle Eingangs- und Ausgangsregeln für die erforderlichen Ports der einzelnen Pods festlegen.

Eine weitere gängige Praxis ist die Definition einer Standardverweigerungs-Netzwerkrichtlinie , die sicherstellt, dass der Datenverkehr verweigert wird, wenn keine andere Richtlinie speziell für die Zulassung dieses Datenverkehrs definiert ist.

5. Dienstnetz

Während die Netzwerkrichtlinien auf Schicht 3 und 4 arbeiten, kann das Service Mesh bei der Sicherheit von Schicht 7 - der Anwendungsschicht - helfen.

Die Implementierungen unterscheiden sich auch dadurch, dass die Netzwerkrichtlinien auf der Kernel-Ebene implementiert werden, während das Service-Mesh auf der User-Space-Ebene implementiert wird und über Standard-Sockets mit dem Netzwerk interagiert.

Die beliebteste Wahl für ein Kubernetes-natives Service-Mesh ist Istio. Sehen Sie sich unsere Einführung in Istio-Verkehrsmanagementsowie unseren Leitfaden für Installation von Istio auf Amazon EKS.

6. Basis-Bilder

Das Basis-Image ist die Grundlage Ihrer Container und Anwendungen, die unter Kubernetes laufen. Daher sollten sie aus einem vertrauenswürdigen und sicheren Repository stammen. Sie sollten es vermeiden, nicht vertrauenswürdige oder nicht verifizierte Basis-Images zu verwenden, da sie Schwachstellen oder bösartigen Code enthalten können.

In der Regel wird empfohlen, private Register anstelle von öffentlichen Registern zu verwenden, um die Bilder zu speichern, die bereits zur Verwendung freigegeben wurden.

Eine weitere Empfehlung ist, Ihre Images stets auf Sicherheitsprobleme, Schwachstellen oder schlechte Praktiken zu überprüfen. Tools zum Scannen von Bildern sammeln CVE-Informationen (Common Vulnerabilities and Exposures) aus verschiedenen Feeds, die auch in Ihre CI/CD-Pipeline integriert werden können.

Eine gute Strategie in Bezug auf das Scannen ist es, Ihre Bilder immer mit Tags zu versehen und die Verwendung des neuesten Tags zu vermeiden.

Eine weitere bewährte Praxis bei der Auswahl des richtigen Bildes ist das Sprichwort: "Je leichter das Image, desto besser." Mit leichteren Bildern können Sie aufgrund der geringeren Größe des Bildes schnellere Builds und Scans in Ihrem Arbeitsablauf erzielen und durch die Verwendung von weniger Abhängigkeiten auch potenzielle Schwachstellen reduzieren.

Daher sollten Sie in Erwägung ziehen, Alpenbilder als Basisbilder zu verwenden.

7. Kubernetes auf dem neuesten Stand halten

Es ist bekannt, dass es für die Optimierung von Sicherheit und Leistung unerlässlich ist, Ihre Anwendungen auf dem neuesten Stand zu halten. Wie die meisten Anwendungen wird auch Kubernetes ständig mit neuen Funktionen und Sicherheitsupdates weiterentwickelt, sodass Sie Ihre Infrastruktur immer auf dem neuesten Stand halten sollten.

8. Verwendung von Namensräumen und Ressourcenbegrenzungen/Kontingenten

Die Verwendung von Kubernetes-Namespaces bietet mehrere Vorteile. Zum Beispiel:

• Es hilft dabei, verschiedene Umgebungen zu isolieren, so dass Probleme mit Ihrer Staging-Umgebung beispielsweise keine Auswirkungen auf Ihre Produktionsumgebung haben.

Auch wenn Sie ein großes Team von Mitarbeitern haben, würde Ihnen die Isolierung verschiedener Projekte oder Microservices durch die Verwendung von Namespaces helfen, den Zugang zu verschiedenen Objekten einfach zu verwalten, was verhindern würde, dass Aktivitäten in einem der Namespaces andere Namespaces beeinflussen.

• Die Verwendung von Namespaces optimiert die Leistung Ihres Clusters, da der Kubernetes-API-Server weniger Objekte suchen muss, wenn Sie bestimmte Vorgänge durchführen.

• Unter Sicherheitsaspekten können Sie durch die Verwendung von Namespaces Ressourcenkontingent-Objekte anwenden, die die von jedem Ihrer Namespaces genutzten Ressourcen begrenzen können, was Denial-of-Service-Angriffe oder andere Angriffe auf die Erschöpfung von Ressourcen in Ihrem gesamten Cluster verhindert.

Sie können auch die CPU- und Speicherressourcennutzung der einzelnen Pods mit den Optionen für die Ressourcenanforderung und die Ressourcenbegrenzung steuern.

9. Sicheres etcd und geheime Daten

Standardmäßig sind die Geheimnisse, die zur Speicherung der sensibelsten Daten verwendet werden (z. B. Anmeldeinformationen, geheime Token und private Schlüssel), unverschlüsselt. Sie sind nur base64-kodiert und daher nicht sicher, da jeder, der die Berechtigung hat, die Geheimnisse einzusehen, einfach den Inhalt der Geheimnisse entschlüsseln und die sensiblen Daten im Klartext sehen kann.

Secrets und alle anderen Kubernetes-Konfigurationsdaten werden im Etcd-Schlüsselwertspeicher gespeichert. Jede einzelne Aktualisierung wird in Etcd gespeichert und auch jede Änderung direkt in Etcd führt zu einer Änderung im Cluster. Das bedeutet, dass ein Angreifer, der sich Zugang zu Etcd verschafft, den API-Server umgehen und somit unbegrenzten Zugriff auf den Cluster erhalten kann.

Deshalb sollten Sie in Erwägung ziehen, die Verschlüsselung im Ruhezustand zu aktivieren und den Etcd-Speicher hinter einer Firewall zu sichern und nur dem API-Server den Zugriff darauf mit ordnungsgemäßer Authentifizierung zu gestatten.

Wie lässt sich die Sicherheit in Kubernetes aufrechterhalten?

Mit der zunehmenden Verbreitung von Container-Orchestratoren in Großunternehmen und KMUs ist auch die Anforderung gestiegen, jede Infrastruktur zu schützen, auf der Container-Workloads laufen. Obwohl Kubernetes umfassende Sicherheitsfunktionen und -einstellungen bietet, ist die Sicherheit nicht von vornherein eingebaut. Diese Kontrollen und zusätzlichen Maßnahmen müssen ordnungsgemäß implementiert werden, um sicherzustellen, dass die Container sicher im Cluster laufen.
Kubernetes-Sicherheit beginnt mit dem Entwurf einer sicheren Architektur. Tools können dann den gesamten Erstellungsprozess überwachen und Schwachstellen aufdecken sowie eine kontinuierliche Sichtbarkeit gewährleisten.

Um sicherzustellen, dass Ihre Container so sicher wie möglich in Ihren Kubernetes-Clustern laufen, kontaktieren Sie ITGix und unsere Experten für die Beobachtung der Kubernetes-Sicherheit werden Ihnen helfen, die gewünschte Effizienz zu erreichen.