IAM-Übersicht

Auf dieser Seite wird beschrieben, wie Google Cloud's Identity and Access Management (IAM) System funktioniert und wie Sie es zum Verwalten des Zugriffs in Google Cloudverwenden können.

IAM ist ein Tool zum Verwalten der detaillierten Autorisierung für Google Cloud. Mit anderen Worten: Sie können steuern, wer was für welche Ressourcen tun kann.

Zugriff in Google Cloud

Für jede Aktion in Google Cloud sind bestimmte Berechtigungen erforderlich. Wenn jemand versucht, eine Aktion in Google Cloudauszuführen, z. B. eine VM Instanz zu erstellen oder ein Dataset anzusehen, prüft IAM zuerst, ob die erforderlichen Berechtigungen vorhanden sind. Wenn nicht, verhindert IAM, dass die Aktion ausgeführt wird.

Wenn Sie jemandem Berechtigungen in IAM erteilen, sind die folgenden drei Komponenten beteiligt:

  • Hauptkonto: Die Identität der Person oder des Systems, der bzw. dem Sie Berechtigungen erteilen möchten.
  • Rolle: Die Sammlung von Berechtigungen, die Sie dem Hauptkonto erteilen möchten.
  • Ressource: Die Google Cloud Ressource, auf die Sie dem Hauptkonto Zugriff gewähren möchten.

Wenn Sie dem Hauptkonto die Berechtigung zum Zugriff auf die Ressource erteilen möchten, weisen Sie ihm eine Rolle für die Ressource zu. Sie weisen diese Rollen mithilfe einer Zulassungsrichtlinie zu.

Zulassungsrichtlinien sind direkt an einige Google Cloud Ressourcen angehängt, die hierarchischorganisiert sind. Projekte enthalten beispielsweise dienstspezifische Ressourcen. Das bedeutet, dass Sie Zugriff auf eine einzelne Ressource oder einen Container von Ressourcen gewähren können.

In den folgenden Abschnitten werden diese Konzepte genauer beschrieben.

Hauptkonten

In Google Cloud steuern Sie den Zugriff für Hauptkonten. Hauptkonten stellen eine oder mehrere Identitäten dar, die sich bei authentifiziert haben Google Cloud.

In der Vergangenheit wurden Hauptkonten als Mitglieder bezeichnet. In einigen APIs wird dieser Begriff weiterhin verwendet.

Es gibt verschiedene Arten von Hauptkonten in IAM, die sich in zwei große Kategorien unterteilen lassen:

  • Menschliche Nutzer: Einige IAM-Hauptkontotypen stellen menschliche Nutzer dar. Sie verwenden diese Hauptkontotypen, um den Zugriff Ihrer Mitarbeiter auf Google Cloud Ressourcen zu verwalten.

    Föderierte Identitäten in Workforce Identity-Pools stellen beispielsweise menschliche Nutzer dar.

  • Arbeitslasten: Einige IAM-Hauptkontotypen stellen Arbeitslasten dar. Sie verwenden diese Hauptkontotypen, wenn Sie den Zugriff Ihrer Arbeitslasten auf Google Cloud Ressourcen verwalten.

    Zu den Hauptkontotypen, die Arbeitslasten darstellen, gehören Dienstkonten und föderierte Identitäten in einem Workload Identity-Pool.

Weitere Informationen zu Hauptkonten finden Sie unter IAM Hauptkonten.

Berechtigungen und Rollen

Berechtigungen bestimmen, welche Vorgänge bei einer Ressource zugelassen sind. In IAM werden Berechtigungen in der Regel im Format service.resource.verb dargestellt. Oft entsprechen Berechtigungen eins zu eins den REST API-Methoden. Mit der Berechtigung resourcemanager.projects.list können Sie beispielsweise Resource Manager-Projekte auflisten.

Sie können einem Hauptkonto keine Berechtigungen direkt erteilen. Stattdessen erteilen Sie Hauptkonten Berechtigungen, indem Sie ihnen Rollen zuweisen.

Rollen sind Sammlungen von Berechtigungen. Wenn Sie einem Hauptkonto eine Rolle zuweisen, erhält es alle Berechtigungen in dieser Rolle.

Es gibt drei Arten von Rollen:

  • Vordefinierte Rollen: Rollen, die von Google Cloud Diensten verwaltet werden. Diese Rollen enthalten die Berechtigungen, die zum Ausführen allgemeiner Aufgaben für jeden Dienst erforderlich sind. Beispielsweise ermöglicht die Rolle „Pub/Sub-Publisher“ (roles/pubsub.publisher) den Zugriff zum Veröffentlichen von Nachrichten in einem Pub/Sub-Thema.

  • Benutzerdefinierte Rollen: Rollen, die Sie erstellen und die nur die von Ihnen angegebenen Berechtigungen enthalten. Sie haben die vollständige Kontrolle über die Berechtigungen in diesen Rollen. Sie erfordern jedoch einen höheren Wartungsaufwand als vordefinierte Rollen und die Anzahl der benutzerdefinierten Rollen, die Sie in Ihrem Projekt und in Ihrer Organisation haben können, ist begrenzt.

  • Einfache Rollen: Sehr permissive Rollen, die einen umfassenden Zugriff auf Google Cloud Dienste ermöglichen. Diese Rollen können für Testzwecke nützlich sein, sollten aber nicht in Produktionsumgebungen verwendet werden.

Weitere Informationen zu Rollen und Berechtigungen finden Sie unter Rollen und Berechtigungen.

Ressourcen

Die meisten Google Cloud Dienste haben eigene Ressourcen. Compute Engine hat beispielsweise Ressourcen wie Instanzen, Laufwerke und Subnetze.

In IAM weisen Sie Rollen für eine Ressource zu. Wenn Sie einem Hauptkonto eine Rolle für eine Ressource zuweisen, kann das Hauptkonto die Berechtigungen in dieser Rolle verwenden, um auf die Ressource zuzugreifen.

Sie können Rollen für eine Teilmenge von Google Cloud Ressourcen zuweisen. Eine vollständige Liste der Ressourcen, für die Sie Rollen zuweisen können, finden Sie unter Ressourcentypen, die Zulassungs richtlinien akzeptieren.

Google Cloud hat auch Containerressourcen, darunter Projekte, Ordner und Organisationen. Diese Containerressourcen sind hierarchisch organisiert, sodass untergeordnete Ressourcen die Richtlinien ihrer übergeordneten Ressourcen übernehmen können. Wenn Sie einem Hauptkonto eine Rolle für eine Containerressource zuweisen, erhält das Hauptkonto Zugriff auf die Containerressource und die Ressourcen in diesem Container. Mit dieser Funktion können Sie mit einer einzigen Rollenzuweisung den Zugriff auf mehrere Ressourcen verwalten, einschließlich Ressourcen, für die Sie Rollen nicht direkt zuweisen können. Weitere Informationen finden Sie auf dieser Seite unter Übernahme von Richtlinien.

Zulassungsrichtlinien

Sie weisen Hauptkonten Rollen mithilfe von Zulassungsrichtlinien zu. In der Vergangenheit wurden diese Richtlinien als IAM-Richtlinien bezeichnet.

Eine Zulassungsrichtlinie ist ein YAML- oder JSON-Objekt, das an eine Google Cloud Ressource angehängt ist.

Jede Zulassungsrichtlinie enthält eine Liste von Rollenbindungen , die IAM-Rollen mit den Hauptkonten verknüpfen, denen diese Rollen zugewiesen wurden.

Wenn ein authentifiziertes Hauptkonto versucht, auf eine Ressource zuzugreifen, prüft IAM anhand der Zulassungsrichtlinie der Ressource, ob das Hauptkonto die erforderlichen Berechtigungen hat. Wenn sich das Hauptkonto in einer Rollenbindung befindet, die eine Rolle mit den erforderlichen Berechtigungen enthält, darf es auf die Ressource zugreifen.

Beispiele für Zulassungsrichtlinien und Informationen zu ihrer Struktur finden Sie unter Zulassungsrichtlinien.

Übernahme von Richtlinien

Google Cloud hat Containerressourcen wie Projekte, Ordner und Organisationen, mit denen Sie Ihre Ressourcen in einer Über-/Untergeordnet-Hierarchie organisieren können. Diese Hierarchie wird als Ressourcenhierarchie bezeichnet.

Die Google Cloud Ressourcenhierarchie hat die folgende Struktur:

  • Die Organisation ist der Stammknoten in der Hierarchie.
  • Ordner sind untergeordnete Elemente der Organisation oder eines anderen Ordners.
  • Projekte sind untergeordnete Elemente der Organisation oder eines Ordners.
  • Die Ressourcen für jeden Dienst sind Projekten untergeordnet.

Das folgende Diagramm zeigt ein Beispiel für eine Google Cloud Ressourcenhierarchie:

Hierarchie für IAM-Ressourcen.

Wenn Sie eine Zulassungsrichtlinie für eine Containerressource festlegen, gilt die Zulassungsrichtlinie auch für alle Ressourcen in diesem Container. Dieses Konzept wird als Richtlinien übernahme bezeichnet, da untergeordnete Ressourcen effektiv die Zulassungsrichtlinien ihrer übergeordneten Ressourcen übernehmen.

Die Richtlinienübernahme hat folgende Auswirkungen:

  • Sie können mit einer einzigen Rollenbindung Zugriff auf mehrere Ressourcen gewähren. Wenn Sie einem Hauptkonto Zugriff auf alle Ressourcen in einem Container gewähren möchten, weisen Sie ihm eine Rolle für den Container und nicht für die Ressourcen im Container zu.

    Wenn Sie beispielsweise Ihrem Sicherheitsadministrator die Verwaltung von Zulassungsrichtlinien für alle Ressourcen in Ihrer Organisation ermöglichen möchten, können Sie ihm die Rolle „Sicherheitsadministrator“ (roles/iam.securityAdmin) für die Organisation zuweisen.

  • Sie können Zugriff auf Ressourcen gewähren, die keine eigenen Zulassungs richtlinien haben. Nicht alle Ressourcen akzeptieren Zulassungsrichtlinien, aber alle Ressourcen übernehmen Zulassungsrichtlinien von ihren übergeordneten Ressourcen. Wenn Sie einem Hauptkonto Zugriff auf eine Ressource gewähren möchten, die keine eigene Zulassungsrichtlinie haben kann, weisen Sie ihm eine Rolle für eine der übergeordneten Ressourcen der Ressource zu.

    Angenommen, Sie möchten jemandem die Berechtigung erteilen, Logs in einen Log-Bucket zu schreiben. Log-Buckets haben keine eigenen Zulassungsrichtlinien. Wenn Sie jemandem diese Berechtigung erteilen möchten, können Sie ihm stattdessen die Rolle „Logs Bucket Writer“ (roles/logging.bucketWriter) für das Projekt zuweisen, das den Log-Bucket enthält.

  • Wenn Sie wissen möchten, wer auf eine Ressource zugreifen kann, müssen Sie auch alle Zulassungsrichtlinien ansehen, die sich auf die Ressource auswirken. Wenn Sie eine vollständige Liste der Hauptkonten erhalten möchten, die Zugriff auf die Ressource haben, müssen Sie die Zulassungsrichtlinie der Ressource und die Zulassungsrichtlinien der übergeordneten Ressourcen der Ressource ansehen. Die Gesamtheit aller dieser Richtlinien wird als geltende Zulassungsrichtlinie bezeichnet.

Weitere Informationen zur Richtlinienübernahme für Zulassungsrichtlinien finden Sie unter Ressourcenhierarchie für die Zugriffssteuerung verwenden.

Erweiterte Zugriffssteuerung

Neben Zulassungsrichtlinien bietet IAM die folgenden Mechanismen zur Zugriffssteuerung, mit denen Sie genauer festlegen können, wer Zugriff auf welche Ressourcen hat:

  • Ablehnungsrichtlinien: Ablehnungsrichtlinien verhindern, dass Hauptkonten bestimmte Berechtigungen verwenden, auch wenn ihnen eine Rolle mit der Berechtigung zugewiesen wurde. Weitere Informationen zu Ablehnungsrichtlinien finden Sie unter Ablehnungsrichtlinien.

  • IAM-Bedingungen: Mit IAM-Bedingungen können Sie eine bedingte, attributbasierte Zugriffssteuerung definieren und erzwingen. Sie können Bedingungen in verschiedenen Richtlinientypen verwenden. Sie können beispielsweise einer Rollenbindung in einer Zulassungsrichtlinie eine Bedingung hinzufügen, um sicherzustellen, dass die Rolle nur zugewiesen wird, wenn die Bedingung erfüllt ist.

    Sie können Bedingungen basierend auf Attributen wie der Ressource in der Anfrage und der Uhrzeit der Anfrage schreiben.

    Weitere Informationen zu IAM-Bedingungen finden Sie unter Übersicht über IAM-Bedingungen.

Konsistenzmodell für die IAM API

Die IAM API unterliegt der Eventual Consistency. Wenn Sie also Daten mit der IAM API schreiben und diese dann sofort lesen, gibt der Lesevorgang möglicherweise eine ältere Version der Daten zurück. Es kann auch einige Zeit dauern, bis sich die vorgenommenen Änderungen auf die Zugriffsprüfungen auswirken.

Dieses Konsistenzmodell wirkt sich darauf aus, wie die IAM API funktioniert. Wenn Sie beispielsweise ein Dienstkonto erstellen und dann in einer anderen Anfrage sofort auf dieses Dienstkonto verweisen, wird in der IAM API möglicherweise angezeigt, dass das Dienstkonto nicht gefunden wurde. Dieses Verhalten tritt auf, weil Vorgänge letztendlich konsistent sind. Es kann einige Zeit dauern, bis das neue Dienstkonto für Leseanfragen sichtbar ist.

Nächste Schritte