Autorisierung und Zugriffssteuerung

Mit Identity and Access Management (IAM) in der Google Distributed Cloud (GDC) Air-Gapped Appliance 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 Air-Gapped-Umgebung gewahrt.

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 kann den mitgelieferten Keycloak-Identitätsanbieter (IdP) nutzen oder eine Verbindung zum IdP Ihrer Organisation herstellen, damit Sie sich mit Ihren Anmeldedaten 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, kann GDC den mitgelieferten Keycloak-IdP nutzen oder eine Verbindung zu den vorhandenen Anmeldesystemen Ihrer Organisation herstellen (z. B. Active Directory, LDAP oder Okta). 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 Anmeldedaten im System anmelden.
  • Gruppen:Sammlungen von menschlichen Nutzern, die in Keycloak oder 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.

Ressourcenbereich

Sie gewähren den Zugriff immer auf einer bestimmten Ebene der GDC-Ressourcenhierarchie. Der Bereich bestimmt, auf welche Ressourcen das Mitglied zugreifen kann.

Sie können Rollen in den folgenden Ressourcenbereichen zuweisen:

  • Organisation:Der Container der obersten Ebene 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 darin weitergegeben.
  • Projekt:Ein Container innerhalb der Organisation, der zum Gruppieren von Ressourcen für bestimmte Teams oder Anwendungen verwendet wird. Projekte dienen als strenge Sicherheitsgrenzen. Rollen, die auf Projektebene gewährt werden, gelten nur für dieses bestimmte Projekt und seine Ressourcen (z. B. virtuelle Maschinen, Datenbanken und Kubernetes-Cluster).

So wird der Zugriff autorisiert

GDC verwaltet und autorisiert den Zugriff hauptsächlich mit einem rollenbasierten Zugriffssteuerungsmodell (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.

Um Zugriff auf Ressourcen der Organisation oder des Projekts zu gewähren, können Sie eine 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 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 IAM 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 Air-Gapped-Infrastruktur auf Kubernetes-Basis 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 verbunden oder mit dem mitgelieferten Keycloak IdP verwaltet. Dabei werden die erforderlichen IdP-Präfixe verwendet (z. B. idpprefix-user@domain.com). Google-Konten (z. B. Gmail) oder Unternehmensidentitäten, die über Cloud Identity oder Google Workspace verbunden 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. Der globale Cloud IAM-Dienst von Google. API-Anfragen werden zentral anhand von Zugriffsrichtlinien ausgewertet, die auf jeder Ebene der Ressourcenhierarchie angehängt sind.
Rollenbindungen So werden Mitglieder bestimmten 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. 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, die zum Organisieren von Ressourcen und zum Vererben von Berechtigungen verwendet wird. Zweistufige Hierarchie: Organisation > Projekte Mehrstufige Hierarchie: Organisation > Ordner > Projekte
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 über 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