Autorisierung und Zugriffssteuerung

Mit Identity and Access Management (IAM) in Google Distributed Cloud (GDC) mit Air Gap können Sie steuern, wer Zugriff auf welche Ressourcen hat und welche Aktionen diese Personen für diese Ressourcen ausführen können.

Wenn Sie wissen, wie IAM in GDC funktioniert, können Sie den Zugriff effektiv verwalten und dafür sorgen, dass Mitglieder die Berechtigungen haben, die sie für ihre Aufgaben benötigen. Gleichzeitig bleibt die Sicherheit Ihrer Umgebung mit Air Gap gewahrt.

Dieses Dokument richtet sich an Zielgruppen in den Gruppen der Plattformadministratoren und Anwendungsoperatoren (z. B. IT-Administratoren, Sicherheitstechniker oder Anwendungsentwickler), die mehr über Autorisierung und Zugriffssteuerung in GDC mit Air Gap erfahren möchten. Dieses Dokument hilft auch Infrastrukturbetreibern, ein grundlegendes Verständnis der Konzepte der Zugriffssteuerung zu entwickeln. Weitere Informationen finden Sie unter Dokumentation zu Zielgruppen für GDC mit Air Gap.

Das Zugriffssteuerungsmodell

Der Zugriff in GDC ist um drei Kernkomponenten herum strukturiert: Mitglieder (wer), Rollen (was) und Ressourcenbereich (wo).

Das Zugriffssteuerungsmodell

Die Zugriffssteuerung besteht aus zwei verschiedenen Phasen: dem Nachweis Ihrer Identität (Authentifizierung) und der Bestimmung Ihrer Berechtigungen (Autorisierung):

  • Authentifizierung:In GDC werden keine Nutzerkonten oder Passwörter gespeichert. GDC stellt eine Verbindung zum Identitätsanbieter (IdP) Ihrer Organisation her, damit Sie sich mit Ihren Unternehmensanmeldedaten anmelden können.
  • Autorisierung:Nach der Authentifizierung prüft GDC IAM Ihre zugewiesenen Rollen, um zu ermitteln, auf welche Ressourcen Sie zugreifen und welche Aktionen Sie ausführen können.

Mitglieder

Ein Mitglied ist eine Identität, der Sie Zugriff auf Ressourcen gewähren können. GDC gruppiert Mitglieder in zwei Hauptkategorien, je nachdem, wo Sie sie verwalten: menschliche Identitäten und nicht menschliche Identitäten.

Menschliche Identitäten

Menschliche Identitäten sind die Nutzer und Gruppen, die sich in GDC anmelden. Anstatt Nutzerkonten oder Passwörter zu speichern, stellt GDC eine Verbindung zu den vorhandenen Anmeldesystemen oder IdPs Ihrer Organisation (z. B. Active Directory, LDAP oder Okta) her. Dabei werden Standardprotokolle für die Identitätsföderation wie OpenID Connect (OIDC) oder SAML 2.0 verwendet.

Es gibt zwei Arten von menschlichen Identitäten:

  • Nutzer:Einzelne menschliche Nutzer, die sich mit ihren Unternehmensanmeldedaten im System anmelden.
  • Gruppen:Sammlungen von menschlichen Nutzern, die im IdP Ihrer Organisation verwaltet werden. Wenn Sie einer Gruppe eine Rolle zuweisen, wird sie automatisch allen Mitgliedern dieser Gruppe zugewiesen.

GDC verwendet IdPs, um menschliche Identitäten eindeutig zu identifizieren. Da Ihre Umgebung eine Verbindung zu mehreren IdPs herstellen kann (z. B. wenn verschiedene Abteilungen unterschiedliche Anmeldesysteme verwenden), unterscheidet GDC zwischen den IdPs, um sicherzustellen, dass Sie der richtigen Person Zugriff gewähren.

Beim Verwalten des Zugriffs stellt GDC automatisch ein eindeutiges IdP-Präfix vor alle externen Nutzernamen und Gruppen:

  • Format:idpprefix-username@domain.com oder idpprefix-group-name für Gruppen.
  • Beispiel: Wenn der IdP Ihrer Organisation mit dem Präfix agency-a konfiguriert ist und Sie sich als alice@example.com anmelden, erkennt GDC IAM Sie als agency-a-alice@example.com.

Nicht menschliche Identitäten

Nicht menschliche Identitäten werden als Dienstidentitäten (oder Dienstkonten) bezeichnet. Sie erstellen und verwalten sie direkt in GDC (als ProjectServiceAccount-Ressourcen), damit Anwendungen, Skripts oder automatisierte Arbeitslasten sicher mit APIs interagieren können.

Da Dienstkonten intern von GDC verwaltet werden, verwenden sie keine IdP-Präfixe. Stattdessen werden sie anhand ihres Projekts und Namens identifiziert (z. B. serviceAccount:projectName:serviceAccountName bei Verwendung der gdcloud CLI).

Weitere Informationen finden Sie unter Dienstkontoschlüssel sichern.

Berechtigungen und Rollen

Eine Berechtigung ist die Befugnis, eine bestimmte Aktion für eine Ressource auszuführen (z. B. eine VM erstellen oder eine Datenbank löschen). Sie gewähren Mitgliedern nicht direkt Berechtigungen. Stattdessen bündelt GDC Berechtigungen in Rollen.

GDC bietet zwei Arten von Rollen:

  • Vordefinierte Rollen:Integrierte Berechtigungsbündel, die von GDC erstellt und verwaltet werden. GDC bietet eine umfassende Bibliothek vordefinierter Rollen, die auf bestimmte Aufgaben und Dienste zugeschnitten sind (von allgemeinen Rollen wie „Projektbetrachter“ bis hin zu detaillierten Dienstrollen wie „Bucket-Projektadministrator“ oder „KMS-Betrachter“).
  • Benutzerdefinierte Rollen:Benutzerdefinierte Berechtigungsbündel, die Sie erstellen können, wenn die vorhandenen vordefinierten Rollen die Anforderungen Ihrer Organisation nicht erfüllen.

Berechtigungen, die über IAM-Rollen gewährt werden, sind rein additiv. Sie gewähren Zugriff, enthalten aber keine Ablehnungsregeln. Wenn Sie einem Mitglied mehrere Rollen zuweisen, erhält das Mitglied die Vereinigung aller Berechtigungen in diesen Rollen. Wenn Sie den Zugriff auf bestimmte Dienste in Ihrer Organisation einschränken oder verweigern möchten, können Sie Organisationsrichtlinien einrichten.

Ressourcenbereich

Sie gewähren den Zugriff immer auf einer bestimmten Ebene der GDC-Ressourcenhierarchie. Der Bereich bestimmt, auf welche Ressourcen das Mitglied zugreifen kann. In Umgebungen mit mehreren Zonen gelten Rollen, die auf einer der beiden Ebenen zugewiesen werden, standardmäßig für alle Zonen.

Sie können Rollen in den folgenden Ressourcenbereichen zuweisen:

  • Organisation:Der Container der obersten Ebene für Ihre Umgebung. Rollen, die auf Organisationsebene zugewiesen werden, gelten für die gesamte Organisation und werden automatisch an alle Projekte und Ressourcen darin weitergegeben.
  • Projekt:Ein Container innerhalb der Organisation, mit dem Ressourcen für bestimmte Teams oder Anwendungen gruppiert werden. Projekte dienen als strenge Sicherheitsgrenzen. Rollen, die auf Projektebene zugewiesen werden, gelten nur für dieses bestimmte Projekt und seine Ressourcen (z. B. virtuelle Maschinen, Datenbanken und Kubernetes-Cluster).

Weitere Informationen finden Sie unter Ressourcenhierarchie und Berechtigungssteuerung für ein Universum mit mehreren Zonen.

So wird der Zugriff autorisiert

GDC verwaltet und autorisiert den Zugriff hauptsächlich mithilfe eines rollenbasierten Zugriffssteuerungsmodells (Role-Based Access Control, RBAC). In einem RBAC-Modell weisen Sie einzelnen Nutzern oder Arbeitslasten keine Berechtigungen direkt zu. Stattdessen weisen Sie Mitgliedern Rollen in einem bestimmten Ressourcenbereich zu, um den Zugriff zu bestimmen.

GDC implementiert RBAC mit den folgenden benutzerdefinierten Kubernetes-Ressourcen:

  • IAMRole: Definiert ein bestimmtes Berechtigungsbündel.
  • IAMRoleBinding: Verknüpft ein Mitglied (einen menschlichen Nutzer, eine Gruppe oder ein Dienstkonto) mit einem IAMRole auf Organisations- oder Projektebene.

Wenn Sie Zugriff auf Ressourcen der Organisation oder des Projekts gewähren möchten, können Sie eine IAMRoleBinding über die GDC Console, die gdcloud CLI oder durch Anwenden benutzerdefinierter Ressourcenmanifeste (YAML-Dateien) mit der kubectl CLI erstellen.

Wenn Sie beispielsweise einem Teammitglied erlauben möchten, virtuelle Maschinen in einem Projekt anzusehen, können Sie eine IAMRoleBinding im Bereich dieses Projekts erstellen, die die Identität des Mitglieds mit einer Betrachterrolle verknüpft. Wenn das Mitglied versucht, eine virtuelle Maschine anzusehen, prüft GDC die aktiven Rollenbindungen, bestätigt, dass die zugewiesene Rolle die erforderliche Berechtigung enthält, und autorisiert die Anfrage.

Während die GDC Console und die gdcloud CLI automatisch eine Verbindung zu Ihren Ressourcen herstellen, erfordert der direkte API-Zugriff mit der kubectl CLI die Authentifizierung beim jeweiligen Kubernetes-Cluster oder API-Server, der diese Ressource hostet. Dazu müssen Sie eine kubeconfig-Datei generieren. Weitere Informationen finden Sie unter Anmelden und kubeconfig-Datei generieren.

Weitere Informationen zum Verwalten von Rollenbindungen finden Sie unter Zugriff gewähren und widerrufen.

Unterschiede zwischen GDC mit Air Gap und Google Cloud

Wenn Sie bereits Erfahrung mit der Zugriffsverwaltung in Google Cloud, werden Sie feststellen, dass GDC ähnliche Konzepte verwendet, sie aber anders implementiert, um in einer Kubernetes-basierten Infrastruktur mit Air Gap zu funktionieren.

In der folgenden Tabelle finden Sie einen Vergleich zwischen IAM in GDC und Google Cloud:

Funktion Beschreibung GDC mit Air Gap Google Cloud
Nutzeridentität (Authentifizierung) Identitätssystem, das zur Authentifizierung menschlicher Nutzer verwendet wird. Mit Ihrem externen IdP über die erforderlichen IdP-Präfixe verknüpft (z. B. idpprefix-user@domain.com). Google-Konten (z. B. Gmail) oder Unternehmensidentitäten, die über Cloud Identity oder Google Workspace verknüpft sind.
Autorisierungs-Engine Das zugrunde liegende System, das Berechtigungen auswertet und erzwingt. Hauptsächlich die rollenbasierte Zugriffssteuerung (RBAC) von Kubernetes, bei der Zugriffs anfragen lokal vom API-Server anhand von Rollen bindungen ausgewertet werden. Sie können Organisationsrichtlinien verwenden, um Ressourceneinschränkungen festzulegen. Der globale Cloud IAM-Dienst von Google. Wertet API-Anfragen zentral anhand von Zugriffsrichtlinien aus, die auf jeder Ebene der Ressourcen hierarchie angehängt sind.
Rollenbindungen So werden Mitglieder Rollen für bestimmte Ressourcen zugeordnet. Benutzerdefinierte IAMRoleBinding-Ressourcen. Jede Bindung ist ein Objekt, das Mitglieder mit einer Rolle verknüpft. IAM-Rollenberechtigungen sind rein additiv (Ablehnungsregeln können separat über Organisationsrichtlinien konfiguriert werden). Eine einzelne IAM-Zugriffsrichtlinie, die an jede Ressource, Ordner oder Organisation angehängt ist. Enthält mehrere Bindungen, die Mitglieder Rollen zuordnen, und unterstützt bedingte Regeln oder Ablehnungsregeln.
Dienstkonten Nicht menschliche Identitäten, die von Anwendungen und automatisierten Arbeitslasten verwendet werden. Lokale Dienstkonten, die in einem bestimmten Projekt erstellt wurden (ProjectServiceAccount). Öffentliche Schlüssel werden im Cluster gespeichert, während private Schlüssel lokal vom Client verwaltet und gesichert werden. Globale Identitäten, die zentral von Google verwaltet werden. Anmeldedaten können automatisch von Google verwaltet oder als Schlüsseldateien heruntergeladen werden, um sich von überall aus zu authentifizieren.
Ressourcenhierarchie Containerstruktur, mit der Ressourcen organisiert und Berechtigungen weitergegeben werden. Zweistufige Hierarchie: Organisation > Projekte Mehrstufige Hierarchie: Organisation > Ordner > Projekte
Berechtigungsbereich für mehrere Zonen So werden Berechtigungen in Verfügbarkeitszonen oder Regionen ausgewertet und weitergegeben. Verwendet Kubernetes RBAC, das von einem globalen API-Server verwaltet wird. Dieser koordiniert und repliziert Rollenbindungen über zonale API-Server hinweg, sodass der Zugriff standardmäßig für alle Zonen gilt. Verwendet einen vollständig verwalteten globalen IAM-Dienst. Berechtigungen die auf einer beliebigen Ressourcenebene zugewiesen werden, sind von Natur aus global und gelten automatisch für alle Regionen und Zonen.
Client-Tools Primäre Schnittstellen, CLI-Tools und APIs, die zum Verwalten des Zugriffs verwendet werden. GDC Console, gdcloud CLI und KRM APIs. Google Cloud Console, gcloud CLI und REST- oder gRPC-APIs.
Direkter API-Zugriff So authentifizieren sich Tools und Skripts, um Ressourcen direkt mit APIs zu verwalten. Für den direkten API-Zugriff mit der kubectl CLI ist die Authentifizierung beim jeweiligen Kubernetes-Cluster oder API-Server erforderlich, der diese Ressource hostet. Dazu müssen Sie eine kubeconfig-Datei generieren. Die GDC Console und gdcloud CLI stellen automatisch eine Verbindung zu Ressourcen her. Für den direkten API-Zugriff mit gcloud oder REST/gRPC Endpunkten werden zentralisierte Anmeldedaten (gcloud auth login) verwendet, die global für alle Dienste gelten, ohne dass clusterspezifische Anmeldungen erforderlich sind.

Nächste Schritte