Netzwerksicherheit in GKE

In diesem Dokument werden die wichtigsten GKE-Netzwerksicherheitskonzepte wie das Prinzip der geringsten Berechtigung erläutert. Außerdem erfahren Sie, wie Sie die richtigen Tools zum Sichern Ihres Clusters auswählen. Die Hauptziele der Implementierung der GKE-Netzwerksicherheit sind die Arbeitslastisolierung und die sichere Mehrmandantenfähigkeit. Um diese Ziele zu erreichen, sollten Sie die Prinzipien der geringsten Berechtigung und der mehrschichtigen Sicherheit anwenden und fundierte Sicherheitsentscheidungen auf der Grundlage von verwertbaren Daten treffen.

In Google Kubernetes Engine (GKE) bedeutet die Anwendung des Prinzips der geringsten Berechtigung auf den Netzwerkverkehr, dass die Kommunikation auf das beschränkt wird, was für die Funktion Ihrer Anwendungen erforderlich ist. Standardmäßig ist das Netzwerk in einem GKE-Cluster offen. Das bedeutet, dass jeder Pod mit jedem anderen Pod kommunizieren kann.

Dieses Dokument soll Betreibern, Netzwerkspezialisten und Sicherheitsexperten helfen, die Netzwerksicherheit in GKE-Clustern zu verstehen und zu implementieren. Weitere Informationen zu gängigen Rollen und Beispielaufgaben in Google Cloudfinden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Bevor Sie dieses Dokument lesen, sollten Sie mit Folgendem vertraut sein:

  • GKE-Netzwerkkonzepte: Eine Übersicht finden Sie unter Informationen zum GKE-Netzwerk.
  • Kubernetes-Pods, -Dienste und -Namespaces: Diese grundlegenden Kubernetes-Ressourcen sind von zentraler Bedeutung für die Definition von Netzwerksicherheitsrichtlinien. Weitere Informationen finden Sie in der Kubernetes-Dokumentation.
  • Prinzip der geringsten Berechtigung: Dieses Sicherheitsprinzip ist ein Kernkonzept, das in diesem Dokument angewendet wird.

Ziele der GKE-Netzwerksicherheit

GKE-Netzwerksicherheitsrichtlinien bieten eine detaillierte, Kubernetes-kompatible Traffic-Steuerung in Ihrem Cluster. Diese Richtlinien sind ein wichtiger Bestandteil Ihrer allgemeinen Sicherheitsstrategie. Berücksichtigen Sie die folgenden grundlegenden Prinzipien, um eine robuste Netzwerksicherheit zu implementieren:

  • Prinzip der geringsten Berechtigung: Gewähren Sie Systemen und Diensten nur die Berechtigungen, die für die Ausführung ihrer Funktionen erforderlich sind. Dieses Prinzip verringert die potenziellen Auswirkungen einer Manipulation. Kubernetes-Netzwerkrichtlinien helfen Ihnen, von einem standardmäßig offenen Netzwerk zu einem Netzwerk zu wechseln, in dem nur erforderliche Verbindungen zulässig sind.
  • Gestaffelte Sicherheitsebenen: Mehrere unabhängige Sicherheitskontrollen einsetzen. Ein Fehler bei einer Kontrolle führt nicht zu einem vollständigen Systemmissbrauch. Sie können beispielsweise eine Netzwerkrichtlinie verwenden, um eine Datenbank zu isolieren, auch wenn für die Datenbank selbst eine Authentifizierung erforderlich ist.
  • Nutzbare Daten: Treffen Sie Sicherheitsentscheidungen auf Grundlage von Daten. Bedrohungsmodellierung und Risikobewertung geben Aufschluss über Ihren Sicherheitsstatus. Funktionen wie das Logging von Netzwerkrichtlinien liefern die Daten, die zum Überprüfen von Richtlinien und zum Erkennen potenzieller Sicherheitslücken erforderlich sind.

Netzwerksicherheitsrichtlinie auswählen

Um die richtige Richtlinie auszuwählen, müssen Sie den Typ und Umfang des Traffics ermitteln, den Sie steuern möchten.

Arten von Traffic

Berücksichtigen Sie die Quelle und das Ziel des Traffics, den Sie verwalten möchten, um die richtige Richtlinie auszuwählen:

  • Kommunikation zwischen Pods im Cluster: Um zu steuern, wie Microservices miteinander kommunizieren, verwenden Sie Richtlinien, die auf Pod-Labels und Namespaces basieren.

    • Als Anwendungsentwickler können Sie die standardmäßigen Kubernetes-NetworkPolicy verwenden, um Ingress- und Egress-Regeln für Ihre Anwendung in ihrem Namespace zu definieren.
    • Als Clusteradministrator können Sie mit dem CiliumClusterwideNetworkPolicy Sicherheitsmaßnahmen erzwingen, die für den gesamten Cluster gelten. Die Ablehn-Regeln in NetworkPolicy haben Vorrang vor den Zulassungs-Regeln in CiliumClusterwideNetworkPolicy.

  • Ausgehender Traffic von Pods zu externen Diensten: Wenn Sie den ausgehenden Traffic von Pods zu externen Diensten anhand von Domainnamen steuern möchten, verwenden Sie FQDNNetworkPolicy. Diese Richtlinie ist nützlich, wenn die IP-Adressen externer Dienste nicht statisch sind, da die zulässigen IP-Adressen automatisch über DNS aufgelöst und aktualisiert werden.

  • Verschlüsselung für den gesamten Dienst-zu-Dienst-Traffic: Verwenden Sie ein Service Mesh, um sicherzustellen, dass die gesamte Kommunikation zwischen Diensten verschlüsselt und authentifiziert wird. Verwenden Sie Istio oder Anthos Cloud Service Mesh, um gegenseitiges TLS (mTLS) zu implementieren, das die Verschlüsselung automatisch übernimmt.

Zusammenfassung der Richtlinienoptionen

In der folgenden Tabelle wird zusammengefasst, welche Richtlinie Sie basierend auf Ihrem Sicherheitsziel verwenden sollten.

Ziel Empfohlene Richtlinie
Traffic zwischen Pods mithilfe von Labels und Namespaces steuern Kubernetes NetworkPolicy
Ausgehenden Traffic zu externen Diensten nach Domainnamen steuern. FQDNNetworkPolicy
Verschlüsseln und authentifizieren Sie den gesamten Dienst-zu-Dienst-Traffic. Istio oder Anthos Cloud Service Mesh (für mTLS)
Als Administrator können Sie obligatorische, clusterweite Regeln erzwingen. CiliumClusterwideNetworkPolicy
Verbindungen, die durch Richtlinien zugelassen oder abgelehnt werden, prüfen und protokollieren. Logging von Netzwerkrichtlinien (für jede Richtlinie aktiviert)

Netzwerkrichtlinien prüfen und Fehler beheben

Nachdem Sie Netzwerkrichtlinien implementiert haben, sollten Sie prüfen, ob sie wie erwartet funktionieren, und alle Verbindungsprobleme beheben. Logging von Netzwerkrichtlinien ist das primäre Tool dafür.

Wenn Sie das Logging von Netzwerkrichtlinien aktivieren, generiert GKE für jede Verbindung, die durch eine Netzwerkrichtlinie zugelassen oder abgelehnt wird, einen Logeintrag in Cloud Logging. Diese Logs sind für Sicherheitsprüfungen und die Fehlerbehebung bei unerwartetem Verhalten unerlässlich. Anhand dieser Logs können Sie die konkreten Auswirkungen Ihrer Regeln sehen und bestätigen, dass legitimer Traffic wie erwartet fließt und nicht autorisierter Traffic blockiert wird.

Nächste Schritte