Informationen zu Richtlinien

Die Zugriffssteuerung für Google Cloud-Ressourcen wird durch IAM-Richtlinien (Identity and Access Management) verwaltet, die mit Ressourcen verknüpft sind. Sie können nur eine IAM-Richtlinie an eine Ressource anhängen. Die IAM-Richtlinie steuert den Zugriff auf die Ressource selbst sowie auf alle untergeordneten Elemente dieser Ressource, die die Richtlinie übernehmen.

Auf dieser Seite werden IAM-Richtlinien im JSON-Format angezeigt. Sie können auch das gcloud-Befehlszeilentool verwenden, um Richtlinien im YAML-Format abzurufen.

Richtlinienstruktur

Eine IAM-Richtlinie ist eine Sammlung von Rollenbindungen und Metadaten. Eine Rollenbindung gibt an, welcher Zugriff auf eine Ressource gewährt werden soll. Sie verknüpft ein oder mehrere Mitglieder mit einer einzigen IAM-Rolle und kontextspezifischen Bedingungen, die die Art und den Zeitpunkt der Rollenzuweisung beeinflussen. Die Metadaten enthalten zusätzliche Informationen über die Richtlinie, wie z. B. ein ETag und die Version, um die Richtlinienverwaltung zu erleichtern.

Jede Rollenbindung kann die folgenden Felder enthalten:

  • Ein Mitglied, auch als Identität oder Prinzipal bezeichnet, kann ein Nutzerkonto, ein Dienstkonto, eine Google-Gruppe oder eine Domain sein.

    Jede IAM-Richtlinie kann bis zu 1.500 Mitglieder enthalten. Maximal 250 dieser Mitglieder können Google-Gruppen sein.

    IAM berücksichtigt dafür alle Vorkommen der einzelnen Mitglieder in den Bindungen der Richtlinie. Mitglieder in mehreren Bindungen werden nicht dedupliziert. Beispiel: Wenn das Mitglied user:alice@example.com in 50 Bindungen enthalten ist, können Sie in allen Bindungen der Richtlinie weitere 1.450 Mitglieder hinzufügen.

  • Eine Rolle ist eine benannte Sammlung von Berechtigungen, mit denen Sie bestimmte Aktionen für Google Cloud-Ressourcen vornehmen können.

  • Eine Bedingung ist ein logischer Ausdruck, der die Rollenbindung anhand von Attributen der Anfrage wie Ursprung, Zielressource usw. weiter einschränkt. Mit Bedingungen wird in der Regel anhand des Kontextes einer Anfrage bestimmt, ob der Zugriff gewährt wird.

    Wenn eine Rollenbindung eine Bedingung enthält, wird sie als bedingte Rollenbindung bezeichnet.

    Einige Google Cloud-Dienste akzeptieren keine Bedingungen in IAM-Richtlinien. Eine Liste der Dienste und Ressourcentypen, die Bedingungen akzeptieren, finden Sie unter Ressourcentypen, die bedingte Rollenbindungen akzeptieren.

Die Metadaten für eine IAM-Richtlinie enthalten die folgenden Felder:

  • Ein etag-Feld, das für die Gleichzeitigkeitserkennung verwendet wird und sicherstellt, dass die Richtlinien regelmäßig aktualisiert werden. Weitere Informationen finden Sie unter ETags in einer Richtlinie verwenden auf dieser Seite.
  • Ein version-Feld, das die Schemaversion für eine bestimmte Richtlinie angibt. Weitere Informationen finden Sie unter Richtlinienversionen auf dieser Seite.

Bei Organisationen, Ordnern, Projekten und Rechnungskonten kann die IAM-Richtlinie auch das Feld auditConfig enthalten. Dieses Feld gibt die Aktivitätstypen an, die Audit-Logs für jeden Dienst generieren. Informationen zum Konfigurieren dieses Teils einer IAM-Richtlinie finden Sie unter Audit-Logs zum Datenzugriff konfigurieren.

Im Allgemeinen werden Änderungen beim Aktualisieren einer IAM-Richtlinie innerhalb von 60 Sekunden wirksam. In einigen Fällen kann es jedoch bis zu 7 Minuten dauern, bis die Änderung vollständig in Google Cloud übernommen wurde.

ETags in einer Richtlinie verwenden

Wenn mehrere Systeme versuchen, gleichzeitig in dieselbe IAM-Richtlinie zu schreiben, besteht das Risiko, dass diese Systeme die Änderungen des jeweils anderen überschreiben. Dieses Risiko besteht, weil das Aktualisieren einer IAM-Richtlinie mehrere Vorgänge umfasst:

  1. Bestehende Richtlinie lesen
  2. Richtlinie ändern
  3. Gesamte Richtlinie schreiben

Wenn System A eine Richtlinie liest und System B unmittelbar eine aktualisierte Version dieser Richtlinie schreibt, sind System A die Änderungen von System B nicht bekannt. Wenn System A seine eigenen Änderungen in die Richtlinie schreibt, gehen die Änderungen von System B möglicherweise verloren.

Zur Vermeidung dieses Problems unterstützt die Identitäts- und Zugriffsverwaltung (IAM) die Gleichzeitigkeitserkennung mithilfe eines etag-Felds in der Richtlinie. Jede IAM-Richtlinie enthält ein etag-Feld. Der Wert dieses Felds ändert sich bei jeder Aktualisierung einer Richtlinie. Wenn eine IAM-Richtlinie ein etag-Feld, aber keine Rollenbindungen enthält, gewährt die Richtlinie keine IAM-Rollen.

Das Feld etag enthält einen Wert wie BwUjMhCsNvY=. Achten Sie beim Aktualisieren der Richtlinie darauf, dass das Feld etag in die aktualisierte Richtlinie aufgenommen wird. Wenn die Richtlinie nach dem Abrufen geändert wurde, stimmt der etag-Wert nicht überein und die Aktualisierung schlägt fehl. Für die REST API erhalten Sie den HTTP-Statuscode 409 Conflict. Der Antworttext sieht in etwa so aus:

{
  "error": {
    "code": 409,
    "message": "There were concurrent policy changes. Please retry the whole read-modify-write with exponential backoff.",
    "status": "ABORTED"
  }
}

Wenn dieser Fehler auftritt, wiederholen Sie alle Vorgänge: Lesen Sie die Richtlinie noch einmal, ändern Sie sie bei Bedarf und schreiben Sie die aktualisierte Richtlinie. Wiederholungsversuche sollten Sie automatisch mit exponentiellem Backoff in allen Tools ausführen, die Sie zur Verwaltung von IAM-Richtlinien verwenden.

Informationen zum Aktualisieren von Richtlinien mit dem Muster "Read-Modify-Write" (Lesen-Ändern-Schreiben) finden Sie unter Zugriff zuweisen, ändern und widerrufen.

Beispiel: Einfache Richtlinie

Mit der folgenden Beispielrichtlinie wird ein Mitglied an eine Rolle gebunden:

{
  "bindings": [
    {
      "members": [
        "user:jie@example.com"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Im obigen Beispiel wird jie@example.com die einfache Rolle "Inhaber" ohne Bedingungen zugewiesen. Mit dieser Rolle hat jie@example.com fast unbegrenzten Zugriff.

Beispiel: Richtlinie mit mehreren Rollenbindungen

Betrachten Sie die folgende Beispielrichtlinie, die mehr als eine Rollenbindung enthält. Jede Rollenbindung weist eine andere Rolle zu:

{
  "bindings": [
    {
      "members": [
        "user:jie@example.com"
      ],
      "role": "roles/resourcemanager.organizationAdmin"
    },
    {
      "members": [
        "user:divya@example.com",
        "user:jie@example.com"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Im Beispiel oben wird Jie (jie@example.com) in der ersten Rollenbindung die vordefinierte Rolle Organisationsadministrator (roles/resourcemanager.organizationAdmin) zugewiesen. Diese Rolle enthält Berechtigungen für Organisationen, Ordner und begrenzte Projektvorgänge. In der zweiten Rollenbindung erhalten sowohl Jie als auch Divya (divya@example.com) die Möglichkeit, Projekte über die Rolle „Projektersteller“ (roles/resourcemanager.projectCreator) zu erstellen. Zusammen gewähren diese Rollenbindungen Jie und Divya differenzierten Zugriff. Jie wird dabei ein umfangreicherer Zugriff als Divya erteilt.

Beispiel: Richtlinie mit bedingter Rollenbindung

Sehen Sie sich die folgende IAM-Richtlinie an, die Mitglieder an eine vordefinierte Rolle bindet und einen Bedingungsausdruck zur Beschränkung der Rollenbindung verwendet:

{
  "bindings": [
    {
      "members": [
        "group:prod-dev@example.com",
        "serviceAccount:prod-dev-example@appspot.gserviceaccount.com"
      ],
      "role": "roles/appengine.deployer",
      "condition": {
          "title": "Expires_July_1_2022",
          "description": "Expires on July 1, 2022",
          "expression":
            "request.time < timestamp('2022-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

In diesem Beispiel ist für das Feld version der Wert 3 festgelegt, da die Richtlinie einen Bedingungsausdruck enthält. Die Rollenbindung in der Richtlinie ist bedingt. Die Rolle wird der Google-Gruppe prod-dev@example.com und dem Dienstkonto prod-dev-example@appspot.gserviceaccount.com nur bis zum 1. Juli 2022 zugewiesen.

Weitere Informationen zu den Features der einzelnen Richtlinienversionen finden Sie auf dieser Seite unter Richtlinienversionen.

Beispiel: Richtlinie mit bedingten und bedingungslosen Rollenbindungen

Sehen Sie sich die folgende IAM-Richtlinie an, die sowohl bedingte als auch bedingungslose Rollenbindungen für dieselbe Rolle enthält:

{
  "bindings": [
    {
      "members": [
        "serviceAccount:prod-dev-example@appspot.gserviceaccount.com"
       ],
       "role": "roles/appengine.deployer"
    },
    {
      "members": [
        "group:prod-dev@example.com",
        "serviceAccount:prod-dev-example@appspot.gserviceaccount.com"
      ],
      "role": "roles/appengine.deployer",
      "condition": {
        "title": "Expires_July_1_2022",
        "description": "Expires on July 1, 2022",
        "expression":
          "request.time < timestamp('2022-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

In diesem Beispiel ist das Dienstkonto serviceAccount:prod-dev-example@appspot.gserviceaccount.com in zwei Rollenbindungen für dieselbe Rolle enthalten. Die erste Rollenbindung hat keine Bedingung. Die zweite Rollenbindung hat eine Bedingung, durch die die Rolle nur bis zum 1. Juli 2022 zugewiesen wird.

Mit dieser Richtlinie wird die Rolle immer dem Dienstkonto zugewiesen. In IAM überschreiben bedingte Rollenbindungen keine Rollenbindungen ohne Bedingung. Wenn ein Mitglied an eine Rolle gebunden ist und die Rollenbindung keine Bedingung hat, hat das Mitglied immer diese Rolle. Das Hinzufügen des Mitglieds zu einer bedingten Rollenbindung für dieselbe Rolle hat keine Auswirkungen.

Im Gegensatz dazu ist die Google-Gruppe group:prod-dev@example.com nur in der bedingten Rollenbindung enthalten. Daher hat sie die Rolle nur bis zum 1. Juli 2022.

Beispiel: Richtlinie, die eine Rolle an ein gelöschtes Mitglied bindet

Sehen Sie sich die folgende Beispielrichtlinie an. Diese Richtlinie bindet eine Rolle an einen Nutzer donald@example.com, dessen Konto gelöscht wurde:

{
  "bindings": [
    {
      "members": [
        "deleted:user:donald@example.com?uid=123456789012345678901"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Wenn Sie einen neuen Nutzer mit dem Namen donald@example.com erstellen, gelten die Rollenbindungen der Richtlinie für den gelöschten Nutzer nicht für den neuen Nutzer. Damit wird verhindert, dass neue Nutzer Rollen übernehmen, die gelöschten Nutzern gewährt wurden. Wenn Sie dem neuen Nutzer Rollen zuweisen möchten, fügen Sie den neuen Nutzer den Rollenbindungen der Richtlinie hinzu, wie unter Richtlinien mit gelöschten Mitgliedern auf dieser Seite gezeigt.

Außerdem enthält der Name des Nutzers jetzt das Präfix deleted: und das Suffix ?uid=numeric-id, wobei numeric-id die eindeutige numerische ID des gelöschten Nutzers ist. In diesem Beispiel wird anstelle von user:donald@example.com die Richtlinie deleted:user:donald@example.com?uid=123456789012345678901 angezeigt.

Dienstkonten und Gruppen verhalten sich genauso wie Nutzer. Wenn Sie ein Dienstkonto oder eine Gruppe löschen und eine Richtlinie anzeigen, die dieses Mitglied enthält, hat der Name des gelöschten Mitglieds das Präfix deleted: und das Suffix ?uid=numeric-id.

Standardrichtlinien

Alle Ressourcen, die IAM-Richtlinien akzeptieren, werden mit Standard-IAM-Richtlinien erstellt. Die Standardrichtlinien der meisten Ressourcen sind leer. Die Standardrichtlinien einiger Ressourcen enthalten aber automatisch bestimmte Rollenbindungen. Wenn Sie beispielsweise ein neues Projekt erstellen, enthält die IAM-Richtlinie für das Projekt automatisch eine Rollenbindung, die Ihnen die Inhaberrolle (roles/owner) für das Projekt zuweist.

Diese Rollenbindungen werden vom System erstellt, sodass der Nutzer für die Ressource keine getIamPolicy- oder setIamPolicy-Berechtigungen benötigt, damit die Rollenbindungen erstellt werden können.

Informationen dazu, ob eine Ressource mit einer IAM-Richtlinie erstellt wird, finden Sie in der Dokumentation der Ressource.

Richtlinienübernahme und die Ressourcenhierarchie

Google Cloud-Ressourcen sind hierarchisch organisiert, wobei der Organisationsknoten der Stammknoten in der Hierarchie ist, darunter folgen optional Ordner und dann Projekte. Die meisten anderen Ressourcen werden unter der Projektebene erstellt und verwaltet. Jede Ressource hat genau ein übergeordnetes Element, mit Ausnahme des Stammknotens in der Hierarchie. Weitere Informationen finden Sie im Abschnitt Ressourcenhierarchie.

Die Ressourcenhierarchie muss beim Festlegen von IAM-Richtlinien berücksichtigt werden. Wenn eine Richtlinie auf einer höheren Ebene in der Hierarchie, z. B. auf Organisationsebene, Ordnerebene oder Projektebene, festgelegt wird, umfasst der freigegebene Zugriffsbereich die Ressourcenebene, der diese Richtlinie zugeordnet ist, sowie alle Ressourcen unterhalb dieser Ebene. Beispielsweise gilt eine auf Organisationsebene festgelegte Richtlinie für die Organisation und alle unter der Organisation angeordneten Ressourcen. Ebenso gilt eine auf Projektebene festgelegte Richtlinie für das Projekt und alle Ressourcen im Projekt.

Der Begriff Richtlinienübernahme beschreibt, wie Richtlinien auf Ressourcen unterhalb ihrer Ebene in der Ressourcenhierarchie angewendet werden. Mit dem Begriff geltende Richtlinie wird beschrieben, wie alle übergeordneten Richtlinien in der Ressourcenhierarchie für eine Ressource übernommen werden. Darunter fallen folgende Richtlinien:

  • Die für die Ressource festgelegte Richtlinie
  • Die Richtlinien, die für alle übergeordneten Ressourcenebenen der Ressource in der Hierarchie festgelegt wurden

Alle neuen Rollenbindungen, die von der übergeordneten Ressource übernommen werden und die sich auf die geltende Richtlinie der Ressource auswirken, werden unabhängig voneinander ausgewertet. Eine bestimmte Zugriffsanfrage für die Ressource wird positiv beantwortet, wenn der Anfrage durch eine der übergeordneten Rollenbindungen Zugriff gewährt wird.

Wenn eine neue Rollenbindung auf eine beliebige Ebene der übernommenen Richtlinie der Ressource angewendet wird, erhöht sich der Umfang der Zugriffsberechtigungen.

Beispiel: Richtlinienübernahme

Zum besseren Verständnis der Richtlinienübernahme zeigt das folgende Beispiel eine Richtlinie, die auf Organisationsebene festgelegt wird:

Richtlinie auf Organisationsebene

{
  "bindings": [
    {
      "members": [
        "user:divya@example.com"
      ],
      "role": "roles/storage.objectViewer"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Die Rolle "Storage-Objekt-Betrachter" (roles/storage.objectViewer) enthält die Berechtigungen get und list für Projekte und Cloud Storage-Objekte. Bei Festlegung auf Organisationsebene wird diese Rollenbindung auf den Ebenen unter der Organisation angewendet, einschließlich aller Projekte und aller Cloud Storage-Objekte unter diesen Projekten.

Zum besseren Verständnis der Richtlinienübernahme wird nachfolgend gezeigt, was geschieht, wenn eine Richtlinie auch bei myproject-123 festgelegt wird:

Richtlinie auf Projektebene

{
  "bindings": [
    {
      "members": [
        "user:divya@example.com"
      ],
      "role": "roles/storage.objectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Im Beispiel oben ermöglicht die Rolle "Storage-Objekt-Ersteller" (roles/storage.objectCreator) Divya das Erstellen von Cloud Storage-Objekten unter myproject-123. Nun, da zwei Rollenbindungen Divya den Zugriff auf die Cloud Storage-Zielobjekte unter myproject-123 gewähren, gelten die folgenden Richtlinien:

  • Eine Richtlinie auf Organisationsebene gewährt die Berechtigung, alle Cloud Storage-Objekte in dieser Organisation aufzulisten und abzurufen.
  • Eine Richtlinie auf Projektebene für das Projekt myproject-123 gewährt die Möglichkeit, Objekte innerhalb dieses Projekts zu erstellen.

In der folgenden Tabelle wird die für Divya geltende Richtlinie zusammengefasst:

Berechtigungen, die über die Rolle "storage.objectViewer" auf Organisationsebene gewährt wurden Berechtigungen, die über die Rolle "storage.objectCreator" auf der Ebene des Projekts "myproject-123" gewährt wurden Geltender Gewährungsbereich für Divya unter "myproject-123"
resourcemanager.projects.get
resourcemanager.projects.list
storage.objects.get
storage.objects.list
resourcemanager.projects.get
resourcemanager.projects.list
storage.objects.create
resourcemanager.projects.get
resourcemanager.projects.list
storage.objects.get
storage.objects.list
storage.objects.create

Richtlinienversionen

Im Laufe der Zeit werden von IAM ggf. neue Funktionen hinzugefügt, durch die wesentliche Felder im Richtlinienschema hinzugefügt oder geändert werden. Solche Änderungen werden in neuen Richtlinienschemaversionen eingeführt, um zu verhindern, dass bestehende Integrationen, die auf Konsistenz in der Richtlinienstruktur angewiesen sind, nicht mehr funktionieren.

Wenn Sie IAM zum ersten Mal einbinden, empfehlen wir Ihnen, die aktuell verfügbare Version des Richtlinienschemas zu verwenden. Im Folgenden werden die verschiedenen verfügbaren Versionen und deren Verwendung erläutert. Außerdem wird beschrieben, wie Sie die gewünschte Version festlegen, und es werden einige Szenarien zur Fehlerbehebung aufgezeigt.

Jede bestehende IAM-Richtlinie gibt ein version-Feld als Teil der Metadaten der Richtlinie an. Sehen Sie sich den nachfolgenden markierten Bereich an:

{
  "bindings": [
    {
      "members": [
        "user:jie@example.com"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Dieses Feld gibt die Syntaxschemaversion der Richtlinie an. Jede Version der Richtlinie enthält ein bestimmtes Syntaxschema, das von Rollenbindungen verwendet werden kann. Eine neuere Version kann Rollenbindungen mit dem aktuelleren Syntaxschema enthalten, das von älteren Versionen nicht unterstützt wird. Dieses Feld ist nur zur Steuerung des Richtliniensyntaxschemas vorgesehen.

Gültige Richtlinienversionen

IAM-Richtlinien können die folgenden Richtlinienversionen verwenden:

Version Beschreibung
1 Die erste Version des IAM-Syntaxschemas für Richtlinien. Unterstützt die Bindung einer Rolle an ein oder mehrere Mitglieder. Bedingte Rollenbindungen werden nicht unterstützt.
2 Für die interne Verwendung reserviert.
3 Führt das Feld condition in der Rollenbindung ein, wodurch die Rollenbindung durch kontext- und attributbasierte Regeln eingeschränkt wird. Weitere Informationen finden Sie in der Übersicht zu IAM Conditions.

Richtlinienversion beim Abrufen einer Richtlinie angeben

Wenn Sie eine IAM-Richtlinie abrufen, empfehlen wir, bei Verwendung der REST API und der Clientbibliotheken in der Anfrage eine Richtlinienversion anzugeben. Wenn eine Anfrage eine Richtlinienversion enthält, geht IAM davon aus, dass der Aufrufer die Features dieser Richtlinienversion kennt und diese korrekt verarbeiten kann.

Wenn die Anfrage keine Richtlinienversion enthält, geht IAM davon aus, dass der Aufrufer eine Richtlinie der Version 1 verwenden möchte.

Wenn Sie eine Richtlinie abrufen, prüft IAM die Richtlinienversion in der Anfrage oder die Standardversion, wenn in der Anfrage keine Version angegeben wurde. IAM prüft die Richtlinie auch auf Felder, die in einer Richtlinie der Version 1 nicht unterstützt werden. Von diesen Informationen hängt ab, welche Art von Antwort gesendet wird:

  • Wenn die Richtlinie keine Bedingungen enthält, gibt IAM immer eine Richtlinie der Version 1 zurück, unabhängig von der Versionsnummer in der Anfrage.
  • Wenn die Richtlinie Bedingungen enthält und der Aufrufer eine Richtlinie der Version 3 angefordert hat, gibt IAM eine Richtlinie der Version 3 zurück, die die Bedingungen umfasst. Ein Beispiel dafür ist das Szenario 1 auf dieser Seite.
  • Wenn die Richtlinie Bedingungen enthält und der Aufrufer eine Richtlinie der Version 1 angefordert oder keine Version angegeben hat, gibt IAM eine Richtlinie der Version 1 zurück.

    Bei Rollenbindungen, die eine Bedingung enthalten, hängt IAM den String _withcond_ an den Rollennamen an, gefolgt von einem Hashwert, z. B. roles/iam.serviceAccountAdmin_withcond_2b17cc25d2cd9e2c54d8. Die Bedingung selbst ist nicht aufgeführt. Ein entsprechendes Beispiel ist das Szenario 2 auf dieser Seite.

Dieses Verhalten verhindert Probleme mit älteren Clientbibliotheken, die keine bedingten Rollenbindungen kennen. Weitere Informationen finden Sie auf dieser Seite unter Unterstützung der Clientbibliothek für Richtlinienversionen.

Szenario 1: Richtlinienversion, die IAM Conditions vollständig unterstützt

Angenommen, Sie rufen die folgende REST API-Methode auf, um die IAM-Richtlinie für ein Projekt abzurufen:

POST https://cloudresourcemanager.googleapis.com/v1/projects/project-id:getIamPolicy

Der Anfragetext dafür lautet:

{
  "options": {
    "requestedPolicyVersion": 3
  }
}

Die Antwort enthält die IAM-Richtlinie des Projekts. Wenn die Richtlinie mindestens eine bedingte Rollenbindung enthält, wird für das Feld version der Wert 3 festgelegt:

{
  "bindings": [
    {
      "members": [
        "user:user@example.com"
      ],
      "role": "roles/iam.securityReviewer",
      "condition": {
          "title": "Expires_July_1_2022",
          "description": "Expires on July 1, 2022",
          "expression": "request.time < timestamp('2022-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

Wenn die Richtlinie keine bedingten Rollenbindungen enthält, wird für das Feld version der Wert 1 eingestellt, auch wenn in der Anfrage die Version 3 angegeben wurde:

{
  "bindings": [
    {
      "members": [
        "user:user@example.com"
      ],
      "role": "roles/iam.securityReviewer",
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 1
}

Szenario 2: Richtlinienversion mit eingeschränkter Unterstützung für IAM Conditions

Angenommen, Sie rufen die folgende REST API-Methode auf, um die IAM-Richtlinie für ein Projekt abzurufen:

POST https://cloudresourcemanager.googleapis.com/v1/projects/project-id:getIamPolicy

Der Anfragetext ist leer, es wird also keine Versionsnummer angegeben. Daher verwendet IAM die Standardversion 1 der Richtlinie.

Die Richtlinie enthält eine bedingte Rollenbindung. Da die Richtlinienversion 1 lautet, wird die Bedingung nicht in der Antwort aufgeführt. Um anzugeben, dass die Rollenbindung eine Bedingung verwendet, hängt IAM den String _withcond_ an den Rollennamen an, gefolgt von einem Hashwert:

{
  "bindings": [
    {
      "members": [
        "user:user@example.com"
      ],
      "role": "roles/iam.securityReviewer_withcond_58e135cabb940ad9346c"
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 1
}

Richtlinienversion beim Festlegen einer Richtlinie angeben

Beim Erstellen einer IAM-Richtlinie wird empfohlen, eine Richtlinienversion in der Anfrage anzugeben. Wenn eine Anfrage eine Richtlinienversion angibt, geht IAM davon aus, dass der Aufrufer die Features in dieser Richtlinienversion kennt und diese korrekt verarbeiten kann.

Wenn in der Anfrage keine Richtlinienversion angegeben ist, erlaubt IAM nur die Felder, die in einer Richtlinie der Version 1 enthalten sein können. Als Best Practice sollten Sie keine bedingten Rollenbindungen in einer Richtlinie der Version 1 ändern. Da die Richtlinie nicht die Bedingung für die einzelnen Bindungen anzeigt, wissen Sie nicht, wann oder wo die Bindung tatsächlich gewährt wird. Rufen Sie stattdessen die Darstellung der Version 3 der Richtlinie ab, die die Bedingung für jede Rollenbindung angibt, und verwenden Sie diese Darstellung, um die Bindungen zu aktualisieren.

Szenario: Richtlinienversionen in Anfragen und Antworten

Angenommen, Sie verwenden die REST API, um eine IAM-Richtlinie abzurufen, und geben in der Anfrage die Version 3 an. Die Antwort enthält die folgende Richtlinie, die die Version 3 verwendet:

{
  "bindings": [
    {
      "members": [
        "user:divya@example.com"
      ],
      "role": "roles/storage.admin",
      "condition": {
          "title": "Weekday_access",
          "description": "Monday thru Friday access only in America/Chicago",
          "expression": "request.time.getDayOfWeek('America/Chicago') >= 1 && request.time.getDayOfWeek('America/Chicago') <= 5"
      }
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 3
}

divya@example.com soll nun während der gesamten Woche die Rolle des Storage-Administrators (roles/storage.admin) haben und nicht nur an bestimmten Wochentagen. Sie entfernen dafür die Bedingung aus der Rollenbindung und senden eine REST API-Anfrage, um die Richtlinie festzulegen. In der Anfrage geben Sie noch einmal die Version 3 an:

{
  "bindings": [
    {
      "members": [
        "user:divya@example.com"
      ],
      "role": "roles/storage.admin"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 3
}

Die Antwort enthält die aktualisierte Richtlinie:

{
  "bindings": [
    {
      "members": [
        "user:divya@example.com"
      ],
      "role": "roles/storage.admin"
    }
  ],
  "etag": "BwWd8I+ZUAQ=",
  "version": 1
}

Die Richtlinie in der Antwort verwendet die Version 1, obwohl in der Anfrage die Version 3 angegeben wurde. Dies liegt daran, dass die Richtlinie nur Felder nutzt, die in einer Richtlinie der Version 1 unterstützt werden.

Unterstützung von Clientbibliotheken für Richtlinienversionen

Einige Clientbibliotheken für Google Cloud unterstützen nur Richtlinien der Version 1. Wenn Ihre Clientbibliothek keine höheren Richtlinienversionen unterstützt, können Sie keine Features anwenden, die nur in höheren Versionen verfügbar sind. Für IAM Conditions muss beispielsweise die Richtlinienversion 3 unterstützt werden.

Wenn Sie IAM-Funktionen verwenden, die in Richtlinien der Version 1 nicht verfügbar sind, z. B. IAM Conditions, verwenden Sie eine Clientbibliothek, die diese Richtlinienversion unterstützt und in der Anfrage korrekt festlegt.

Die folgenden Google APIs-Clientbibliotheken für IAM unterstützen die Richtlinienversion 3:

Sprache Versionen, die Richtlinienversion 3 unterstützen
C# Google.Apis >=v1.41.1
Go google-api-go-client >=v0.10.0
Java
Node.js googleapis >=v43.0.0
PHP google/apiclient >=v2.4.0
Python google-api-python-client >=v1.7.11
Ruby google-api-client >=v0.31.0

Sie können diese Clientbibliotheken verwenden, um IAM-Richtlinien der Version 3 für Ressourcen für die folgenden Dienste zu verwalten:

  • IAM
  • Cloud KMS
  • Cloud Storage
  • Compute Engine
  • Resource Manager

Andere Clientbibliotheken, einschließlich der Google Cloud-Clientbibliotheken, unterstützen nur Richtlinien der Version 1.

gcloud-Unterstützung für Richtlinienversionen

Sie können IAM-Richtlinien der Version 3 mit dem gcloud-Tool verwalten. Zum Aktualisieren auf die neueste Version führen Sie gcloud components update aus.

Richtlinien mit gelöschten Mitgliedern

Wenn eine Rollenbindung in einer Richtlinie ein gelöschtes Mitglied enthält und Sie eine Rollenbindung für ein neues Mitglied mit demselben Namen hinzufügen, wird die Rollenbindung immer auf das neue Mitglied angewendet.

Ein Beispiel ist diese Richtlinie, die eine Rollenbindung an den gelöschten Nutzer donald@example.com und das gelöschte Dienstkonto my-service-account@project-id.iam.gserviceaccount.com enthält:

{
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:my-service-account@project-id.iam.gserviceaccount.com?uid=123456789012345678901",
        "deleted:user:donald@example.com?uid=234567890123456789012"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Angenommen, Sie erstellen einen neuen Nutzer, der auch donald@example.com genannt wird, und Sie möchten den neuen Nutzer an die Rolle „Projektersteller“ (roles/resourcemanager.projectCreator) binden, sodass der Nutzer Google Cloud-Projekte erstellen kann. Aktualisieren Sie die Richtlinie wie in diesem Beispiel, um den neuen Nutzer zu binden:

{
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:my-service-account@project-id.iam.gserviceaccount.com?uid=123456789012345678901",
        "deleted:user:donald@example.com?uid=234567890123456789012"
      ],
      "role": "roles/owner"
    },
    {
      "members": [
        "user:donald@example.com"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Damit Sie Ihre IAM-Richtlinien einfacher prüfen können, haben Sie die Möglichkeit, den gelöschten Nutzer auch aus der Rollenbindung an die Inhaberrolle zu entfernen:

{
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:my-service-account@project-id.iam.gserviceaccount.com?uid=123456789012345678901"
      ],
      "role": "roles/owner"
    },
    {
      "members": [
        "user:donald@example.com"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Best Practices für Richtlinien

Die folgenden Best Practices gelten für Organisationen mit vielen Google Cloud-Nutzern:

  • Wenn Sie mehrere Nutzerkonten mit denselben Zugriffskonfigurationen verwalten, verwenden Sie stattdessen Google-Gruppen. Fügen Sie jedes einzelne Nutzerkonto in die Gruppe ein und gewähren Sie die gewünschten Rollen der Gruppe statt einzelnen Nutzerkonten.

  • Auf Organisationsebene gewährte Berechtigungen: Überlegen Sie sorgfältig, welche Mitglieder Zugriffsberechtigungen auf Organisationsebene erhalten sollen. Für die meisten Organisationen sollten nur wenige bestimmte Teams (z. B. Sicherheits- und Netzwerkteams) Zugriff auf dieser Ebene der Ressourcenhierarchie erhalten.

  • Auf Ordnerebene gewährte Berechtigungen: Sie können die Betriebsstruktur Ihrer Organisation mithilfe von Ordnerebenen darstellen. Dabei kann jeder übergeordnete oder untergeordnete Ordner mit verschiedenen Gruppen von Zugriffsberechtigungen konfiguriert werden, die den Geschäfts- und Betriebsanforderungen entsprechen. Beispiel: Ein übergeordneter Ordner kann eine Abteilung darstellen, einer der untergeordneten Ordner kann den Ressourcenzugriff und den Betrieb durch eine Gruppe widerspiegeln und ein anderer untergeordneter Ordner kann ein kleines Team darstellen. Beide dieser Ordner können Projekte enthalten, die für das jeweilige Team benötigt werden. Eine solche Verwendung von Ordnern kann eine geeignete Zugriffstrennung sicherstellen, wobei die von den übergeordneten Ordnern und der Organisation übernommenen Richtlinien berücksichtigt werden. Diese Vorgehensweise erfordert weniger Richtlinienpflege beim Erstellen und Verwalten von Google Cloud-Ressourcen.

  • Auf Projektebene gewährte Berechtigungen: Gewähren Sie Rollenbindungen auf Projektebene nur dann, wenn dies für bestimmte Gruppen oder für einzelne detaillierte Berechtigungen erforderlich ist. Zur einfacheren Verwaltung, insbesondere bei vielen Projekten, empfehlen wir dringend, Richtlinien möglichst auf Ordnerebene festzulegen.

Nächste Schritte