Best Practices für die Verwendung der Workload Identity von Flotten

Wie Sie unter Authentifizierung bei APIs und Diensten aus Flottenarbeitslasten wissen, ist die flottenweite Workload Identity-Föderation ein leistungsstarkes Flottenfeature, das die Einrichtung der Authentifizierung bei Google Cloud für Ihre Anwendungen in verschiedenen Projekten vereinfacht. Es kann dabei jedoch zusätzliche Zugriffssteuerungsaspekte geben, die über die für die reguläre Identitätsföderation von Arbeitslasten für GKE hinausgehen. In diesem Leitfaden finden Sie einige Beispiele für diese potenziellen Probleme und Informationen dazu, wie Sie Ihre Flotten organisieren können, um mögliche Risiken zu minimieren.

Bevor Sie diesen Leitfaden lesen, sollten Sie mit den Konzepten unter Über Workloads der Flotte bei APIs und Diensten authentifizieren vertraut sein.

Best Practices zur Einführung anderer Flottenfeatures finden Sie unter Flottenfeatures planen.

Flotten- und Projektidentitätspools

Um zu verstehen, warum die flottenweite Workload Identity-Föderation besonders bei der Arbeit mit Flotten mit mehreren Projekten sorgfältig eingeführt werden muss, sehen wir uns genauer an, wie die reguläre Workload Identity-Föderation für GKE und die Workload Identity-Föderation für Flotten funktionieren. In beiden Fällen werden Arbeitslasten mithilfe von kurzlebigen Tokens authentifiziert, die von den Clustern generiert werden. Jeder Cluster wird einem speziellen Workload Identity-Pool als Identitätsanbieter hinzugefügt. Arbeitslasten, die in einem bestimmten Namespace ausgeführt werden, können dann dieselbe IAM-Identität in mehreren Clustern verwenden.

Folgendes geschieht mit der regulären Identitätsföderation von Arbeitslasten für GKE, wenn sie für Ihre Cluster aktiviert ist. Beachten Sie, dass die Identitätsföderation von Arbeitslasten für GKE standardmäßig für Autopilot-Cluster aktiviert ist.

  1. GKE erstellt einen von Google verwalteten Workload Identity-Pool im Projekt des Clusters: PROJECT_ID.svc.goog.id.
  2. GKE fügt dem Pool die Cluster als Identitätsanbieter hinzu.
  3. Daher haben Arbeitslasten, die in einem bestimmten Namespace ausgeführt werden, in allen Clustern innerhalb eines Projekts dieselbe IAM-Identität. Die Identität hat das folgende Format: serviceAccount:PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME].

Flottenweite Workload Identity-Föderation wird automatisch aktiviert, wenn Sie einer Flotte einen Cluster mit aktivierter Identitätsföderation von Arbeitslasten für GKE hinzufügen, einschließlich Autopilot-Clustern, Standardclustern bei denen die Funktion explizit aktiviert und GKE-Clustern außerhalb von Google Cloud “

Das passiert, wenn ein Nutzer einen Cluster mit aktivierter Workload Identity Federation for GKE bei einer Flotte registriert:

  1. Der von Google verwaltete flottenweite Workload Identity-Pool FLEET_PROJECT_ID.svc.goog.id im Flotten-Hostprojekt wird erstellt, wenn der Pool nicht bereits vorhanden ist. Dieser entspricht dem Workload Identity-Pool des Projekts für das Flotten-Hostprojekt.
  2. Der Cluster wird als Identitätsanbieter dem Pool hinzugefügt.
  3. Das hat zur Folge, dass sich Arbeitslasten, die in einem bestimmten Namespace ausgeführt werden, dieselbe IAM-Identität in allen Clustern innerhalb der Flotte teilen. Wir bezeichnen dies als implizite Gleichheit der Workload Identitys der Flotte. Die Identität hat folgendes Format: serviceAccount:FLEET_PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME]. Flottenarbeitslasten in verschiedenen Projekten können dann Google APIs mit derselben Identität für die Authentifizierung aufrufen.

Wenn die Flotte nur Cluster aus einem Projekt enthält und alle bei der Flotte registriert sind, ist das Ergebnis dasselbe, als ob Sie nur Workload Identity Federation for GKE ohne Flotten verwenden: Alle Cluster sind Identitätsanbieter in dem projektweiten Workload Identity-Pool und die Arbeitslasten verwenden dieselben Identitäten, die sie auch mit Workload Identity Federation for GKE verwenden würden. Wenn die Flotte jedoch Mitgliedscluster in mehreren Projekten hat, kombiniert die Workload Identity-Föderation der Flotte die Identitätspools pro Projekt zu einem einzigen flottenweiten Identitätspool, der im Flotten-Hostprojekt gehostet wird.

Wie Sie in den folgenden Beispielen sehen, kann es zu Komplexitäten kommen, wenn sich die Cluster in einem Projekt nur teilweise mit den Clustern in diesem Projekt überschneiden, die zu einer Flotte gehören.

Szenario 1: Eine einzelne Projektflotte bei der alle Cluster registriert

In diesem Szenario befinden sich alle Mitgliedscluster der Flotte im Flotten-Hostprojekt und alle Cluster in diesem Projekt sind Mitglieder der Flotte.

Diagramm mit einem Projekt mit allen Clustern in derselben Flotte

Wie im vorherigen Abschnitt beschrieben, ist die Verwendung der flottenweiten Identitätsföderation von Arbeitslasten in diesem Szenario das gleiche wie die Verwendung der regulären Identitätsföderation von Arbeitslasten für GKE und es gibt kein zusätzliches Risiko.

Szenario 2: Einzelne Projektflotte bei der einige Cluster registriert

In diesem Szenario enthält eine Flotte zwei Cluster, die sich beide im Flotten-Hostprojekt „Projekt 1“ befinden. Das Flotten-Hostprojekt enthält auch einen dritten Cluster, der kein Flottenmitglied ist, für den die Identitätsföderation von Arbeitslasten für GKE aktiviert ist.

Diagramm mit einem Projekt mit einigen Clustern in derselben Flotte

Das bedeutet:

  • Die Cluster 1, 2 und 3 werden von GKE dem Workload Identity-Pool project-1.svc.goog.id des Projekts hinzugefügt.
  • Die Cluster 1 und 2 werden von der Flotte dem Flotten-Workload Identity-Pool hinzugefügt, der (da dies das Flotten-Hostprojekt ist) auch der Workload Identity-Pool project-1.svc.goog.id des Projekts ist.

Der Administrator möchte Berechtigungen für Arbeitslasten erteilen, die in einem Namespace in allen Clustern der Flotte ausgeführt werden. Sie verwenden serviceAccount:project-1.svc.goog.id[namespace/ksa] als Identität, um Zugriff zu gewähren. Arbeitslasten in diesem Namespace in Cluster 3, der nicht Teil der Flotte ist, teilen sich jetzt jedoch denselben Zugriff. Das liegt daran, dass sich Cluster 3 im Workload Identity-Pool des Projekts befindet, welcher (da dies das Flotten-Host-projekt ist) mit dem Workload Identity-Pool der Flotte identisch ist. Mit anderen Worten: Der Administrator möchte möglicherweise nur Clustern in einer Flotte Berechtigungen erteilen, aber aufgrund der Implementierung der Identitätsföderation von Arbeitslasten für Flotten erhalten möglicherweise auch Cluster außerhalb der Flotte Zugriff.

Mögliche Abhilfe

Eine mögliche Lösung besteht darin, ein dediziertes Projekt zum Hosten der Flotte ohne Cluster zu erstellen, das durch eine benutzerdefinierte Organisationsrichtlinie für die Container API erzwungen wird. Dies bietet eine klare Trennung der Vertrauensdomain des Flotten-Workload Identity-Pools von den Vertrauensdomains auf GKE-Projektebene.

Diagramm mit zwei Projekten, eines mit Clustern, das andere fungiert als Flotten-Hostprojekt

Der Administrator kann dann die entsprechende vertrauenswürdige Domain auswählen, wenn er Berechtigungen für Arbeitslasten erteilt. Beispielsweise können sie mit serviceAccount:project-0.svc.goog.id[namespace/ksa] einer Namespace-Arbeitslast in der gesamten Flotte Berechtigungen erteilen. Der Nicht-Flottenmitglied-Cluster 3 ist in dieser Einrichtung nicht Teil dieses Workload Identity-Pools und erhält daher keinen Zugriff.

Diese Lösung funktioniert für Cluster in Google Cloud und angehängten Clustern.

Szenario 3: Flotte mit Mehrere Projekte mit einigen registrierten Clustern

In diesem Szenario hat eine Flotte Mitglieder aus zwei Projekten: Projekt 1 und Projekt 2.

Diagramm mit einer Flotte mit Clustern aus zwei Projekten

Der Administrator möchte mithilfe der regulären Identitätsföderation von Arbeitslasten für GKE Berechtigungen für Arbeitslasten erteilen, die in einem Namespace in allen Clustern in Projekt 1 ausgeführt werden. Da Cluster 4 jedoch bei der Flotte registriert ist und Projekt 1 das Flotten-Hostprojekt ist, erhalten auch Arbeitslasten auf Cluster 4 in Projekt 2 dieselben Berechtigungen.

Mögliche Abhilfe

Wie im vorherigen Szenario können Sie auch hier ein spezielles Flottenhostprojekt ohne Cluster erstellen, um das Problem zu beheben. So kann der Administrator bei der Einrichtung der Zugriffssteuerung zwischen Identitäten aus dem Flotten-Identitätspool und dem Projekt-Identitätspool jedes Clusters unterscheiden.

Szenario 4: Namespace-Gleichheit berücksichtigen

Workload Identity-Pools sind nicht der einzige potenzielle Bereich für Verwirrung bei der Verwendung der Workload Identity-Föderation. Wie Sie aus dem Artikel Flottenfunktionen planen wissen, wird bei vielen Flottenfunktionen, einschließlich der Identitätsföderation von Arbeitslasten für Flotten, die Annahme der Namespace-Gleichheit verwendet, um die Konfiguration und Verwaltung der gesamten Flotte zu vereinfachen. Das bedeutet, dass Namespaces mit demselben Namen in mehreren Clustern von Flottenmitgliedern so behandelt werden, als wären sie derselbe Namespace. In diesem Beispiel hat ein Administrator Arbeitslasten im Namespace „NS1“ Berechtigungen erteilt, die auf den Clustern „Cluster 1“ und „Cluster 2“ der Flotte ausgeführt werden.

Diagramm mit Clustern aus zwei Projekten mit demselben Namespace

Ein Nutzer hat jedoch (versehentlich oder böswillig) einen Namespace mit demselben Namen in einem anderen Cluster der Flottenmitglieds ist erstellt. Aufgrund der Annahme der Namespace-Gleichheit erhalten Arbeitslasten in diesem Namespace automatisch dieselben Berechtigungen wie legitime NS1-Arbeitslasten in Cluster 1 und Cluster 2.

Mögliche Abhilfe

Legen Sie Berechtigungen so fest, dass nur eine kleine Gruppe vertrauenswürdiger Rollen Namespaces in Clustern erstellen kann.