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: Richtlinie mit bedingter Rollenbindung

Betrachten Sie die folgende Cloud IAM-Richtlinie, die Mitglieder an eine vordefinierte Rolle bindet und einen Bedingungsausdruck verwendet, um die Rollenbindung einzuschränken:

{
      "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 das Feld policy auf 3 eingestellt, da die Richtlinie einen Bedingungsausdruck enthält. Die Bindung in der Richtlinie ist eine bedingte Rollenbindung. Sie weist die Rolle der Google-Gruppe prod-dev@example.com und dem Dienstkonto prod-dev-example@appspot.gserviceaccount.com zu, aber nur bis zum 1. Juli 2020.

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

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 Cloud IAM-Richtlinie kann bis zu 1.500 members enthalten. Bis zu 250 dieser Mitglieder können Google-Gruppen sein.

    Cloud IAM zählt alle Mitglieder in jeder Bindung. Mitglieder, die in mehreren Bindungen vorhanden sind, 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 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 Google Cloud-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. Weitere Informationen finden Sie in der Referenz zu Cloud 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 ist beim Festlegen einer Cloud IAM-Richtlinie wichtig. 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 myproject-123 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

Für Cloud IAM-Richtlinien können die folgenden Richtlinienversionen verwendet werden:

Version Beschreibung
1 Die erste Version des Cloud IAM-Syntaxschemas für Richtlinien. Unterstützt das Binden 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 über kontext- und attributbasierte Regeln eingeschränkt wird. Weitere Informationen finden Sie in der Übersicht über Cloud IAM Conditions.

Richtlinienversion beim Abrufen einer Richtlinie angeben

Wenn Sie eine Cloud IAM-Richtlinie erhalten, empfehlen wir Ihnen, für die REST API und die Clientbibliotheken eine Richtlinienversion in der Anfrage anzugeben. Wenn eine Anfrage eine Richtlinienversion angibt, geht Cloud IAM davon aus, dass der Aufrufer über die Features in dieser Richtlinienversion verfügt und diese korrekt verarbeiten kann.

Wenn die Anfrage keine Richtlinienversion angibt, geht Cloud IAM davon aus, dass der Aufrufer eine Richtlinie der Version 1 wünscht.

Wenn Sie eine Richtlinie abrufen, überprüft Cloud IAM die Richtlinienversion in der Anfrage oder die Standardversion, wenn die Anfrage keine Version angegeben hat. Cloud IAM überprüft auch die Richtlinie für Felder, die in einer Richtlinie der Version 1 nicht unterstützt werden. Anhand dieser Informationen wird entschieden, welche Art von Antwort gesendet werden soll:

  • Wenn die Richtlinie keine Bedingungen enthält, gibt Cloud 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 angefragt hat, gibt Cloud IAM eine Richtlinie der Version 3 zurück, die die Bedingungen enthält. Sehen Sie sich beispielsweise Szenario 1 auf dieser Seite an.
  • Wenn die Richtlinie Bedingungen enthält und der Aufrufer eine Richtlinie der Version 1 angefordert oder keine Version angegeben hat, gibt Cloud IAM eine Richtlinie der Version 1 zurück.

    Bei Rollenbindungen, die eine Bedingung enthalten, hängt Cloud IAM den String _withcond_ an den Rollennamen an, gefolgt von einem Hashwert, zum Beispiel roles/iam.serviceAccountAdmin_withcond_2b17cc25d2cd9e2c54d8. Die Bedingung selbst ist nicht vorhanden. Sehen Sie sich beispielsweise Szenario 2 auf dieser Seite an.

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

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

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

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

Der Anfragetext enthält den folgenden Text:

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

Die Antwort enthält die Cloud IAM-Richtlinie des Projekts. Wenn die Richtlinie mindestens eine bedingte Rollenbindung enthält, wird das Feld version auf 3 gesetzt:

{
      "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, ist das Feld version auf 1 eingestellt, obwohl die Anfrage die Version 3 angegeben hat:

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

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

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

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

Der Anfragetext ist leer; es wird keine Versionsnummer angegeben. Daher verwendet Cloud IAM die standardmäßige Richtlinienversion 1.

Die Richtlinie enthält eine bedingte Rollenbindung. Da die Richtlinienversion 1 lautet, wird die Bedingung nicht in der Antwort angezeigt. Um anzugeben, dass die Rollenbindung eine Bedingung verwendet, hängt Cloud 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

Wenn Sie eine Cloud IAM-Richtlinie festlegen, empfehlen wir Ihnen, in der Anfrage eine Richtlinienversion anzugeben. Wenn eine Anfrage eine Richtlinienversion angibt, geht Cloud IAM davon aus, dass der Aufrufer über die Features in dieser Richtlinienversion verfügt und diese korrekt verarbeiten kann.

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

Szenario: Richtlinienversionen in Anfragen und Antworten

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

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

Sie beschließen, dass alice@example.com während der Woche die Rolle des Storage-Administrators (roles/storage.admin) übernehmen soll, nicht nur an bestimmten Wochentagen. Sie entfernen die Bedingung aus der Rollenbindung und senden eine REST API-Anfrage, um die Richtlinie festzulegen. Sie geben in der Anfrage noch einmal die Version 3 an:

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

Die Antwort enthält die aktualisierte Richtlinie:

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

Die Richtlinie in der Antwort verwendet die Version 1, obwohl die Anfrage die Version 3 angegeben hat, da die Richtlinie nur Felder verwendet, die in einer Richtlinie der Version 1 unterstützt werden.

Unterstützung der Clientbibliothek für Richtlinienversionen

Einige Clientbibliotheken für Google Cloud unterstützen nur Richtlinien der Version 1. Wenn Ihre Clientbibliothek keine späteren Richtlinienversionen unterstützt, können Sie keine Features verwenden, die nur in späteren Versionen verfügbar sind. Cloud IAM Conditions erfordert beispielsweise Unterstützung für die Richtlinienversion 3.

Wenn Sie Cloud IAM-Features verwenden, die in Richtlinien der Version 1 nicht verfügbar sind, z. B. Cloud IAM-Bedingungen, verwenden Sie eine Clientbibliothek, die diese Richtlinienversion unterstützt und in der Anfrage richtig angibt.

Die folgenden Google APIs-Clientbibliotheken für Cloud 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 Cloud IAM-Richtlinien der Version 3 für Ressourcen für die folgenden Dienste zu verwalten:

  • Cloud IAM
  • Cloud KMS
  • cl
  • 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 zur Verwaltung von Cloud IAM-Richtlinien verwenden, müssen Sie Version 263.0.0 oder höher verwenden. Frühere Versionen unterstützen nur Richtlinien der Version 1.

Führen Sie gcloud version aus, um die Versionsnummer des gcloud-Tools zu überprüfen. Führen Sie zum Aktualisieren auf die neueste Version gcloud components update aus.

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.

Nächste Schritte