Netzwerksicherheit in GKE

In diesem Dokument werden die wichtigsten Konzepte der GKE-Netzwerksicherheit erläutert, z. B. das Prinzip der geringsten Berechtigung. Außerdem erfahren Sie, wie Sie die richtigen Tools zum Sichern Ihres Clusters auswählen. Die Hauptziele der Implementierung der GKE-Netzwerksicherheit sind die Arbeitslastisolation und die sichere Mehrmandantenfähigkeit. Um diese Ziele zu erreichen, sollten Sie die Prinzipien der geringsten Berechtigung und der gestaffelten Sicherheitsebenen anwenden und umsetzbare Daten verwenden, um Ihre Sicherheitsentscheidungen zu 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, d. h., jeder Pod kann mit jedem anderen Pod kommunizieren.

Dieses Dokument soll Operatoren, Netzwerkspezialisten und Sicherheitsspezialisten helfen, die Netzwerksicherheit in GKE-Clustern zu verstehen und zu implementieren. Weitere Informationen zu gängigen Rollen und Beispiel aufgaben in Google Cloudfinden Sie unter Häufig verwendete GKE-Nutzerrollen und aufgaben.

Bevor Sie dieses Dokument lesen, sollten Sie mit den folgenden Themen vertraut sein:

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

Ziele der GKE-Netzwerksicherheit

GKE-Netzwerksicherheitsrichtlinien bieten eine detaillierte, Kubernetes-bezogene 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:

  • Geringste Berechtigung: Gewähren Sie Systemen und Diensten nur die Mindestberechtigungen, die für die Ausführung ihrer Funktionen erforderlich sind. Dieses Prinzip reduziert die potenziellen Auswirkungen einer Manipulation. Kubernetes-Netzwerk richtlinien helfen Ihnen, von einem standardmäßig offenen Netzwerk zu einem Netzwerk zu wechseln, in dem nur die erforderlichen Verbindungen zulässig sind.
  • Gestaffelte Sicherheitsebenen: Verwenden Sie mehrere unabhängige Sicherheitskontrollen. Ein Fehler in einer Kontrolle führt nicht zu einer vollständigen Systemmanipulation. Sie können beispielsweise eine Netzwerkrichtlinie verwenden, um eine Datenbank zu isolieren, auch wenn für die Datenbank selbst eine Authentifizierung erforderlich ist.
  • Umsetzbare Daten: Treffen Sie Sicherheitsentscheidungen auf der Grundlage von Daten. Bedrohungsmodellierung und Risikobewertung beeinflussen Ihre Sicherheitslage. Funktionen wie das Logging von Netzwerkrichtlinien liefern die Daten, mit denen Sie Richtlinien überprüfen und potenzielle Verstöße erkennen können.

Netzwerksicherheitsrichtlinie auswählen

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

Traffic-Typen

Berücksichtigen Sie bei der Auswahl der richtigen Richtlinie die Quelle und das Ziel des Traffics, den Sie verwalten möchten:

  • Kommunikation zwischen Pods im Cluster: Um die Kommunikation zwischen Microservices zu steuern, verwenden Sie Richtlinien, die auf Pod Labels und Namespaces angewendet werden.

    • Als Anwendungsentwickler können Sie die Standard-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 Sicherheitsvorkehrungen erzwingen, die für den gesamten Cluster gelten. Die Ablehnungs regeln in NetworkPolicy haben Vorrang vor den CiliumClusterwideNetworkPolicy Zulassungsregeln.

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

  • Verschlüsselung für den gesamten Dienst-zu-Dienst-Traffic: Um sicherzustellen, dass die gesamte Kommunikation zwischen Diensten verschlüsselt und authentifiziert wird, verwenden Sie ein Service Mesh. Mit Istio oder Anthos Cloud Service Mesh können Sie gegenseitige TLS-Authentifizierung (mTLS) implementieren, die die Verschlüsselung automatisch verarbeitet.

Zusammenfassung der Richtlinienauswahl

In der folgenden Tabelle wird zusammengefasst, welche Richtlinie je nach Sicherheitsziel verwendet werden sollte.

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

Netzwerkrichtlinien prüfen und Fehler beheben

Nach der Implementierung von Netzwerkrichtlinien müssen Sie prüfen, ob sie wie erwartet funktionieren, und alle Verbindungsprobleme diagnostizieren. Das Logging von Netzwerkrichtlinien kann als primäres Tool dafür verwendet werden.

Wenn Sie das Logging von Netzwerkrichtlinien aktivieren, generiert GKE in Cloud Logging einen Logeintrag für jede Verbindung, die durch eine Netzwerkrichtlinie zugelassen oder abgelehnt wird. Diese Logs sind für die Durchführung von Sicherheitsprüfungen und die Behebung unerwarteten Verhaltens unerlässlich. Wenn Sie diese Logs überprüfen, 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