GKE-Cluster für Mandanten von Drittanbietern vorbereiten

Last reviewed 2022-02-10 UTC

In diesem Dokument werden Steuerelemente zum Konfigurieren und Sichern von GKE-Clustern (Google Kubernetes Engine) vorgestellt, auf denen benutzerdefinierte Anwendungen gehostet werden, die über Mandanten von Drittanbietern verteilt werden. Es ist Teil einer Blueprint-Lösung, die aus Folgendem besteht:

  • Eine Übersicht über die von Ihnen implementierten Steuerungen (dieses Dokument).
  • Ein GitHub-Repository mit folgenden Verzeichnissen:
    • terraform: Enthält den Terraform-Code, den Sie zum Erstellen der Infrastruktur und Ressourcen auf Projektebene verwenden. Mit diesem Code werden auch Anthos-Komponenten im Cluster installiert.
    • configsync: Enthält die Ressourcen und Konfigurationen auf Clusterebene, die auf Ihren GKE-Cluster angewendet werden.
    • tenant-config-pkg: Ein kpt-Paket, das Sie als Vorlage zum Konfigurieren neuer Mandanten im GKE-Cluster verwenden können.

Dieses Dokument richtet sich an Teams, die GKE-Cluster verwalten. Dabei wird davon ausgegangen, dass Sie mit GKE und Kubernetes vertraut sind.

In diesem Dokument wird davon ausgegangen, dass Sie bereits eine Reihe grundlegender Sicherheitskontrollen zum Schutz Ihrer Cloud-Infrastruktur konfiguriert haben, beispielsweise die im Google Cloud Security Foundations Guide beschriebenen Kontrollen. Mit dem Blueprint können Sie Ihre vorhandenen Sicherheitskontrollen durch zusätzliche Kontrollen erweitern, um Ihre CKE-Cluster zu schützen.

Architektur

Das folgende Diagramm beschreibt die Architektur, die Sie mit diesem Blueprint erstellen:

Infrastrukturkomponenten des Blueprints.

Wie im vorherigen Diagramm gezeigt, unterstützt Sie der Blueprint beim Erstellen und Konfigurieren der folgenden Infrastrukturkomponenten:

  • Ein VPC-Netzwerk (Virtual Private Cloud) und ein Subnetz.
  • Ein privater GKE-Cluster. Die Clusterknoten sind vom Internet isoliert.
  • Zwei GKE-Knotenpools. Sie erstellen einen dedizierten Knotenpool, um ausschließlich Mandantenanwendungen und -ressourcen zu hosten. Andere Clusterressourcen werden im Standardknotenpool gehostet.
  • VPC-Firewallregeln. Sie erstellen allgemeine Regeln, die für alle Knoten im Cluster gelten. Sie erstellen zusätzliche Regeln, die nur für die Knoten im Knotenpool des Mandanten gelten. Diese Firewallregeln begrenzen den Traffic, der von den Mandantenknoten ausgeht.
  • Cloud NAT, um ausgehenden Traffic von den Clusterknoten zum Internet zuzulassen.
  • Cloud DNS-Regeln, die zur Aktivierung des privaten Google-Zugriffs konfiguriert werden, sodass Anwendungen innerhalb des Clusters auf Google APIs zugreifen können, ohne das Internet zu durchlaufen.
  • Dienstkonten, die von den Clusterknoten und Anwendungen verwendet werden.

Anwendungen

Das folgende Diagramm zeigt die Ressourcen auf Clusterebene, die Sie mit dem Blueprint erstellen und konfigurieren.

Ressourcen auf Clusterebene.

Wie im vorherigen Diagramm gezeigt, verwenden Sie im Blueprint Folgendes, um die Ressourcen auf Clusterebene zu erstellen und zu konfigurieren:

  • Config Sync von Anthos Config Management, um die Clusterkonfiguration und -richtlinien aus einem Git-Repository zu synchronisieren.
  • Policy Controller von Anthos Config Management, um Richtlinien für Ressourcen im Cluster zu erzwingen.
  • Anthos Service Mesh zum Steuern und Sichern des Netzwerktraffics.
  • Ein dedizierter Namespace für Mandantenanwendungen und -ressourcen.
  • Richtlinien und Kontrollen, die auf den Mandanten-Namespace angewendet werden, einschließlich Netzwerkrichtlinien und Service Mesh-Richtlinien.

Informationen zu den erforderlichen Sicherheitseinstellungen

In diesem Abschnitt werden die Steuerelemente erläutert, die Sie mit dem Blueprint anwenden, um Ihren GKE-Cluster zu sichern.

Verbesserte Sicherheit von GKE-Clustern

Cluster gemäß den Best Practices für die Sicherheit erstellen

Der Blueprint unterstützt Sie beim Erstellen eines GKE-Clusters mit den folgenden Sicherheitseinstellungen:

Weitere Informationen zu den GKE-Sicherheitseinstellungen finden Sie unter Sicherheit von Clustern erhöhen.

VPC-Firewallregeln

Traffic zwischen virtuellen Maschinen einschränken

VPC-Firewallregeln steuern, welcher Traffic zu oder von Compute Engine-VMs zugelassen wird. Mit den Regeln können Sie Traffic auf VM-Ebene in Abhängigkeit von Layer-4-Attributen filtern.

Sie erstellen einen GKE-Cluster mit den Standard-Firewallregeln für GKE-Cluster. Diese Firewallregeln ermöglichen die Kommunikation zwischen den Clusterknoten und der GKE-Steuerungsebene sowie zwischen Knoten und Pods im Cluster.

Sie wenden zusätzliche Firewallregeln auf die Knoten im Mandantenknotenpool an. Diese Firewallregeln beschränken den ausgehenden Traffic von den Mandantenknoten. Mit diesem Ansatz können Sie die Isolation der Mandantenknoten erhöhen. Standardmäßig wird der gesamte ausgehende Traffic von den Mandantenknoten abgelehnt. Jeder erforderliche ausgehende Traffic muss explizit konfiguriert werden. Beispielsweise verwenden Sie den Blueprint, um Firewallregeln zu erstellen, um ausgehenden Traffic von den Mandantenknoten zur GKE-Steuerungsebene und zu Google APIs mithilfe von privatem Google-Zugriff zuzulassen. Die Firewallregeln werden mithilfe des Dienstkontos des Mandantenknotenpools auf die Mandantenknoten ausgerichtet.

Namespaces

Ressourcen, die denselben Richtlinien folgen sollen, mit Labels versehen

Mit Namespaces können Sie einen Bereich für zusammengehörige Ressourcen innerhalb eines Clusters angeben, z. B. Pods, Dienste und Replikationscontroller. Durch die Verwendung von Namespaces können Sie die Verwaltungsverantwortung für die zugehörigen Ressourcen als Einheit delegieren. Daher sind Namespaces ein wichtiger Bestandteil der meisten Sicherheitsmuster.

Namespaces sind ein wichtiges Feature zur Isolierung von Steuerungsebenen. Sie bieten jedoch keine Isolation von Knoten, Datenebenen oder Netzwerken.

Ein gängiger Ansatz besteht darin, Namespaces für einzelne Anwendungen zu erstellen. Sie können beispielsweise den Namespace myapp-frontend für die UI-Komponente einer Anwendung erstellen.

Der Blueprint unterstützt Sie beim Erstellen eines dedizierten Namespace zum Hosten der Drittanbieteranwendungen. Der Namespace und seine Ressourcen werden innerhalb Ihres Clusters als Mandanten behandelt. Sie wenden Richtlinien und Steuerelemente auf den Namespace an, um den Umfang der Ressourcen im Namespace einzuschränken.

Netzwerkrichtlinien

Netzwerk-Trafficfluss in Clustern durchsetzen

Netzwerkrichtlinien erzwingen Layer-4-Netzwerk-Trafficflüsse mithilfe von Firewallregeln auf Pod-Ebene. Netzwerkrichtlinien sind auf einen Namespace beschränkt.

Mit dem Blueprint wenden Sie Netzwerkrichtlinien auf den Mandanten-Namespace an, in dem die Anwendungen von Drittanbietern gehostet werden. Standardmäßig lehnt die Netzwerkrichtlinie den gesamten Traffic zu und von Pods im Namespace ab. Jeder erforderliche Traffic muss explizit auf die Zulassungsliste gesetzt werden. Beispielsweise lassen die Netzwerkrichtlinien im Blueprint explizit Traffic zu den erforderlichen Clusterdiensten wie dem internen Cluster-DNS und der Steuerungsebene von Anthos Service Mesh zu.

Config Sync

Konfigurationen auf GKE-Cluster anwenden

Config Sync synchronisiert Ihre GKE-Cluster mit Konfigurationen, die in einem Git-Repository gespeichert sind. Das Git-Repository fungiert als zentrale Informationsquelle für Ihre Clusterkonfiguration und -richtlinien. Config Sync ist deklarativ. Der Dienst prüft kontinuierlich den Clusterstatus und wendet den in der Konfigurationsdatei deklarierten Status zur Erzwingung von Richtlinien an. Dadurch werden Abweichungen von der Konfiguration verhindert.

Sie installieren Config Sync in Ihrem GKE-Cluster. Sie konfigurieren Config Sync so, dass Clusterkonfigurationen und -richtlinien aus dem GitHub-Repository synchronisiert werden, das mit dem Blueprint verknüpft ist. Die synchronisierten Ressourcen umfassen Folgendes:

  • Anthos Service Mesh-Konfiguration auf Clusterebene
  • Sicherheitsrichtlinien auf Clusterebene
  • Konfiguration und Richtlinie auf Mandantenebene, darunter Netzwerkrichtlinien, Dienstkonten, RBAC-Regeln und die Anthos Service Mesh-Konfiguration

Policy Controller

Einhaltung von Richtlinien durchsetzen

Anthos Policy Controller ist eine dynamische Zugangssteuerung für Kubernetes, die CRD-basierte (CustomResourceDefinition) Richtlinien erzwingt, die von Open Policy Agent (OPA) ausgeführt werden.

Zugangssteuerungen sind Kubernetes-Plug-ins, die Anfragen an den Kubernetes API-Server abfangen, bevor ein Objekt beibehalten wird, aber nachdem die Anfrage authentifiziert und autorisiert wurde. Sie können die Verwendung von Clustern mithilfe von Zugangssteuerungen einschränken.

Sie installieren Policy Controller in Ihrem GKE-Cluster. Der Blueprint enthält Beispielrichtlinien, um Ihren Cluster zu schützen. Sie wenden die Richtlinien automatisch mit Config Sync auf Ihren Cluster an. Sie wenden die folgenden Richtlinien an:

Anthos Service Mesh

Sichere Kommunikation zwischen Diensten verwalten

Mit Anthos Service Mesh können Sie ein Istio-basiertes Service Mesh überwachen und verwalten. Ein Service Mesh ist eine Infrastrukturebene, mit der Sie eine verwaltete, beobachtbare und sichere Kommunikation zwischen Ihren Diensten erstellen können.

So vereinfacht Anthos Service Mesh die Verwaltung sicherer Kommunikation zwischen Diensten:

  • Verwalten der Authentifizierung und Verschlüsselung des Traffics (unterstützte Protokolle im Cluster mithilfe von gegenseitiger Transportschichtkommunikation (mTLS)). Anthos Service Mesh verwaltet die Bereitstellung und Rotation von mTLS-Schlüsseln und Zertifikaten für Anthos-Arbeitslasten, ohne die Kommunikation zu unterbrechen. Die regelmäßige Rotation von mTLS-Schlüsseln ist eine bewährte Sicherheitsmethode zum Reduzieren des Risikos bei einem Angriff.
  • Hiermit können Sie Netzwerksicherheitsrichtlinien konfigurieren, die auf der Dienstidentität basieren und nicht auf der IP-Adresse eines Peers im Netzwerk. Anthos Service Mesh wird verwendet, um Richtlinien für die identitätsbewusste Zugriffssteuerung (Firewall) zu konfigurieren, mit denen Sie Sicherheitsrichtlinien erstellen können, die vom Netzwerkstandort der Arbeitslast unabhängig sind. Dieser Ansatz vereinfacht das Einrichten von Dienst-zu-Dienst-Kommunikationsrichtlinien.
  • Hiermit können Sie Richtlinien konfigurieren, die Zugriff von bestimmten Clients gewähren.

Der Blueprint führt Sie zur Installation von Anthos Service Mesh in Ihrem Cluster. Sie konfigurieren den Mandanten-Namespace für die automatische Sidecar-Proxy-Einfügung. Dieser Ansatz gewährleistet, dass Anwendungen im Mandanten-Namespace Teil des Mesh sind. Sie konfigurieren Anthos Service Mesh automatisch mit Config Sync. Sie konfigurieren das Mesh-Netzwerk für Folgendes:

  • mTLS-Kommunikation zwischen Diensten im Mesh-Netzwerk erzwingen.
  • Ausgehenden Traffic vom Mesh-Netzwerk auf bekannte Hosts beschränken.
  • Autorisierte Kommunikation zwischen Diensten im Mesh-Netzwerk beschränken. Anwendungen im Mandanten-Namespace können beispielsweise nur mit Anwendungen im selben Namespace oder mit einer Reihe bekannter externer Hosts kommunizieren.
  • Den gesamten ausgehenden Traffic über ein Mesh-Gateway weiterleiten, in dem Sie weitere Trafficsteuerungen anwenden können.

Knotenmarkierungen und -affinitäten

Planung der Arbeitslasten steuern

Knotenmarkierungen und Knotenaffinität sind Kubernetes-Mechanismen, mit denen Sie die Planung von Pods auf Clusterknoten beeinflussen können.

Markierungsknoten verwerfen Pods. Kubernetes plant einen Pod nicht auf einem markierten Knoten, es sei denn, der Pod hat eine Toleranz für die Markierung. Sie können mit Knotenmarkierungen Knoten für bestimmte Arbeitslasten oder Mandanten reservieren. Markierungen und Toleranzen werden häufig in mehrmandantenfähigen Clustern verwendet. Weitere Informationen finden Sie in der Dokumentation zu dedizierten Knoten mit Markierungen und Toleranzen.

Mit der Knotenaffinität können Sie Pods auf Knoten mit bestimmten Labels beschränken. Wenn ein Pod eine Knotenaffinitätsanforderung hat, plant Kubernetes den Pod nur dann auf einem Knoten, wenn dieser ein der Affinitätsanforderung entsprechendes Label hat. Mit der Knotenaffinität können Sie dafür sorgen, dass Pods auf geeigneten Knoten geplant werden.

Sie können Knotenmarkierungen und Knotenaffinität zusammen verwenden, um dafür zu sorgen, dass Pods von Mandanten-Arbeitslasten ausschließlich auf Knoten geplant werden, die für den Mandanten reserviert sind.

Mit dem Blueprint können Sie die Planung der Mandantenanwendungen so steuern:

  • GKE-Knotenpool für den Mandanten erstellen. Jeder Knoten im Pool hat eine Markierung für den Mandantennamen.
  • Die entsprechende Toleranz und Knotenaffinität wird automatisch auf jeden Pod angewendet, der auf den Mandanten-Namespace ausgerichtet ist. Sie wenden Toleranz und Affinität mit PolicyController-Mutationen an.

Geringste Berechtigung

Zugriff auf Cluster- und Projektressourcen beschränken

Es ist eine bewährte Sicherheitsmethode nach dem Prinzip der geringsten Berechtigung für Ihre Google Cloud-Projekte und -Ressourcen wie GKE-Cluster. Auf diese Weise haben die Anwendungen, die in Ihrem Cluster ausgeführt werden, und die Entwickler und Operatoren, die den Cluster verwenden, nur die erforderlichen Mindestberechtigungen.

Der Blueprint unterstützt Sie auf folgende Weise bei der Verwendung von Dienstkonten mit minimalen Berechtigungen:

  • Jeder GKE-Knotenpool erhält ein eigenes Dienstkonto. Beispielsweise verwenden die Knoten im Mandantenknotenpool ein Dienstkonto, das diesen Knoten zugeordnet ist. Die Knoten-Dienstkonten werden mit den erforderlichen Mindestberechtigungen konfiguriert.
  • Der Cluster verwendet Workload Identity, um Kubernetes-Dienstkonten mit Google-Dienstkonten zu verknüpfen. Auf diese Weise können die Mandantenanwendungen eingeschränkten Zugriff auf alle erforderlichen Google APIs erhalten, ohne einen Dienstkontoschlüssel herunterladen und speichern zu müssen. Beispielsweise können Sie dem Dienstkonto Berechtigungen zum Lesen von Daten aus einem Cloud Storage-Bucket erteilen.

Mit dem Blueprint können Sie den Zugriff auf Clusterressourcen einschränken:

  • Sie erstellen eine Kubernetes-RBAC-Beispielrolle mit eingeschränkten Berechtigungen zum Verwalten von Anwendungen. Sie können diese Rolle den Nutzern und Gruppen zuweisen, die die Anwendungen im Mandanten-Namespace ausführen. Auf diese Weise sind diese Nutzer nur berechtigt, Anwendungsressourcen im Mandanten-Namespace zu ändern. Sie sind nicht berechtigt, Ressourcen auf Clusterebene oder sensible Sicherheitseinstellungen wie Anthos Service Mesh-Richtlinien zu ändern.

Zusammenfassung

So implementieren Sie die in diesem Dokument beschriebene Architektur:

  1. Prüfen Sie, ob Sie diesen Blueprint zusammen mit dem Sicherheitsgrundlagen-Blueprint bereitstellen möchten. Wenn Sie den Blueprint zu Sicherheitsgrundlagen nicht bereitstellen möchten, muss Ihre Umgebung eine ähnliche Sicherheits-Baseline haben.
  2. Lesen Sie die Readme-Datei für den Blueprint und achten Sie darauf, dass Sie alle Voraussetzungen erfüllen.
  3. Stellen Sie in Ihrer Testumgebung eine Instanz dieser Architektur bereit. Führen Sie im Rahmen des Testverfahrens die folgenden Schritte aus:
    1. Stellen Sie einen Beispiel-Mandantendienst bereit und prüfen Sie die Konfiguration des Clusters.
    2. Fügen Sie dem Cluster einen weiteren Mandanten hinzu.
  4. Stellen Sie den Blueprint in Ihrer Produktionsumgebung bereit.
  5. Fügen Sie dem Cluster weitere Mandanten hinzu.

Nächste Schritte