Informationen zu Richtlinien

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

In diesem Abschnitt werden JSON-Beispiele für Cloud 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 dem Ursprung, der Zielressource usw., weiter einschränkt. Bedingungen werden üblicherweise verwendet, um abhängig vom Kontext bei der Zugriffsanfrage Einschränkungen auszudrücken.
  • 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 Cloud 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 Cloud IAM-Richtlinie zu schreiben, besteht das Risiko gegenseitiger Überschreibungen. Dieses Risiko entsteht dadurch, dass die Änderung einer Cloud IAM-Richtlinie drei Vorgänge umfasst: Abrufen der aktuellen Richtlinie, Ändern des Inhalts nach Bedarf und anschließendes Festlegen der neuen Richtlinie in vollem Umfang. Wenn zwei Systeme dies gleichzeitig tun, ist es möglich, dass eines dieser Systeme eine aktualisierte Richtlinie festlegt, ohne zu erkennen, dass die Richtlinie zwischen dem Zeitpunkt des ersten Abrufens und dem aktuellen Zeitpunkt geändert wurde.

Um solche Szenarien zu vermeiden, unterstützt Cloud IAM die Gleichzeitigkeitserkennung mithilfe eines etag-Felds in der Richtlinie. Wenn Sie eine Richtlinie abrufen, achten Sie darauf, dass Sie bei der Übermittlung der geänderten Richtlinie das etag aus der abgerufenen Richtlinie verwenden. Wenn die Richtlinie geändert wurde, nachdem Sie sie abgerufen haben, stimmt das etag-Feld nicht überein und schlägt die Aktualisierung fehl.

Wiederholen Sie in diesem Fall den gesamten Vorgang: Rufen Sie die Richtlinie noch einmal ab, wenden Sie die Änderungen an und senden Sie dann die aktualisierte Richtlinie. Wir empfehlen, diese Wiederholungslogik automatisch in Code oder Skripts auszuführen, mit dem bzw. denen Sie Cloud IAM-Richtlinien verwalten.

Beispiel: Einfache Richtlinie

Betrachten Sie die folgende Beispielrichtlinie, die ein Mitglied an eine Rolle bindet:

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

Im obigen Beispiel wird jim@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:jim@example.com"
      ],
      "role": "roles/resourcemanager.organizationAdmin"
    },
    {
      "members": [
        "user:alice@example.com",
        "user:jim@example.com"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Im Beispiel oben wird Jim (jim@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 Jim als auch Alice (alice@example.com) über die Rolle "Projektersteller" (roles/resourcemanager.projectCreator) das Recht, Projekte zu erstellen. Zusammen gewähren diese Bindungen Jim und Alice differenzierten Zugriff, da der Alice gewährte Zugriff Teil des Zugriffs ist, der Jim gewährt wird.

Beispiel: Bedingte Richtlinie

In der folgenden Beispielrichtlinie, die Mitglieder an eine vordefinierte Rolle bindet, ist zur weiteren Einschränkung der Rollenbindung ein Bedingungsausdruck enthalten:

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

Beachten Sie, dass im obigen Beispiel die Richtlinienversion auf 3 festgelegt ist. Dies liegt daran, dass die bedingte Richtlinie als Richtlinienschemaversion 3 konfiguriert ist. Weitere Informationen finden Sie unter "Richtlinienversionen".

Im obigen Beispiel wird der Zugriff detaillierter gesteuert als in den ersten beiden Beispielen. Einer Google-Gruppe (prod-dev@example.com), die mehrere Nutzerkonten sowie ein Dienstkonto (prod-dev-example@appspot.gserviceaccount.com) enthält, wird die vordefinierte Rolle "App Engine-Bereitsteller" (roles/appengine.deployer) zugewiesen. Darüber hinaus wird die Rollenbindung durch eine Datums-/Uhrzeitbedingung weiter eingeschränkt und wird somit zu einer bedingten Rollenbindung: Die Berechtigung der Mitglieder, App Engine-Apps bereitzustellen, läuft zum angegebenen Zeitpunkt ab.

Richtlinieneinschränkungen

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

  • Jede Google Cloud-Ressource, die eine Cloud IAM-Richtlinie auf ihrer Ebene in der Ressourcenhierarchie unterstützt, kann maximal eine Richtlinie haben. Beispiel: Organisationen, Ordner, Projekte oder einzelne Ressourcen wie Compute Engine-Laufwerke, Images und weitere.

  • Jede Richtlinie kann insgesamt bis zu 1.500 members in allen ihren Bindungen enthalten, unabhängig von den Mitgliedstypen. Darüber hinaus ist der Mitgliedstyp "Google-Gruppe" für alle Rollenbindungen in einer Richtlinie auf 250 beschränkt.

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

  • Einige GCP-Dienste unterstützen derzeit keine bedingten Richtlinien auf Ressourcenebene. Beispielsweise kann eine bedingte Richtlinie, die den Zugriff auf die Ressource eines Dienstes einschränkt, für das Projekt festgelegt werden, aber eine bedingte Richtlinie, die für die Ressource selbst festgelegt ist, wird nicht unterstützt.

Richtlinienvererbung 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 Cloud 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. Der Begriff geltende Richtlinie beschreibt, wie alle übergeordneten Richtlinien in der Ressourcenhierarchie für eine Ressource übernommen werden. Hierzu gehören:

  • 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:alice@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:alice@example.com"
      ],
      "role": "roles/storage.objectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Im obigen Beispiel gewährt die Rolle "Storage-Objekt-Ersteller" (roles/storage.objectCreator) Alice das Recht, Cloud Storage-Objekte unter myproject-123 zu erstellen. Es gibt jetzt zwei Rollenbindungen, die Alice Zugriff auf die Cloud Storage-Zielobjekte unter myproject-123 gewähren.

  • Eine Richtlinie auf Organisationsebene gewährt das Recht, alle Cloud Storage-Objekte in dieser Organisation aufzulisten und abzurufen
  • Eine Richtlinie auf Ebene von myproject-123 gewährt das Recht, Objekte unter zu erstellen, wo die Richtlinie angehängt ist.

In der folgenden Tabelle ist die wirksame Richtlinie von Alice zusammengefasst:

Berechtigungen, die über die Rolle "storage.objectViewer" auf Organisationsebene gewährt wurden Berechtigungen, die über die Rolle "storage.objectCreator" auf Ebene von "myproject-123" gewährt wurden Wirksamer Gewährungsbereich für Alice 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 Cloud 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 Cloud IAM zum ersten Mal einbinden, empfehlen wir die Verwendung der jeweils aktuellsten Version des Richtlinienschemas. 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 Cloud IAM-Richtlinie gibt ein version-Feld als Teil der Metadaten der Richtlinie an. Betrachten Sie den markierten Bereich unten:

{
  "bindings": [
    {
      "members": [
        "user:jim@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 nicht nur zur Steuerung des Richtliniensyntaxschemas vorgesehen.

Gültige Richtlinienversionen und Versionsberechnung

Die Richtlinienversion wird durch die Syntaxschemaversion der in der Richtlinie enthaltenen Rollenbindungen bestimmt. Die folgenden Richtlinienversionen sind gültig:

Version Beschreibung
1

Die erste Version des Cloud IAM-Richtlinienschemas. Unterstützt das Binden einer Rolle an ein oder mehrere Mitglieder. Bedingte Bindungen werden nicht unterstützt.

2

Ungültig. Nur zur internen Verwendung.

3

Führt das Feld condition in der Rollenbindung ein, wodurch die Rollenbindung durch kontext- und attributbasierte Regeln weiter eingeschränkt wird. Weitere Informationen finden Sie im Abschnitt Übersicht über die Bedingungen.

Richtlinienversion beim Abrufen einer Richtlinie angeben

Beim Abrufen einer Richtlinie empfehlen wir die Angabe einer Richtlinienversion. Durch das explizite Anfragen einer bestimmten Richtlinienversion erklärt der Client, der den Aufruf zum Abrufen einer Richtlinie startet, dass er weiß, wie die Cloud IAM-Richtlinie dieser Version zu handhaben ist. Wenn keine Richtlinienversion angegeben ist, wird standardmäßig die Version 1 festgelegt.

Cloud IAM berechnet die Richtlinienversion der gespeicherten Richtlinie. Wenn der Richtlinieninhalt derzeit Funktionen nutzt, die nur in höheren Versionen als angefordert verfügbar sind, schlägt der Vorgang getIamPolicy() fehl. Das Fehlerszenario wird unten im Szenario 2 erläutert. Im Erfolgsfall enthält die zurückgegebene Richtlinie die Richtlinienversion, die den Inhalt der Richtlinie widerspiegelt.

Diese Richtlinienversionssteuerung ist hauptsächlich für die Verarbeitung älterer Versionen von Clientbibliotheken aktiviert, die Cloud IAM-Richtlinien der Version 3 mit bedingten Rollenbindungen nicht verarbeiten können. Daher wird verhindert, dass ältere Versionen von Clientbibliotheken unbeabsichtigt eine bedingte Rollenbindung in der Richtlinie entfernen oder ändern. Weitere Details erhalten Sie weiter unten.

Szenario 1: Richtlinie mit der höchsten Richtlinienversion abrufen

Betrachten Sie den folgenden REST-Befehl, um eine Richtlinie für ein Projekt abzurufen.

POST https://cloudresourcemanager.googleapis.com/v1/projects/[PROJECT-ID]:getIamPolicy

Der Anfragetext sollte so festgelegt werden:

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

Der Antworttext enthält die Cloud IAM-Richtlinie des Projekts:

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

In einem anderen Fall kann eine ähnliche Anfrage für ein anderes Projekt die Version 3 anfordern, aber Sie erhalten eine Richtlinie der Version 1, da das zweite Projekt aufgrund seines Inhalts die Richtlinienversion 1 hat. Da die Richtlinie keine bedingte Rollenbindung enthält, sind in diesem Fall nur die Funktionen erforderlich, die im Schema der Version 1 verfügbar sind.

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

Szenario 2: Anfordern einer Richtlinie mit unzureichender Version

Beachten Sie, dass die Richtlinie in Szenario 1 eine bedingte Rollenbindung enthält. In diesem Fall lautet die berechnete Richtlinienversion 3. Angenommen, Sie versuchen dann, eine niedrigere Version wie 1 anzufordern:

POST https://cloudresourcemanager.googleapis.com/v1/projects/[PROJECT-ID]:getIamPolicy

Mit einem leeren Anfragetext oder einem Anfragetext, der so lautet:

{
  "options": {
    "requestedPolicyVersion": 1
  }
}

Die Antwort enthält einen Fehler:

"Requested policy version (1) cannot be less than the existing policy version
(3). For more information please refer to
https://cloud.google.com/iam/docs/policies#versions."

Richtlinienversion beim Festlegen der Richtlinie angeben

Sie können beim Erstellen oder Ändern einer Richtlinie eine Richtlinienversion angeben. Die von Ihnen ausgewählte Version gibt Aufschluss über die Richtlinienschemaversion, die Ihr Client versteht. Wenn diese nicht angegeben wird, wird der Standardwert der Version 1 angenommen.

Cloud IAM berechnet die Richtlinienversion basierend auf dem Inhalt der Richtlinie. Wenn die angegebene Richtlinienschemaversion niedriger als die berechnete Richtlinienversion ist, schlägt der Vorgang setIamPolicy() fehl.

Szenario 1: Richtlinie einer höheren Version mit einer Richtlinie einer niedrigeren Version aktualisieren

Betrachten Sie die folgende Richtlinie, die derzeit gültig ist und vom Vorgang getIamPolicy() zurückgegeben wurde.

{
  "bindings": [
    {
      "members": [
        "user:alice@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
}

Diese Richtlinie enthält eine bedingte Rollenbindung und hat die Version 3. Die Richtlinie wird so aktualisiert. Alice erhält dann uneingeschränkten Zugriff auf Cloud Storage-Ressourcen als Speicheradministrator, indem Folgendes festgelegt wird:

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

Wie empfohlen, wird die angegebene Version auf 3 festgelegt. Dies ist die höchste Richtlinienversion, die Ihr Client unterstützt. Beachten Sie, dass in diesem Fall die Version 3 in der setIamPolicy()-Anfrage zur erfolgreichen Aktualisierung der Richtlinie erforderlich ist. Dies stellt den Schutz vor dem versehentlichen Überschreiben einer Richtlinie der Version 3 von einem Client dar, der nur Richtlinien mit der maximalen Version niedriger als 3 unterstützt. In diesem Fall erhalten Sie die Fehlermeldung "Specified policy version (1) cannot be less than the existing policy version (3)".

Nach der erfolgreichen Einrichtung dieser Richtlinie mit der angegebenen Version 3 enthält die zurückgegebene Antwort Folgendes:

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

Die zurückgegebene Richtlinie in der Antwort enthält die berechnete Version basierend auf dem Inhalt der erfolgreich festgelegten Richtlinie. In diesem Fall ist sie auf 1 festgelegt.

Szenario 2: Aktualisieren einer Richtlinie mit unzureichender Version

Betrachten Sie die folgende Richtlinie, die die falsche Version angibt:

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

In diesem Fall ist die benutzerdefinierte Richtlinienversion niedriger als die berechnete Richtlinienversion. Die Anfrage setIamPolicy() schlägt fehl. Die Antwort enthält einen Fehler:

"Specified policy version (1) must be at least 3 based on the policy's
contents. For more information, please refer to
https://cloud.google.com/iam/docs/policies#versions."

Sie Beheben dieses Problem, wenn Sie entweder die Richtlinienversion auf 3 aktualisieren, falls Ihr Client diese Richtlinienversion verstehen kann, oder die Bedingung entfernen.

Clientbibliothek und Codeunterstützung für Richtlinienversionen

Derzeit unterstützen nicht alle Google Cloud-Clientbibliotheken Cloud IAM-Richtlinienversionen höher als 1. Wenn Sie eine Version der Clientbibliothek verwenden, die vor der Einführung der Cloud IAM-Richtlinienversion 3 erstellt wurde, kann Ihre Clientbibliothek die Richtlinien der Version 3 nicht verarbeiten. In diesem Fall erhält die Clientbibliothek möglicherweise eine Fehlermeldung, wenn sie versucht, eine Richtlinie mit der berechneten Richtlinienversion 3 festzulegen oder abzurufen.

Folgendes ist bei der Verwaltung von Cloud IAM-Richtlinien über eine Clientbibliothek wichtig:

  • Achten Sie immer darauf, dass Ihre bevorzugte Clientbibliothek die neueste Richtlinienversion unterstützt, und legen Sie bei der Interaktion mit Richtlinien bei Ihren Google Cloud-Ressourcen mit dem aktuellen Client immer den korrekten Wert der Richtlinienversion fest.

  • Geben Sie beim Abrufen oder Festlegen einer Richtlinie immer die neueste Richtlinienversion an. Derzeit ist dies die Version 3.

Mindestens unterstützte Versionen

Nur die Google APIs-Clientbibliotheken unterstützen derzeit Cloud IAM-Richtlinienversionen höher als 1. Google Cloud-Clientbibliotheken unterstützen keine Richtlinienversionen höher als 1.

Alle Dienste und die zugehörigen Client-Bibliotheken sind unten aufgeführt.

Clientbibliotheken für Google APIs

Die niedrigste Bibliotheksversion pro Sprache wird unterstützt für:

  • Cloud Storage API
  • Cloud KMS API
  • Compute Engine Alpha API
  • Compute Engine Beta API
  • Resource Manager API
  • Cloud IAM API

Die unterstützten Sprachbibliotheken sind unten aufgeführt:

Cloud-Clientbibliotheken

Die folgenden Bibliotheken unterstützen die Richtlinienversion 3 nicht:

  • Cloud Storage API
  • Cloud KMS API

Nicht unterstützte Sprachenbibliotheken sind unten aufgeführt:

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, Richtlinien möglichst auf Ordnerebene festzulegen.

  • Richtlinienversion angeben: Zur Verwaltung von Cloud IAM-Richtlinien empfehlen wir die Verwendung der bereitgestellten Google Cloud-Tools wie der Cloud Console und des gcloud-Tools. Geben Sie beim Interagieren mit der REST API immer die aktuelle Richtlinienversion an, wenn Sie eine getIamPolicy()- oder setIamPolicy()-Anfrage senden. Achten Sie immer darauf, dass Ihre bevorzugte Clientbibliothek die neueste Richtlinienversion unterstützt, und geben Sie immer die aktuelle Richtlinienversion an, wenn Sie Richtlinien über Ihre Clientbibliothek abrufen oder festlegen.