Anthos-Sicherheits-Blueprint: Standortbeschränkungen für Cluster in Google Cloud durchsetzen

In diesem Dokument wird beschrieben, wie Sie Ressourcen so verwalten, dass sie nur in bestimmten Regionen verfügbar sind. Es enthält eine Übersicht darüber, wie und warum Sie Standortbeschränkungen erfüllen müssen, und beschreibt die Google Cloud-Steuerelemente, die für diese Aufgabe verwendet werden.

Das Dokument ist Teil einer Reihe von Sicherheits-Blueprints, die eine präskriptive Anleitung für die Arbeit mit Anthos bieten. Weitere Informationen zu diesen Entwürfen finden Sie unter Sicherheitshinweise zu Anthos-Sicherheit: häufig gestellte Fragen.

Einführung

Viele Unternehmen müssen standortspezifische Anforderungen erfüllen. Das heißt, ihre Dienste – und in vielen Fällen die Cluster, auf denen die Dienste ausgeführt werden – dürfen nur von bestimmten Standorten aus bereitgestellt werden oder zugänglich sein. Dafür kann es verschiedene Gründe geben: gesetzliche Vorschriften, Latenzanforderungen oder eine geschäftliche Bedingung, den Dienst nur in bestimmten Ländern anzubieten.

Folgendes ist zu beachten, um standortspezifische Anforderungen zu erfüllen:

  • Wo sich die Dienste befinden müssen.
  • Ob Sie den Zugriff von bestimmten Regionen aus auf Ihre Dienste einschränken müssen.
  • Von welchen Google Cloud-Diensten Ihre Dienste abhängen.
  • Ob Sie GKE in Google Cloud oder lokal verwenden.
  • Welche Abläufe und Vorgänge innerhalb sowie zu und von Ihrer Anwendung zulässig sind.

Wenn diese Fragen geklärt sind, können Sie entscheiden, wie Sie die jeweiligen Sicherheitseinstellungen so konfigurieren, dass sie Ihren standortspezifischen Anforderungen entsprechen.

Informationen zu den nötigen Sicherheitseinstellungen

In diesem Abschnitt werden die Steuerelemente erläutert, mit denen Sie das für Sie passende Maß an Standortbeschränkung erreichen können.

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

Organisationsrichtlinien

Standorte beschränken, in denen Sie Cluster bereitstellen können

Mit dem Organisationsrichtliniendienst lassen sich Einschränkungen für unterstützte Ressourcen in Ihrer Google-Organisation konfigurieren. Sie konfigurieren Einschränkungen für die unterstützten Ressourcen.

Wenn Sie Dienste auf einen Ort beschränken, verwenden Sie die Einschränkung "Beschränkung von Ressourcenstandorten". Diese Einschränkung definiert die Gruppe von Standorten, an denen standortbasierte Google Cloud-Ressourcen erstellt werden können. In den Richtlinien für diese Einschränkung können unterschiedliche zulässige oder abgelehnte Standorte angegeben werden. Die Richtlinien können beispielsweise Mehrfachregionen wie Asien und Europa, Regionen wie us-east1 oder europe-west1 oder einzelne Zonen wie europe-west1-b angeben. Jeder erlaubte oder abgelehnte Standort muss explizit aufgelistet sein.

Anthos Config Management

Konfigurationen auf Anthos-Cluster anwenden

Eine Best Practice bei der Verwaltung von Anthos-Clustern ist die Verwendung von Anthos Config Management. Dadurch werden Ihre angemeldeten Cluster mit Konfigurationen synchron gehalten. Eine Konfiguration ist eine YAML- oder JSON-Datei, die in Ihrem Repository gespeichert ist und dieselben Konfigurationsdetails enthält, die Sie manuell mit dem Befehl kubectl apply auf einen Cluster anwenden können. Mit Anthos Config Management können Sie Ihre Richtlinien und Infrastrukturbereitstellungen wie Ihre Anwendungen verwalten, nämlich indem Sie Richtlinien als Code verfügbar machen.

Sie verwenden Anthos Config Management in Verbindung mit einem Git-Repository, das als Single Source of Truth für Ihre deklarierten Richtlinien dient. Anthos Config Management kann Richtlinien für die Zugriffssteuerung wie RBAC, Ressourcenkontingente, Namespaces und Infrastrukturbereitstellungen auf Plattformebene verwalten. Anthos Config Management ist deklarativ. Es prüft kontinuierlich den Clusterstatus und verleiht den in der Konfiguration angegebenen Status, um Richtlinien durchzusetzen.

Autorisierte Netzwerke für den Clustermaster-Zugriff

Standorte einschränken, die auf den Kubernetes API-Server zugreifen können

Mit autorisierten Netzwerken können Sie bestimmte CIDR-Bereiche zulassen (auf die weiße Liste setzen) und zulassen, dass IP-Adressen in diesen Bereichen über HTTPS auf Ihren Clustermaster-Endpunkt zugreifen. Private Cluster geben keine externen IP-Adressen preis. Auf Wunsch können sie den Clustermaster auch ohne öffentlich erreichbaren Endpunkt ausführen.

Es hat sich bewährt, der Anleitung im GKE-Härtungsleitfaden zu folgen, in der die Verwendung privater Cluster in Kombination mit der Aktivierung autorisierter Netzwerke empfohlen wird.

Auswählen eines Clustertyps

Um zu verstehen, welcher Clustertyp für Ihren Anwendungsfall geeignet ist, müssen Sie die Regionen und Zonen sowie die Standorte kennen, an denen Ressourcen bereitgestellt werden können. Regionen sind unabhängige geografische Gebiete, die aus Zonen bestehen. Zum Beispiel ist London (europe-west2) eine Region innerhalb von Europa und Oregon (us-west1) eine Region innerhalb von Nord- und Südamerika.

Eine Zone ist ein Bereitstellungsbereich für Google Cloud-Ressourcen innerhalb einer Region. Zonen können als einzelne fehlerhafte Domain betrachtet werden. Für fehlertolerante Anwendungen mit Hochverfügbarkeit können Sie Ihre Anwendungen in mehreren Zonen einer Region bereitstellen.

Standorte innerhalb der Regionen haben gewöhnlich Umlauf-Netzwerklatenzen von weniger als einer Millisekunde auf dem 95. Perzentil. Ein Beispiel für einen Standort ist Tokio, Japan, das drei Zonen hat und in der Region asia-northeast1 liegt.

In GKE gibt es drei Clustertypen:

  • Einzelzonencluster. Ein Einzelzonencluster hat eine einzige Steuerungsebene (Master), die in einer Zone ausgeführt wird. Diese Steuerungsebene verwaltet Arbeitslasten auf Knoten, die in derselben Zone ausgeführt werden.
  • Cluster mit mehreren Zonen. Ein Cluster mit mehreren Zonen hat ein einzelnes Replikat der Steuerungsebene, das in einer einzelnen Zone ausgeführt wird, und Knoten, die in mehreren Zonen ausgeführt werden.
  • Regionale Cluster. Regionale Cluster replizieren Clustermaster und -knoten über mehrere Zonen in einer einzigen Region. Ein regionaler Cluster im Bereich us-east1 erstellt beispielsweise Replikate der Steuerungsebene und der Knoten in den drei us-east1-Zonen: us-east1-b, us-east1-c und us-east1-d.

Sie sollten den Cluster auswählen, der Ihren Anforderungen an die Verfügbarkeit entspricht. Wenn Ihre Arbeitslasten beispielsweise hochverfügbar sein sollen, verwenden Sie einen regionalen Cluster.

Zusammenfassung

Ermitteln Sie die Anforderungen für die Standortbeschränkung, um die Steuerelemente einzubinden. Legen Sie dann den Bereich der in diesem Leitfaden beschriebenen Steuerelemente und die Phase, in der sie konfiguriert werden müssen, so fest:

  1. Definieren Sie Ihre regionalen Anforderungen.
  2. Ermitteln Sie den geeigneten Standort für Ihren Cluster.
  3. Erstellen Sie eine Organisationsrichtlinie für Ressourcenstandorte, um die Erstellung von GKE-Clustern auf die Standorte zu beschränken, die Ihren Anforderungen entsprechen.
  4. Erstellen Sie Ihre privaten Cluster gemäß der Anleitung im Leitfaden zum Härten von GKE-Clustern. Folgen Sie beim Erstellen des Clusters dem Härtungsleitfaden und verwenden Sie das Flag --enable-network-policy. Netzwerkrichtlinien sind erforderlich. Mit diesem Schritt können Sie später Firewallregeln einbinden, die den Traffic zwischen Pods in einem Cluster einschränken.
  5. Fügen Sie Ihren privaten Clustern autorisierte Netzwerke hinzu.

Wenn Sie die Orte einschränken möchten, von denen Kunden auf Ihre Dienste zugreifen können, gehen Sie so vor:

  • Definieren Sie für GKE in Google Cloud-Clustern eine Google Cloud Armor-Sicherheitsrichtlinie, um die Zugriffssteuerung anhand des geografischen Ausgangspunktes des eingehenden Traffics zu erzwingen. Hängen Sie die Sicherheitsrichtlinie an jedes Back-End an, das mit der Ingress-Ressource verknüpft ist.
  • Verwenden Sie Anthos Config Management, um mit Richtlinien einzuschränken, wer auf Ihre Cluster zugreifen kann.