Informationen zu Richtlinien

Die Zugriffssteuerung für Google Cloud-Ressourcen wird durch IAM-Richtlinien verwaltet. Eine IAM-Richtlinie ist mit einer Ressource verknüpft. Diese Richtlinie steuert den Zugriff auf die Ressource selbst sowie durch Richtlinienübernahme auf alle untergeordneten Ressourcen.

In diesem Abschnitt werden JSON-Beispiele für IAM-Richtlinien verwendet. YAML wird aber ebenso unterstützt.

Richtlinienstruktur

Eine Richtlinie besteht aus einer Sammlung von Bindungen, einer Audit-Konfiguration und Metadaten. Eine Bindung gibt an, wie der Zugriff auf Ressourcen gewährt werden soll. Sie verknüpft ein oder mehrere Mitglieder mit einer einzigen Rolle und kontextspezifischen Bedingungen, die die Art und den Zeitpunkt der Rollenzuweisung beeinflussen. Das Feld AuditConfig gibt die Konfigurationsdaten an, die festlegen, wie Zugriffsversuche geprüft werden sollen. Die Metadaten enthalten zusätzliche Informationen über die Richtlinie, wie z. B. ein ETag und die Version, um die Richtlinienverwaltung zu erleichtern. Jeder Teil wird im Folgenden beschrieben:

  • Eine Liste von Bindungen. Jede Bindung enthält die folgenden Felder:
    • Ein Mitglied, auch als Identität oder Prinzipal bezeichnet, kann ein Nutzerkonto, ein Dienstkonto, eine Google-Gruppe oder eine Domain sein.
    • Eine Rolle ist eine benannte Sammlung von Berechtigungen, die den Zugriff zur Durchführung von Aktionen für Google Cloud-Ressourcen gewähren.
    • 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.
  • Ein AuditConfig-Feld, mit dem das Audit-Logging für die Richtlinie konfiguriert wird.
  • Metadaten, die die folgenden Felder enthalten:
    • Ein etag-Feld, das für die Gleichzeitigkeitserkennung verwendet wird und sicherstellt, dass die Richtlinien regelmäßig aktualisiert werden.
    • Ein version-Feld, das die Schemaversion für eine bestimmte Richtlinie angibt. Die Verwendung des Felds version wird im Abschnitt Richtlinienversionen ausführlicher erläutert.

Eine Rollenbindung in einer IAM-Richtlinie ist die Kombination aus der Rolle und einer Liste von Mitgliedern. Wenn eine Rollenbindung auch eine Bedingung enthält, wird sie als bedingte Rollenbindung bezeichnet.

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. Der Wert dieses Felds ändert sich bei jeder Aktualisierung einer Richtlinie.

Wenn Sie eine Richtlinie aktualisieren müssen, achten Sie darauf, beim Schreiben der aktualisierten Richtlinie das etag-Feld anzugeben. 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. Die Bindung an eine einfache Rolle hat oft zu viele Berechtigungen. In diesem Fall umfasst die Rolle "Inhaber" mehr als 1.000 Berechtigungen. Wir empfehlen, eine vordefinierte Rolle oder eine benutzerdefinierte Rolle anstelle einer einfachen Rolle zu verwenden, da diese Rollentypen im Umfang und in der Anzahl ihrer Berechtigungen eingeschränkt sind.

Beispiel: Richtlinie mit mehreren Bindungen

Betrachten Sie die folgende Beispielrichtlinie, die mehr als eine Bindung enthält. Jede Bindung gewährt eine andere Rolle:

{
  "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) über die Rolle "Projektersteller" (roles/resourcemanager.projectCreator) die Berechtigung zum Erstellen von Projekten. Zusammen gewähren diese Bindungen Jie und Divya differenzierten Zugriff, da der Divya erteilte Zugriff eine Teilmenge des Zugriffs ist, der Jie erteilt wird.

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_2020",
          "description": "Expires on July 1, 2020",
          "expression":
            "request.time < timestamp('2020-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 Bindung in der Richtlinie ist eine bedingte Rollenbindung. Damit wird die Rolle der Google-Gruppe prod-dev@example.com und dem Dienstkonto prod-dev-example@appspot.gserviceaccount.com zugewiesen, jedoch nur bis zum 1. Juli 2020.

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_2020",
        "description": "Expires on July 1, 2020",
        "expression":
          "request.time < timestamp('2020-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 Bindung hat keine Bedingung. Die zweite Bindung hat eine Bedingung, die der Rolle nur noch bis zum 1. Juli 2020 gewährt 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 Bindung 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 vor dem 1. Juli 2020.

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 Bindungen der Richtlinie für den gelöschten Nutzer nicht für den neuen Nutzer. Dieses Verhalten verhindert, dass neue Nutzer Rollen übernehmen, die gelöschten Nutzern gewährt wurden.

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.

In diesem Beispiel können Sie den neuen Nutzer donald@example.com keiner Bindung in der Richtlinie hinzufügen, da die Richtlinie bereits an einen gelöschten Nutzer mit dem gleichen Namen gebunden ist. Informationen zur Behebung dieses Problems finden Sie in der Anleitung für Richtlinien mit gelöschten Mitgliedern.

Richtlinieneinschränkungen

Für IAM-Richtlinien gelten die folgenden Einschränkungen:

  • Jede Google Cloud-Ressource, die auf ihrer Ebene in der Ressourcenhierarchie eine IAM-Richtlinie unterstützt, kann maximal eine Richtlinie haben. Beispiel: Organisationen, Ordner, Projekte oder einzelne Ressourcen wie Compute Engine-Laufwerke, Images und weitere.
  • Jede IAM-Richtlinie kann bis zu 1.500 members 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.

  • Im Allgemeinen werden alle Richtlinienänderungen innerhalb von 60 Sekunden nach dem Aufruf von setIamPolicy() oder nach der Aktualisierung einer Rollenbindung in der Cloud Console wirksam. Unter bestimmten Umständen kann es jedoch bis zu 7 Minuten dauern, bis die Änderungen vollständig im gesamten System angewendet werden.

  • Einige Google Cloud-Dienste unterstützen derzeit keine bedingten Rollenbindungen für Richtlinien auf Ressourcenebene, auch wenn der Name bzw. der Typ der Ressource oder Google Cloud in einer bedingten Rollenbindung verwendet werden können. Beispielsweise kann in einigen Fällen eine Richtlinie mit einer bedingten Rollenbindung, die den Zugriff auf die Ressource eines Dienstes einschränkt, für das Projekt, aber nicht für die Ressource selbst festgelegt werden. Weitere Informationen finden Sie in der Referenz zu IAM Conditions.

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 Versionen des Richtlinienschemas aufgenommen, um zu verhindern, dass bestehende Einbindungen, 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 spezifisches Syntaxschema, das von Bindungen verwendet werden kann. Die 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 die 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_2020",
          "description": "Expires on July 1, 2020",
          "expression": "request.time < timestamp('2020-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 Bindung zeigt, 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

Wenn Sie das gcloud-Tool zum Verwalten von IAM-Richtlinien verwenden, achten Sie darauf, dass Sie Version 263.0.0 oder höher verwenden. Ältere Versionen unterstützen nur Richtlinien der Version 1.

Zum Prüfen der Versionsnummer des gcloud-Tools führen Sie gcloud version aus. Zum Aktualisieren auf die neueste Version führen Sie gcloud components update aus.

Richtlinien mit gelöschten Mitgliedern

Wenn eine Bindung in einer Richtlinie ein gelöschtes Mitglied enthält und Sie versuchen, eine Bindung für ein neues Mitglied mit demselben Namen hinzuzufügen, fügt IAM der Bindung das gelöschte Mitglied statt des neuen Mitglieds hinzu.

Ziehen Sie beispielsweise diese Richtlinie in Erwägung, die eine Bindung 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
}

Wenn Sie einen neuen Nutzer mit dem Namen donald@example.com erstellen, können Sie den neuen Nutzer keiner Bindung in der Richtlinie hinzufügen. Angenommen, Sie möchten beispielsweise den neuen Nutzer an die Rolle "Projektersteller" (roles/resourcemanager.projectCreator) binden, mit der Nutzer Google Cloud-Projekte erstellen können. So aktualisieren Sie die Richtlinie:

{
  "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
}

Wenn Sie die aktualisierte Richtlinie erhalten, verweist die Bindung auf den gelöschten Nutzer und nicht auf den neuen Nutzer:

{
  "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": [
        "deleted:user:donald@example.com?uid=234567890123456789012"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwWWK2TI-5A=",
  "version": 1
}

Wenn Sie ein neues Dienstkonto mit dem Namen my-service-account@project-id.iam.gserviceaccount.com erstellen, können Sie das neue Dienstkonto ebenfalls nicht zu einer Bindung in der Richtlinie hinzufügen. Die gleiche Beschränkung gilt auch für andere Arten von Mitgliedern.

Nehmen Sie eine der folgenden Änderungen vor, um dieses Problem zu beheben:

  • Stellen Sie das gelöschte Mitglied wieder her, sofern möglich. Wenn in einer Bindung ein gelöschtes Mitglied angezeigt wird und Sie das Mitglied wiederherstellen können, erhält das Mitglied automatisch die Rollen in der Bindung zurück. Sie müssen die Rollen des Mitglieds nicht manuell wiederherstellen.

    Informationen zum Wiederherstellen eines G Suite-Nutzers finden Sie unter Kürzlich gelöschte Nutzer wiederherstellen.

    Informationen zum Wiederherstellen eines Dienstkontos finden Sie unter Dienstkonto wiederherstellen.

  • Ändern Sie die Richtlinie so:

    1. Widerrufen Sie alle Rollen, die von der Richtlinie an das gelöschte Mitglied gebunden werden. Wenn das gelöschte Mitglied in mehr als einer Bindung der Richtlinie vorkommt, müssen Sie das gelöschte Mitglied aus jeder Bindung entfernen.

      Sie müssen das gelöschte Mitglied nicht aus Bindungen in anderen Richtlinien entfernen.

    2. Weisen Sie dem neuen Mitglied die entsprechenden Rollen zu.

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.

Weitere Informationen