Risiken der Identitätsgleichheit in mehrmandantenfähigen Flotten reduzieren

Auf dieser Seite finden Sie Best Practices zum Konfigurieren und Verwenden der Identitätsföderation von Arbeitslasten für Flotten, Dieses Flottenfeature ermöglicht es Ihnen, die Authentifizierung von Anwendungen bei Google Cloud APIs projektübergreifend zentral einzurichten. Best Practices zur Einführung anderer Flottenfeatures finden Sie unter Flottenfeatures planen.

Diese Seite richtet sich an Plattformadministratoren und ‑operatoren sowie an Sicherheitsingenieure, die die Risiken minimieren möchten, die mit der Identitätsgleichheit in Flotten verbunden sind.

Machen Sie sich vor dem Lesen dieser Seite mit den Konzepten unter Identitätsföderation von Arbeitslasten für Flottenvertraut.

Terminologie

Auf dieser Seite wird die folgende Terminologie verwendet:

  • Workload Identity Federation for GKE: Ein Feature, das GKE-Arbeitslasten in einem einzelnen Google Cloud Projekt Identitäten zuweist.
  • Identitätsföderation von Arbeitslasten für Flotten: Ein Feature, das Workload Identity Federation for GKE auf Arbeitslasten in der gesamten Flotte erweitert, auch außerhalb Google Cloud und in mehreren Projekten.
  • Workload Identity-Pool: Eine Entität, die Arbeitslasten Identitäten in einem Format zuweist, das mit Identity and Access Management (IAM) kompatibel ist. Jeder Cluster ist ein Identitätsanbieter in einem Workload Identity-Pool.

Identitätsgleichheit in Flotten

Workload Identity-Pools sind Entitäten, die Arbeitslasten Identitäten in einem Format zuweisen, das IAM bei der Authentifizierung und Autorisierung von Anfragen verwenden kann. Mit Workload Identity Federation for GKE hat jedes Projekt standardmäßig einen festen, von Google verwalteten Workload Identity-Pool, der für dieses Projekt eindeutig ist.

Bei der Identitätsföderation von Arbeitslasten für Flotten ist der von Google verwaltete Workload Identity-Pool für das Flotten-Hostprojekt der Standard-Workload Identity-Pool für alle Cluster, die Sie in der Flotte registrieren, unabhängig davon, ob sich die Cluster in anderen Projekten oder anderen Clouds befinden. Optional können Sie einen selbstverwalteten Workload Identity-Pool für bestimmte Cluster einrichten, der anstelle des Standardpools verwendet werden soll.

Sowohl bei der Identitätsföderation von Arbeitslasten für Flotten als auch bei der Identitätsföderation von Arbeitslasten für GKE verwenden Sie IAM-Zulassungsrichtlinien, um Entitäten in Ihren Clustern, z. B. Kubernetes-Dienstkonten oder Pods, Rollen für bestimmte Google Cloud Ressourcen zuzuweisen. In Ihren Zulassungsrichtlinien verweisen Sie auf diese Entitäten mit einer Prinzipal-ID. Das ist eine Namenssyntax, die von IAM gelesen werden kann . Die Hauptkonto-ID enthält den Namen des Workload Identity-Pools, den der Cluster verwendet, und andere Informationen, mit denen die spezifischen Entitäten im Cluster ausgewählt werden. Die folgende Hauptkonto-ID wählt beispielsweise ein Kubernetes-Dienstkonto in einem Namespace aus:

principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_IDENTITY_POOL_NAME/subject/ns/NAMESPACE/sa/SERVICEACCOUNT

In diesem Beispiel enthalten die folgenden Felder Informationen zum Hauptkonto:

  • PROJECT_NUMBER: Die Projektnummer des Flotten-Hostprojekts
  • WORKLOAD_IDENTITY_POOL_NAME: Der Name des Workload Identity-Pools
  • NAMESPACE: Der Name des Namespace
  • SERVICEACCOUNT: Der Name des Kubernetes-Dienstkontos

Anfragen an Google Cloud APIs werden mit kurzlebigen OAuth 2.0-Zugriffstokens authentifiziert, die von Clustern generiert werden. Diese Zugriffstokens enthalten die Hauptkonto-ID der Entität, die die Anfrage erstellt hat. IAM verwendet die Hauptkonto-ID, um sicherzustellen, dass eine Zulassungsrichtlinie die Entität autorisiert, den angeforderten Vorgang auszuführen.

Auswirkungen der Identitätsgleichheit auf Flotten mit mehreren Mandanten

Die Hauptkonto-ID führt zu Identitätsgleichheit. Das bedeutet, dass jede Entität in der Umgebung, die einer bestimmten Hauptkonto-ID entspricht, als dasselbe von IAM betrachtet wird. Bei der Workload Identity Federation for GKE für ein einzelnes Projekt gilt die Identitätsgleichheit für alle Entitäten, die in diesem Projekt eine Hauptkonto-ID gemeinsam nutzen. Bei der Identitätsföderation von Arbeitslasten für Flotten gilt diese Identitätsgleichheit jedoch für alle Entitäten, die in der gesamten Flotte eine Hauptkonto-ID gemeinsam nutzen, unabhängig vom Clusterprojekt.

Mit der Hauptkonto-ID im vorherigen Abschnitt erhalten Anfragen von Pods, die dasselbe Dienstkonto, denselben Namespace und denselben Workload Identity-Pool verwenden, beispielsweise dieselbe Hauptkonto-ID, unabhängig vom Cluster oder Projekt.

Wenn in Ihrer Flotte nur Cluster im Flotten-Hostprojekt ausgeführt werden, sind die Auswirkungen der Identitätsgleichheit dieselben wie bei Workload Identity Federation for GKE. Wenn Ihre Flotte jedoch Cluster enthält, die in anderen Projekten ausgeführt werden, erstreckt sich die Identitätsgleichheit auf alle registrierten Cluster in der Flotte.

Beispiel für Komplexitäten bei der Identitätsgleichheit in Flotten

In den folgenden Beispielszenarien werden potenzielle Komplexitäten bei der Identitätsgleichheit beschrieben, die auftreten können, wenn Sie die Identitätsföderation von Arbeitslasten für Flotten implementieren. Für jedes Szenario werden mögliche Maßnahmen zur Risikominderung genannt, die Ihnen helfen können, diese Komplexitäten zu bewältigen.

Einzelne Projektflotte, bei der alle Cluster registriert sind und derselbe Workload Identity-Pool verwendet wird

Stellen Sie sich die folgende Flottenkonfiguration vor:

  • Alle Mitgliedscluster der Flotte befinden sich im Flotten-Hostprojekt.
  • Alle Cluster im Projekt sind Mitglieder der Flotte.
  • Alle Cluster verwenden denselben Workload Identity-Pool.

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, in dem sich alle Cluster in derselben Flotte befinden

Wie im Abschnitt Auswirkungen der Identitätsgleichheit auf Flotten beschrieben, ist die Verwendung der Identitätsföderation von Arbeitslasten für Flotten in diesem Szenario dasselbe wie die Verwendung von Workload Identity Federation für GKE und es besteht kein zusätzliches Risiko.

Einzelne Projektflotte, bei der einige Cluster registriert sind und derselbe Workload Identity-Pool verwendet wird

Stellen Sie sich die folgende Flottenkonfiguration vor:

  • Die Flotte enthält zwei Cluster, die beide im Flotten-Hostprojekt ausgeführt werden.
  • Das Flotten-Hostprojekt enthält einen dritten Cluster, der kein Flottenmitglied ist.
  • Für den Cluster, der kein Flottenmitglied ist, ist auch Workload Identity Federation for GKE aktiviert.
  • Alle Cluster im Projekt verwenden denselben Workload Identity-Pool.

Diagramm mit einem Projekt mit einigen Clustern in derselben Flotte.

Bei dieser Konfiguration gelten alle Rollen, die Sie einer Entität in einem Cluster im Projekt zuweisen, auch für andere Entitäten im Projekt, die der Hauptkonto-ID entsprechen. Das kann dazu führen, dass Entitäten, die nicht Teil der Flotte sind, versehentlich Berechtigungen erhalten. Wenn Sie beispielsweise einer Hauptkonto-ID eine Rolle zuweisen, die ein bestimmtes Dienstkonto in einem Namespace auswählt, hat das folgende Auswirkungen:

  • Arbeitslasten, die im angegebenen Namespace ausgeführt werden und das angegebene Dienstkonto in den Mitgliedsclustern der Flotte verwenden, teilen sich den Zugriff.
  • Arbeitslasten, die im dritten Cluster ausgeführt werden, der kein Mitglied ist, und denselben Namespace und Dienstkontonamen verwenden, erhalten ebenfalls denselben Zugriff.

Die folgenden Vorschläge können helfen, diese Komplexität zu lösen:

  • Konfigurieren Sie die Mitgliedscluster der Flotte so, dass sie einen selbstverwalteten Workload Identity-Pool verwenden. So haben Entitäten in den Mitgliedsclustern der Flotte andere Hauptkonto-IDs als der Cluster, der kein Mitglied ist. Weitere Informationen finden Sie unter Authentifizierung bei Google Cloud APIs über Arbeitslasten in Flotten mit unterschiedlichen Vertrauensbeziehungen.

  • Erstellen Sie ein dediziertes Flotten-Hostprojekt und verhindern Sie mit Organisationsrichtlinien, dass in diesem Projekt Cluster ausgeführt werden. Dadurch wird die Vertrauensdomain des flottenweiten Workload Identity-Pools von den Vertrauensdomains auf GKE-Projektebene getrennt. Nur registrierte Cluster verwenden den flottenweiten Workload Identity-Pool gemeinsam.

    Diese Vorschläge funktionieren für Cluster on Google Cloud und angehängte Cluster.

Flotte mit mehreren Projekten, bei der einige Cluster registriert sind und derselbe Workload Identity-Pool verwendet wird

Stellen Sie sich die folgende Flottenkonfiguration vor:

  • Die Flotte enthält Mitgliedscluster, die in zwei Google Cloud Projekten ausgeführt werden: project-1 und project-2.
  • project-1 ist das Flotten-Hostprojekt. Alle Cluster in project-1 sind Flottenmitglieder.
  • project-2 enthält einen Mitgliedscluster der Flotte und einen nicht registrierten Cluster.
  • Alle Cluster in project-1 verwenden den von Google verwalteten Workload Identity-Pool des Projekts, der auch der Standard-Workload Identity-Pool für die gesamte Flotte ist.
  • Der Mitgliedscluster der Flotte in project-2 verwendet den flottenweiten Workload Identity-Pool.

Diagramm einer Flotte mit Clustern aus zwei Projekten.

In diesem Szenario gelten alle Berechtigungen, die Sie Entitäten im Flotten-Hostprojekt gewähren, auch für Entitäten im Mitgliedscluster aus project-2, da sie alle denselben Workload Identity-Pool verwenden.

Um diese Komplexität zu lösen, erstellen Sie ein dediziertes Google Cloud Projekt , das als Flotten-Hostprojekt verwendet werden soll. Die Mitgliedscluster der Flotte in project-1 und in project-2 verwenden dann standardmäßig den Workload Identity-Pool des dedizierten Projekts gemeinsam. Anschließend können Sie Clustern in project-1 projektweiten Zugriff gewähren, indem Sie den Workload Identity-Pool für project-1 in der Hauptkonto-ID verwenden.

Erstellung ähnlicher Identitäten verhindern

Die Identitätsgleichheit in Flotten erfordert, dass Sie die Zugriffssteuerung sorgfältig implementieren, um die absichtliche oder unbeabsichtigte Erstellung ähnlicher Identitäten zu verhindern. Stellen Sie sich beispielsweise ein Szenario vor, in dem Sie allen Pods Zugriff gewähren, die ein bestimmtes Dienstkonto in einem Namespace verwenden. Wenn jemand diesen Namespace und dieses Dienstkonto in einem anderen Mitgliedscluster der Flotte erstellt, erhalten Pods in diesem Cluster denselben Zugriff.

Um die Wahrscheinlichkeit dieses Problems zu verringern, verwenden Sie einen Autorisierungsmechanismus, mit dem nur eine vertrauenswürdige Gruppe von Nutzern Namespaces und Kubernetes-Dienstkonten erstellen, aktualisieren oder löschen kann.

  • Für IAM bieten die folgenden Berechtigungen diesen Zugriff:

    • container.namespaces.*
    • container.serviceAccounts.*

  • Für die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) in Kubernetes konfigurieren die folgenden Beispiel-Clusterrollen einen speziellen Zugriff auf diese Kubernetes-Ressourcen:

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: namespace-admin
rules:
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["create","delete","update","patch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: serviceaccount-admin
rules:
- apiGroups: [""]
  resources: ["serviceaccounts"]
  verbs: ["create","delete","update","patch","impersonate"]

Nächste Schritte