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 für diese Ressourcen ausgeführt werden können.

Wenn Sie verstehen, wie IAM in GDC funktioniert, können Sie den Zugriff effektiv verwalten. So haben Mitglieder die Berechtigungen, die sie für ihre Rollen benötigen, während die Sicherheit Ihrer Air-Gap-Umgebung gewahrt bleibt.

Dieses Dokument richtet sich an Plattformadministratoren und Anwendungsgruppen (z. B. IT-Administratoren, Sicherheitstechniker oder Anwendungsentwickler), die sich mit der Autorisierung und Zugriffssteuerung in GDC mit Air Gap vertraut machen möchten. Dieses Dokument hilft Infrastrukturbetreibern auch, 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

GDC strukturiert den Zugriff anhand von drei Kernkomponenten: 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 der GDC werden keine Nutzerkonten oder Passwörter gespeichert. GDC stellt eine Verbindung zum Identitätsanbieter (Identity Provider, 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 festzustellen, auf welche Ressourcen Sie zugreifen und welche Aktionen Sie ausführen können.

Mitglieder

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

Menschliche Identitäten

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

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.

Bei der Zugriffsverwaltung stellt GDC allen externen Nutzernamen und Gruppen automatisch ein eindeutiges IdP-Präfix voran:

  • 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, werden Sie von GDC IAM als agency-a-alice@example.com erkannt.

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 durch ihr Projekt und ihren Namen 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 zu erstellen oder eine Datenbank zu löschen. Sie erteilen Mitgliedern nicht direkt Berechtigungen. Stattdessen bündelt GDC Berechtigungen in Rollen.

GDC bietet zwei Arten von Rollen:

  • Vordefinierte Rollen: Integrierte Berechtigungspakete, 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 „Project Viewer“ bis hin zu detaillierten Dienstrollen wie „Bucket Project Admin“ oder „KMS Viewer“).
  • Benutzerdefinierte Rollen: Benutzerdefinierte Berechtigungspakete, die Sie erstellen können, wenn vorhandene vordefinierte Rollen die Anforderungen Ihrer Organisation nicht erfüllen.

Über IAM-Rollen gewährte Berechtigungen sind rein additiv. Sie gewähren Zugriff, enthalten aber keine Ablehnungsregeln. Wenn Sie einem Mitglied mehrere Rollen zuweisen, erhält es die Summe aller Berechtigungen dieser 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 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 sind, standardmäßig automatisch für alle Zonen.

Sie können Rollen für die folgenden Ressourcenbereiche zuweisen:

  • Organisation: Der übergeordnete Container für Ihre Umgebung. Rollen, die auf Organisationsebene gewährt werden, gelten für die gesamte Organisation und werden automatisch an alle Projekte und Ressourcen innerhalb der Organisation vererbt.
  • Projekt: Ein Container innerhalb der Organisation, der zum Gruppieren von Ressourcen für bestimmte Teams oder Anwendungen verwendet wird. Projekte dienen als strikte Sicherheitsgrenzen. Rollen, die auf Projektebene gewährt werden, gelten nur für das jeweilige Projekt und seine Ressourcen (z. B. virtuelle Maschinen, Datenbanken und Kubernetes-Cluster).

Weitere Informationen finden Sie unter Ressourcenhierarchie und Berechtigungssteuerung für ein Multi-Zonen-Universum.

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 Berechtigungen nicht direkt einzelnen Nutzern oder Arbeitslasten zu. Stattdessen weisen Sie Mitgliedern Rollen in einem bestimmten Ressourcenbereich zu, um den Zugriff zu bestimmen.

GDC implementiert die RBAC mithilfe der folgenden benutzerdefinierten Kubernetes-Ressourcen:

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

Wenn Sie Zugriff auf Organisations- oder Projektressourcen gewähren möchten, können Sie einen IAMRoleBinding mit der GDC Console, der 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 im Bereich dieses Projekts eine IAMRoleBinding erstellen, die die Identität des Mitglieds mit einer Betrachterrolle verknüpft. Wenn das Mitglied versucht, eine virtuelle Maschine aufzurufen, 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-Konsole und die gdcloud CLI automatisch eine Verbindung zu Ihren Ressourcen herstellen, erfordert der direkte API-Zugriff über die kubectl CLI die Authentifizierung beim jeweiligen Kubernetes-Cluster oder API-Server, der diese Ressource hostet. Dazu muss eine kubeconfig-Datei generiert werden. Weitere Informationen finden Sie unter Anmelden und kubeconfig-Datei generieren.

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

Unterschiede zwischen IAM für GDC mit Air Gap und Google Cloud

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

In der folgenden Tabelle werden IAM in GDC und Google Cloudverglichen:

Funktion Beschreibung GDC mit Air Gap Google Cloud
Nutzeridentität (Authentifizierung) Identitätssystem, das zur Authentifizierung von menschlichen Nutzern verwendet wird. Mit Ihrem externen IdP über die erforderlichen IdP-Präfixe (z. B. idpprefix-user@domain.com) verbunden. Google-Konten (z. B. Gmail) oder Unternehmensidentitäten, die über Cloud Identity oder Google Workspace föderiert sind.
Autorisierungs-Engine Das zugrunde liegende System, das Berechtigungen auswertet und erzwingt. In erster Linie die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) von Kubernetes, bei der Zugriffsanfragen lokal vom API-Server anhand von Rollenbindungen ausgewertet werden. Mit Organisationsrichtlinien können Sie Ressourceneinschränkungen festlegen. Der globale Cloud IAM-Dienst von Google. API-Anfragen werden zentral anhand von Zugriffsrichtlinien ausgewertet, die auf einer beliebigen Ebene der Ressourcenhierarchie angehängt sind.
Rollenbindungen Wie Mitglieder Rollen für bestimmte Ressourcen zugewiesen werden. Einzelne 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, jeden Ordner oder jede 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 (ProjectServiceAccount) erstellt wurden. Ö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, die zum Organisieren von Ressourcen und Übernehmen von Berechtigungen verwendet wird. Zweistufige Hierarchie: Organisation > Projekte Mehrstufige Hierarchie: Organisation > Ordner > Projekte
Berechtigungsumfang für mehrere Zonen Wie Berechtigungen in Verfügbarkeitszonen oder Regionen ausgewertet und weitergegeben werden. Verwendet die Kubernetes-RBAC, die von einem globalen API-Server verwaltet wird, der Rollenbindungen über zonale API-Server hinweg koordiniert und repliziert, 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 sind, sind grundsätzlich global und gelten automatisch für alle Regionen und Zonen.
Client-Tools Primäre Schnittstellen, Befehlszeilentools und APIs, die zum Verwalten des Zugriffs verwendet werden. GDC-Konsole, gdcloud CLI und KRM APIs. Google Cloud Console, gcloud CLI und REST- oder gRPC-APIs.
Direkter API-Zugriff Wie sich Tools und Skripts authentifizieren, um Ressourcen direkt über APIs zu verwalten. Für den direkten API-Zugriff über die kubectl-Befehlszeile ist eine Authentifizierung beim jeweiligen Kubernetes-Cluster oder API-Server erforderlich, der diese Ressource hostet. Dazu muss eine kubeconfig-Datei generiert werden. (Die GDC-Konsole und die gdcloud CLI stellen automatisch eine Verbindung zu Ressourcen her.) Beim direkten API-Zugriff über gcloud oder REST-/gRPC-Endpunkte werden zentrale Anmeldedaten (gcloud auth login) verwendet, die global für alle Dienste gelten, ohne dass clusterspezifische Anmeldungen erforderlich sind.

Nächste Schritte