IAM-Übersicht

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

Mit IAM können Sie detaillierte Zugriffsberechtigungen auf bestimmte Ressourcen von Google Cloud gewähren und unerwünschten Zugriff auf andere Ressourcen verhindern. Sie haben mit IAM die Möglichkeit, das Sicherheitsprinzip der geringsten Berechtigung anzuwenden, das besagt, dass niemand mehr Berechtigungen haben sollte, als er tatsächlich benötigt.

Funktionsweise von IAM

Mit IAM verwalten Sie die Zugriffssteuerung. Sie legen fest, wer (Identität) welchen Zugriff (Rolle) auf welche Ressource hat. VM-Instanzen von Google Compute Engine, GKE-Cluster (Google Kubernetes Engine) und Cloud Storage-Buckets sind z. B. Google Cloud-Ressourcen. Die Organisationen, Ordner und Projekte, mit denen Sie Ihre Ressourcen organisieren, sind ebenfalls Ressourcen.

In IAM wird dem Endnutzer die Berechtigung für den Zugriff auf eine Ressource nicht direkt gewährt. Stattdessen werden Berechtigungen in Rollen gruppiert, die dann authentifizierten Hauptkonten zugewiesen werden. In der Vergangenheit bezeichnete IAM die Hauptkonten häufig als Mitglieder. In einigen APIs wird dieser Begriff weiterhin verwendet.

Eine Zulassungsrichtlinie, auch als IAM-Richtlinie bezeichnet, definiert und erzwingt, welche Rollen welchen Hauptkonten zugewiesen werden. Jede Zulassungsrichtlinie ist mit einer Ressource verknüpft. Wenn ein authentifiziertes Hauptkonto versucht, auf eine Ressource zuzugreifen, prüft IAM die Zulassungsrichtlinie der Ressource, um festzustellen, ob die Aktion zulässig ist.

Das folgende Diagramm zeigt ein Beispiel für die Berechtigungsverwaltung in IAM.

Eine Zulassungsrichtlinie mit zwei Rollenbindungen. Grafik: Die Rollenbindungen verknüpfen bestimmte Hauptkonten mit bestimmten Rollen.

Dieses Modell für die Zugriffsverwaltung besteht aus drei Hauptabschnitten:

  • Hauptkonto. Ein Hauptkonto ist eine Identität, die auf eine Ressource zugreifen kann. Jedes Hauptkonto hat eine eigene Kennung.
  • Rolle: Eine Rolle ist eine Sammlung von Berechtigungen. Berechtigungen bestimmen, welche Vorgänge bei einer Ressource zugelassen sind. Wenn Sie einem Hauptkonto eine Rolle zuweisen, gewähren Sie alle mit ihr verknüpften Berechtigungen.
  • Richtlinie: Die Zulassungsrichtlinie umfasst eine Reihe von Rollenbindungen, die ein oder mehrere Hauptkonten an einzelne Rollen binden. Wenn Sie festlegen möchten, wer (Hauptkonto) welche Art von Zugriff (Rolle) auf eine Ressource hat, erstellen Sie eine Zulassungsrichtlinie und verknüpfen sie mit der Ressource.

Im vorhergehenden Diagramm bindet z. B. die Zulassungsrichtlinie Hauptkonten wie user@example.com an Rollen wie die App Engine-Administratorrolle (roles/appengine.appAdmin). Wenn die Zulassungsrichtlinie an ein Projekt angehängt ist, erhalten die Hauptkonten die angegebenen Rollen innerhalb des Projekts.

Nachstehend werden diese Konzepte detaillierter beschrieben.

In IAM gewähren Sie Hauptkonten Zugriff. Hauptkonten repräsentieren eine Identität, die auf eine Ressource zugreifen kann. Im Rahmen der Zugriffsverwaltung können Hauptkonten einen der folgenden Typen haben:

Weitere Informationen zu den Formaten der Kennung für die einzelnen Hauptkontotypen finden Sie unter Hauptkonto-Kennungen.

Google-Konten

Ein Google-Konto stellt einen Entwickler, einen Administrator oder eine andere Person dar, die mit Google Cloud interagiert und dabei ein von ihr bei Google erstelltes Konto verwendet. Jede E-Mail-Adresse, die mit einem Google-Konto verknüpft ist, kann als Hauptberechtigter verwendet werden, einschließlich gmail.com-E-Mail-Adressen oder E-Mail-Adressen mit anderen Domains. Neue Nutzer können sich für ein Google-Konto anmelden, wenn sie die Registrierungsseite für das Google-Konto aufrufen.

Dienstkonten

Ein Dienstkonto ist ein Konto für eine Anwendung oder Computing-Arbeitslast anstelle eines einzelnen Endnutzers. Wenn Sie Code ausführen, der in Google Cloud gehostet wird, geben Sie ein Dienstkonto an, das als Identität für Ihre Anwendung verwendet werden soll. Sie können so viele Dienstkonten erstellen, wie erforderlich sind, um die verschiedenen logischen Komponenten Ihrer Anwendung zu repräsentieren. Weitere Informationen zur Verwendung eines Dienstkontos zur Authentifizierung Ihrer Anwendung finden Sie unter Dienstkonten.

Google-Gruppen

Eine Google-Gruppe ist eine benannte Sammlung von Google-Konten und Dienstkonten. Jede Google-Gruppe hat eine eindeutige E-Mail-Adresse, die mit der Gruppe verknüpft ist. Die E-Mail-Adresse, die mit einer Google-Gruppe verknüpft ist, finden Sie auf der Startseite der jeweiligen Google-Gruppe unter Info. Weitere Informationen zu Google-Gruppen finden Sie auf der Startseite von Google-Gruppen.

Google-Gruppen sind eine bequeme Möglichkeit, um Zugriffskontrollen auf eine Sammlung von Nutzern anzuwenden. Sie können die Zugriffssteuerungen für eine ganze Gruppe auf einmal gewähren oder ändern, anstatt sie nacheinander für jeden einzelnen Nutzer oder jedes Dienstkonto individuell zu gewähren oder zu ändern. Sie können auch Hauptkonten zu einer Google-Gruppe hinzufügen oder aus ihr entfernen. Das ist einfacher, als Zugriffsrichtlinien zu aktualisieren, um Nutzer hinzuzufügen oder zu entfernen.

Google-Gruppen haben keine Anmeldedaten. Außerdem können Sie Google-Gruppen nicht zum Feststellen der Identität für eine Anfrage zum Zugriff auf eine Ressource verwenden.

Google Workspace-Konten

Ein Google Workspace-Konto stellt eine virtuelle Gruppe aller Google-Konten dar, die es enthält. Google Workspace-Konten sind mit dem Internetdomainnamen Ihrer Organisation verknüpft, z. B. example.com. Wenn Sie ein Google-Konto für einen neuen Nutzer erstellen, z. B. username@example.com, wird dieses Google-Konto der virtuellen Gruppe für Ihr Google Workspace-Konto hinzugefügt.

Wie Google-Gruppen können Google Workspace-Domains nicht zum Feststellen der Identität verwendet werden. Sie ermöglichen aber eine effektive Berechtigungsverwaltung.

Cloud Identity-Domains

Eine Cloud Identity-Domain ähnelt einem Google Workspace-Konto, weil sie eine virtuelle Gruppe aller Google-Konten in einer Organisation repräsentiert. Nutzer einer Cloud Identity-Domain haben jedoch keinen Zugriff auf Anwendungen und Features von Google Workspace. Unter Was ist Cloud Identity? erfahren Sie mehr zu diesem Thema.

allAuthenticatedUsers

Der Wert allAuthenticatedUsers ist eine spezielle Kennzeichnung für alle Dienstkonten und alle Nutzer im Internet, die sich mit einem Google-Konto authentifiziert haben. Diese Kennzeichnung schließt auch Konten ein, die nicht mit einem Google Workspace-Konto oder einer Cloud Identity-Domain verbunden sind, z. B. persönliche Gmail-Konten. Nicht authentifizierte Nutzer, wie anonyme Besucher, sind nicht eingeschlossen.

Dieser Hauptkontotyp enthält keine föderierten Identitäten, die von externen Identitätsanbietern (IdPs) verwaltet werden. Wenn Sie die Mitarbeiteridentitätsföderation oder die Identitätsföderation von Arbeitslasten verwenden, verwenden Sie nicht allAuthenticatedUsers. Verwenden Sie stattdessen eine der folgenden Optionen:

Einige Ressourcentypen unterstützen diesen Hauptkontotyp nicht.

allUsers

Der Wert allUsers ist eine spezielle Kennzeichnung für alle Internetnutzer, einschließlich authentifizierter und nicht authentifizierter Nutzer.

Einige Ressourcentypen unterstützen diesen Hauptkontotyp nicht.

Föderierte Identitäten in einem Workforce Identity-Pool

Eine föderierte Identität in einem Workforce Identity-Pool ist eine Nutzeridentität, die von einem externen IdP verwaltet und mithilfe der Workforce Identity-Föderation föderiert wird. Sie können eine bestimmte Identität in einem Workforce Identity-Pool verwenden oder mithilfe bestimmter Attribute eine Gruppe von Nutzeridentitäten in einem Workforce Identity-Pool angeben. Informationen zu Hauptkonto-IDs für föderierte Identitäten finden Sie unter Hauptkonto-IDs.

Föderierte Identitäten in einem Workload Identity-Pool

Eine föderierte Identität in einem Workload Identity-Pool ist eine Arbeitslastidentität, die von einem externen Identitätsanbieter verwaltet und mithilfe der Workload Identity-Föderation föderiert wird. Sie können eine bestimmte Arbeitslastidentität in einem Workload Identity-Pool verwenden oder mithilfe bestimmter Attribute eine Gruppe von Arbeitslastidentitäten in einem Workload Identity-Pool angeben. Informationen zu Hauptkonto-IDs für föderierte Identitäten finden Sie unter Hauptkonto-IDs.

GKE-Pods

Arbeitslasten, die in GKE ausgeführt werden, verwenden die Workload Identity Federation for GKE, um auf Google Cloud-Dienste zuzugreifen. Weitere Informationen zu Hauptkonto-IDs für GKE-Pods finden Sie unter Kubernetes-Ressourcen in IAM-Richtlinien referenzieren.

Ressource

Wenn ein Nutzer Zugriff auf eine bestimmte Google Cloud-Ressource benötigt, können Sie ihm eine Rolle für diese Ressource zuweisen. Beispiele für Ressourcen sind Projekte, Compute Engine-Instanzen und Cloud Storage-Buckets.

Einige Dienste unterstützen IAM-Berechtigungen mit feineren Abstufungen, als dies auf Projektebene möglich ist. Beispielsweise können Sie einem Nutzer für einen bestimmten Cloud Storage-Bucket die Rolle "Storage-Administrator" (roles/storage.admin) oder für eine bestimmte Compute Engine-Instanz die Rolle "Compute-Instanzadministrator" (roles/compute.instanceAdmin) zuweisen.

In anderen Fällen können Sie IAM-Berechtigungen auf Projektebene erteilen. Diese Berechtigungen werden dann von allen Ressourcen im jeweiligen Projekt übernommen. Wenn Sie beispielsweise Zugriff auf alle Cloud Storage-Buckets in einem Projekt gewähren möchten, erteilen Sie keinen gesonderten Zugriff auf jeden einzelnen Bucket, sondern auf das Projekt, das die Buckets enthält. Genauso verhält es sich, wenn auf alle Compute Engine-Instanzen in einem Projekt zugegriffen werden soll: Sie erteilen den Zugriff auf das Projekt und nicht auf jede einzelne Instanz.

Informationen dazu, welche Rollen für welche Ressourcen zugewiesen werden können, finden Sie unter Informationen zu Rollen in der Spalte Niedrigste Ressource für einzelne Rollen.

Berechtigungen

Berechtigungen bestimmen, welche Vorgänge bei einer Ressource zugelassen sind. In IAM werden Berechtigungen so dargestellt: service.resource.verb. Beispiel: pubsub.subscriptions.consume.

Berechtigungen entsprechen oft eins zu eins den REST API-Methoden. Das bedeutet, dass jedem Google Cloud-Dienst eine Reihe von Berechtigungen für jede bereitgestellte REST API-Methode zugeordnet ist. Der Aufrufer dieser Methode braucht die entsprechenden Berechtigungen. Wenn Sie beispielsweise "Pub/Sub" verwenden und die Methode topics.publish() aufrufen müssen, benötigen Sie die Berechtigung pubsub.topics.publish für dieses Thema.

Sie weisen Nutzern Berechtigungen nicht direkt zu. Stattdessen legen Sie Rollen fest, die die entsprechenden Berechtigungen umfassen, und weisen diese dann dem Nutzer zu. Eine Liste aller verfügbaren Berechtigungen zusammen mit ihren Rollen finden Sie in der Referenz zu Berechtigungen.

Rollen

Eine Rolle ist eine Sammlung von Berechtigungen. Sie können dem Nutzer eine Berechtigung nicht direkt zuweisen. Stattdessen weisen Sie ihm eine Rolle zu. Wenn Sie einem Nutzer eine Rolle zuweisen, erhält er alle mit ihr verknüpften Berechtigungen.

Grafik: Berechtigung zur Rollenzuordnung

In IAM gibt es verschiedene Arten von Rollen:

  • Einfache Rollen: Dies sind Rollen, die zuvor schon in der Google Cloud Console verfügbar waren. Diese Rollen heißen "Inhaber", "Bearbeiter" und "Betrachter".

  • Vordefinierte Rollen: Dies sind Rollen, die eine feiner abgestufte Zugriffssteuerung ermöglichen als die einfachen Rollen. Beispielsweise ermöglicht die vordefinierte Rolle Pub/Sub-Publisher (roles/pubsub.publisher) ausschließlich Zugriff für die Veröffentlichung von Nachrichten in einem Cloud Pub/Sub-Thema.

  • Benutzerdefinierte Rollen: Dies sind Rollen, die Sie erstellen, um Berechtigungen an die Anforderungen Ihrer Organisation anzupassen, wenn diese durch vordefinierte Rollen nicht erfüllt werden.

Weitere Informationen zu Rollen finden Sie in den folgenden Ressourcen:

Zulassungsrichtlinie

Wenn ein authentifiziertes Hauptkonto versucht, auf eine Ressource zuzugreifen, prüft IAM anhand der Zulassungsrichtlinie der Ressource, ob die Aktion zulässig ist.

Sie können Nutzern Rollen zuweisen, indem Sie eine Zulassungsrichtlinie erstellen. Dabei handelt es sich um eine Sammlung von Anweisungen, die festlegen, wer welche Art von Zugriff hat. Zulassungsrichtlinien werden mit einer Ressource verbunden und erfordern eine Zugriffssteuerung, wenn auf diese Ressource zugegriffen wird.

IAM-Richtlinie.

Eine Zulassungsrichtlinie besteht aus einer Liste von Rollenbindungen. Eine Rollenbindung bindet mehrere in einer Liste aufgeführte Hauptkonten an eine Rolle.

  • role: Das ist die Rolle, die Sie dem Hauptkonto zuweisen möchten. role wird in der Form roles/service.roleName angegeben. Cloud Storage bietet beispielsweise die Rollen roles/storage.objectAdmin, roles/storage.objectCreator und roles/storage.objectViewer.

  • members: Eine Liste mit einer oder mehreren Hauptkonten, wie im Abschnitt Identitätskonzepte in diesem Dokument beschrieben. Jeder Hauptkontotyp wird mit einem Präfix gekennzeichnet, z. B. ein Google-Konto (user:), ein Dienstkonto (serviceAccount:), eine Google-Gruppe (group:) oder ein Google Workspace-Konto oder eine Cloud Identity-Domain (domain:). Im folgenden Beispielcode-Snippet wird die Rolle storage.objectAdmin den folgenden Hauptkonten mit dem entsprechenden Präfix gewährt: user:my-user@example.com, serviceAccount:my-other-app@appspot.gserviceaccount.com und group:my-group@example.com. Die Rolle objectViewer wird user:my-user@example.com zugewiesen.

Das folgende Code-Snippet veranschaulicht die Struktur einer Zulassungsrichtlinie.

{
  "bindings": [
    {
      "role": "roles/storage.objectAdmin",
      "members": [
        "user:my-user@example.com",
        "serviceAccount:my-other-app@appspot.gserviceaccount.com",
        "group:my-group@example.com"
      ]
    },
    {
      "role": "roles/storage.objectViewer",
      "members": [
        "user:my-user@example.com"
      ]
    }
  ]
}

IAM und Richtlinien-APIs

IAM stellt eine Reihe von Methoden zur Verfügung, mit denen Sie Zulassungsrichtlinien für Google Cloud-Ressourcen erstellen und verwalten können. Diese Methoden werden von den Diensten bereitgestellt, die IAM unterstützen. Beispielsweise werden die IAM-Methoden durch die Resource Manager API, die Pub/Sub API und die Cloud Life Sciences APIs bereitgestellt.

Die Methoden von IAM sind die folgenden:

  • setIamPolicy(): Legt die Zulassungsrichtlinien von Ressourcen fest.
  • getIamPolicy(): Ruft eine zuvor festgelegte Zulassungsrichtlinie ab.
  • testIamPermissions(): Testet, ob der Aufrufer die angegebenen Berechtigungen für eine Ressource hat.

Sie finden die API-Referenzthemen für diese Methoden in der Dokumentation für jeden Dienst, der IAM unterstützt.

Ressourcenhierarchie

Google Cloud-Ressourcen sind hierarchisch organisiert.

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

Jeder Ressource ist genau ein Element übergeordnet. Weitere Informationen finden Sie unter Ressourcenhierarchie in Resource Manager.

Im folgenden Diagramm ist ein Beispiel für eine Google Cloud-Ressourcenhierarchie dargestellt.

Hierarchie für IAM-Ressourcen.

Sie können eine IAM-Richtlinie auf jeder Ebene der Ressourcenhierarchie festlegen: der Organisationsebene, der Ordnerebene, der Projektebene oder der Ressourcenebene. Ressourcen übernehmen die Zulassungsrichtlinien aller ihrer übergeordneten Ressourcen. Die geltende Zulassungsrichtlinie für eine Ressource setzt sich aus der Zulassungsrichtlinie für diese Ressource und den Zulassungsrichtlinien zusammen, die von höherer Stelle in der Hierarchie übernommen wurden.

Die Übernahme der Richtlinie ist transitiv. Dies bedeutet, dass Ressourcen Zugriffsrichtlinien vom Projekt übernehmen, das Richtlinien von Ordnern übernimmt, die wiederum Richtlinien von der Organisation übernehmen. Daher gelten Zugriffsrichtlinien auf Organisationsebene auch auf der Ressourcenebene.

Im obigen Diagramm ist topic_a beispielsweise eine Pub/Sub-Ressource, die sich im Projekt example-prod befindet. Wenn Sie also einem Nutzer die Rolle „Bearbeiter“ für example-prod zuweisen, gewähren Sie ihm damit effektiv die Rolle „Bearbeiter“ für topic_a.

Die Zulassungsrichtlinien für untergeordnete Ressourcen übernehmen die Zulassungsrichtlinien für ihre übergeordneten Ressourcen. Wenn Sie beispielsweise einem Nutzer für ein Projekt die Bearbeiterrolle und demselben Nutzer die Betrachterrolle für eine untergeordnete Ressource zuweisen, behält der Nutzer weiterhin die Bearbeiterrolle für die untergeordnete Ressource. Wenn Sie die Ressourcenhierarchie ändern, ändert sich auch die Richtlinienübernahme. Wenn Sie beispielsweise ein Projekt in eine Organisation verschieben, übernimmt das Projekt Richtlinien von der Zulassungsrichtlinie der Organisation.

IAM-Unterstützung für Google Cloud-Dienste

In IAM wird jede API-Methode in allen Google Cloud-Diensten geprüft, um dafür zu sorgen, dass das Konto, das die API-Anfrage stellt, die entsprechende Berechtigung zur Verwendung der Ressource hat.

Google Cloud-Dienste bieten vordefinierte Rollen, die eine detaillierte Zugriffssteuerung ermöglichen. Compute Engine bietet beispielsweise Rollen wie „Compute-Instanzadministrator“ und „Compute-Netzwerkadministrator“. Cloud Storage bietet beispielsweise Rollen wie „Storage Folder Admin“ und „Storage Object User“.

Vordefinierte Rollen sind für die meisten Google Cloud-Dienste verfügbar. Ausführliche Informationen finden Sie in der Liste aller vordefinierten Rollen. Wenn Sie noch mehr Kontrolle über Berechtigungen benötigen, können Sie eine benutzerdefinierte Rolle erstellen.

Sie können Nutzern bestimmte Rollen für den Zugriff auf Ressourcen mit feineren Abstufungen als auf Projektebene zuweisen. Sie können beispielsweise eine Zulassungsrichtlinie erstellen, die einem Nutzer die Abonnentenrolle für ein bestimmtes Pub/Sub-Thema zuweist. In der Liste aller vordefinierten Rollen wird der Ressourcentyp mit der niedrigsten Berechtigung oder detailliertesten Differenzierung angezeigt, der die einzelnen Rollen akzeptiert.

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. Außerdem können Änderungen, die sich auf die Zugriffsprüfung auswirken, einige Zeit in Anspruch nehmen.

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

Jetzt testen

Wenn Sie mit Google Cloud noch nicht vertraut sind, erstellen Sie einfach ein Konto, um die Leistungsfähigkeit unserer Produkte in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.

Jetzt kostenlos starten