Risiken der Identitätsgleichheit in mehrmandantenfähigen Flotten reduzieren

Auf dieser Seite finden Sie Best Practices für die Konfiguration und Verwendung der Workload Identity-Föderation der Flotte. Mit diesem Flottenfeature können Sie die Authentifizierung von Anwendungen bei Google Cloud APIs projektübergreifend zentral einrichten. Best Practices zur Einführung anderer Flottenfunktionen finden Sie unter Flottenfunktionen planen.

Diese Seite richtet sich an Plattformadministratoren und ‑bediener sowie an Sicherheitsexperten, 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 Flotten vertraut.

Terminologie

Auf dieser Seite werden die folgenden Begriffe verwendet:

  • Workload Identity Federation for GKE: Eine Funktion, die GKE-Arbeitslasten in einem einzelnen Google Cloud Projekt Identitäten bereitstellt.
  • Identitätsföderation von Arbeitslasten für Flotten: Eine Funktion, die die Identitätsföderation von Arbeitslasten für GKE auf Arbeitslasten in der gesamten Flotte ausweitet, auch außerhalb von Google Cloudund über mehrere Projekte hinweg.
  • Workload Identity-Pool: Eine Entität, die Arbeitslasten Identitäten in einem Format bereitstellt, 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 bereitstellen, das IAM bei der Authentifizierung und Autorisierung von Anfragen verwenden kann. Bei der Workload Identity-Föderation für 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 für die 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 wird.

Sowohl bei der Workload Identity-Föderation für Flotten als auch bei der Workload Identity-Föderation für GKE verwenden Sie IAM-Zulassungsrichtlinien, um Rollen für bestimmte Google Cloud-Ressourcen für Entitäten in Ihren Clustern wie Kubernetes-Dienstkonten oder ‑Pods zu gewähren. In Ihren Zulassungsrichtlinien verweisen Sie auf diese Entitäten mit einer Hauptkonto-ID, einer Namenssyntax, die von IAM gelesen werden kann. Die Prinzipal-ID enthält den Namen des Workload Identity-Pools, den der Cluster verwendet, sowie andere Informationen, mit denen die spezifischen Entitäten im Cluster ausgewählt werden. Mit der folgenden Hauptkonto-ID wird beispielsweise ein Kubernetes-ServiceAccount in einem Namespace ausgewählt:

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 Prinzipal:

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

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

Auswirkungen der Identitätsgleichheit auf mehrmandantenfähige Flotten

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

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 der Identitätsföderation von Arbeitslasten für GKE. Wenn Ihre Flotte jedoch Cluster enthält, die in anderen Projekten ausgeführt werden, gilt die Identität für alle registrierten Cluster in der Flotte.

Beispiele für Komplexitäten bei der Identitätsgleichheit von Flotten

In den folgenden Beispielszenarien werden potenzielle Komplexitäten bei der Identität beschrieben, die bei der Implementierung der Workload Identity-Föderation für Flotten auftreten können. Für jedes Szenario werden mögliche Maßnahmen zur Risikominderung vorgeschlagen, die Ihnen helfen können, diese Komplexitäten zu bewältigen.

Einzelne Projektflotte bei der alle Cluster registriert sind und denselben Workload Identity-Pool verwenden

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ät auf Flotten beschrieben, ist die Verwendung der Workload Identity Federation für Flotten in diesem Szenario dieselbe wie die Verwendung der Workload Identity Federation für GKE und es besteht kein zusätzliches Risiko.

Einzelne Projektflotte mit einigen registrierten Clustern und demselben Workload Identity-Pool

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 die Identitätsföderation von Arbeitslasten für GKE aktiviert.
  • Alle Cluster im Projekt verwenden denselben Workload Identity-Pool.

Diagramm mit einem Projekt mit einigen Clustern in derselben Flotte.

Mit 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 mit der Prinzipal-ID übereinstimmen. Das kann dazu führen, dass Berechtigungen versehentlich an Einheiten erteilt werden, die nicht Teil der Flotte sind. Wenn Sie beispielsweise einem Prinzipal-Identifier, der ein bestimmtes Dienstkonto in einem Namespace auswählt, eine Rolle zuweisen, hat das folgende Auswirkungen:

  • Arbeitslasten, die im angegebenen Namespace ausgeführt werden und das angegebene Dienstkonto in den Flottenmitgliedsclustern verwenden, haben Zugriff.
  • Arbeitslasten, die im dritten Nicht-Mitgliedscluster ausgeführt werden und denselben Namespace und Dienstkontonamen verwenden, erhalten ebenfalls denselben Zugriff.

Die folgenden Vorschläge können helfen, diese Komplexität zu bewältigen:

  • Konfigurieren Sie die Flottenmitgliedscluster für die Verwendung eines selbstverwalteten Workload Identity-Pools (Vorschau). So wird dafür gesorgt, dass Entitäten in den Mitgliedsclustern der Flotte unterschiedliche Prinzipal-IDs als der Nicht-Mitgliedscluster haben. Weitere Informationen finden Sie unter Bei Google Cloud -APIs über Flottenarbeitslasten mit unterschiedlichen Vertrauensstufen authentifizieren.

  • Erstellen Sie ein dediziertes Flotten-Hostprojekt und verwenden Sie Organisationsrichtlinien, um zu verhindern, dass in diesem Projekt Cluster ausgeführt werden. Dadurch wird die vertrauenswürdige Domain des flottenweiten Workload Identity-Pools von den vertrauenswürdigen Domains auf GKE-Projektebene getrennt. Nur registrierte Cluster verwenden den Workload Identity-Pool der Flotte.

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

Flotte mit mehreren Projekten mit einigen registrierten Clustern und demselben Workload Identity-Pool

Stellen Sie sich die folgende Flottenkonfiguration vor:

  • Die Flotte enthält Mitgliedscluster, die in zwei Projekten ausgeführt werden: project-1 und project-2. Google Cloud
  • project-1 ist das Flotten-Hostprojekt. Alle Cluster in project-1 sind Flottenmitglieder.
  • project-2 enthält einen Flottenmitgliedscluster und einen nicht registrierten Cluster.
  • Alle Cluster in project-1 verwenden den von Google verwalteten Workload Identity-Pool des Projekts, der auch der standardmäßige Workload Identity-Pool der Flotte ist.
  • Der Flottenmitgliedscluster 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 erteilen, auch für Entitäten im Mitgliedscluster aus project-2, da sie alle denselben Workload Identity-Pool verwenden.

Um diese Komplexität zu verringern, erstellen Sie ein dediziertes Google Cloud Projekt, das als Flotten-Hostprojekt verwendet werden soll. Die Flottenmitgliedscluster in project-1 und project-2 verwenden dann standardmäßig den Workload Identity-Pool des dedizierten Projekts. Anschließend können Sie mithilfe des Workload Identity-Pools für project-1 in der Hauptkonto-ID projektbezogenen Zugriff auf Cluster in project-1 gewähren.

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 Zugriff auf alle Pods gewähren, die ein bestimmtes Dienstkonto in einem Namespace verwenden. Wenn jemand diesen Namespace und das Servicekonto in einem anderen Flottenmitgliedscluster erstellt, erhalten Pods in diesem Cluster denselben Zugriff.

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

  • Für IAM sind die folgenden Berechtigungen erforderlich, um diesen Zugriff zu ermöglichen:

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

  • Für die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) von Kubernetes konfigurieren die folgenden Beispiel-ClusterRoles einen speziellen Zugriff für die Interaktion mit diesen 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