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 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.

GKE unterstützt jetzt einen hierarchischen Ansatz für die Netzwerksicherheit, indem ClusterNetworkPolicy für die Durchsetzung auf Administratorebene in allen Namespaces verwendet wird.

Dieses Dokument enthält Informationen, die Betreiber, Netzwerkspezialisten und Sicherheitsexperten benötigen, um 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:

  • Geringste Berechtigung: Gewähren Sie Systemen und Diensten nur die Mindestberechtigungen, 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.
  • Umsetzbare Daten: Treffen Sie Sicherheitsentscheidungen auf Grundlage von Daten. Bedrohungsmodellierung und Risikobewertung geben Aufschluss über Ihre Sicherheitslage. Funktionen wie das Logging von Netzwerkrichtlinien liefern die Daten, mit denen Richtlinien überprüft und potenzielle Sicherheitslücken erkannt werden können.

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äßige Kubernetes-NetworkPolicy verwenden, um Ingress- und Egress-Regeln für Ihre Anwendung in ihrem Namespace zu definieren.
    • Als Clusteradministrator können Sie die standardmäßige Kubernetes-ClusterNetworkPolicy verwenden, um obligatorische Sicherheitsvorkehrungen (Admin-Stufe) zu erzwingen oder Zero-Trust-Standardeinstellungen (Baseline-Stufe) für alle Namespaces festzulegen. Diese Ressource wird auf Clustern mit der GKE-Version 1.36.1-gke.1067000 oder höher unterstützt.
    • Als Clusteradministrator können Sie die proprietäre CiliumClusterwideNetworkPolicy für die spezielle clusterweite Traffic-Steuerung verwenden. Verwenden Sie für neue Bereitstellungen die Kubernetes-native ClusterNetworkPolicy anstelle dieser proprietären Richtlinie.

  • Ausgehender Traffic von Pods zu externen Diensten: Wenn Sie den ausgehenden Traffic von Pods zu externen Diensten basierend auf Domainnamen steuern möchten, 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 basierend auf DNS auflöst und aktualisiert.

  • 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.

Stufen der Richtlinienbewertung

GKE wertet Netzwerksicherheitsrichtlinien in drei hierarchischen Ebenen aus.

  1. Administratorebene (ClusterNetworkPolicy): Die höchste Priorität. Mit dieser Stufe können Sie obligatorische Sicherheitsanforderungen durchsetzen. Ablehnen-Regeln in dieser Stufe haben Vorrang vor allen anderen Richtlinien. Accept-Regeln lassen Traffic zu und beenden die Auswertung für dieses Paket.
  2. NetworkPolicy-Stufe: Die Stufe, in der Entwickler anwendungsspezifische Sicherheit definieren. Richtlinien umfassen die Standardressourcen NetworkPolicy, FQDNNetworkPolicy und CiliumClusterwideNetworkPolicy.
  3. Baseline-Stufe (ClusterNetworkPolicy): die niedrigste Prioritätsstufe. Mit dieser Stufe können Sie Standard-Guardrails für „Standardmäßig ablehnen“ festlegen, die Entwickler in der NetworkPolicy-Stufe selektiv überschreiben können.

Wenn in keiner Ebene Richtlinien übereinstimmen, verwendet GKE standardmäßig das implizite Verhalten „Alle zulassen“.

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)
Erzwingen Sie obligatorische, nicht überschreibbare Sicherheitsmechanismen. ClusterNetworkPolicy (Administratorstufe)
Standardmäßige „Zero-Trust“-Vorkehrungen treffen, die Entwickler überschreiben können. ClusterNetworkPolicy (Basistarif)
Konfigurieren Sie proprietäre clusterweite Richtlinien (nicht für neue Bereitstellungen empfohlen). CiliumClusterwideNetworkPolicy
Verbindungen, die von 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. Netzwerkrichtlinien-Logging ist das primäre Tool dafür.

Wenn Sie das Logging von Netzwerkrichtlinien aktivieren, generiert GKE für jede Verbindung, die von einer Netzwerkrichtlinie zugelassen oder abgelehnt wird, einen Logeintrag in Cloud Logging. Diese Logs sind für die Sicherheitsprüfung 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.

Im Gegensatz zu Standardrichtlinien, die nur „Zulassen“-Aktionen unterstützen, unterstützen ClusterNetworkPolicy-Ressourcen explizite Ablehnen-Aktionen. Wenn durch eine administrative Richtlinie Traffic verworfen wird, werden die Attribute des Logeintrags der spezifischen Richtlinie zugeordnet, die für die Blockierung verantwortlich ist.

Nächste Schritte