GCP für AWS-Ingenieure: Wie sich Ihre AWS-Instinkte übertragen lassen (und wo sie versagen)

Wenn Sie fließend in AWS sind und nun auf Google Cloud blicken, ist die gute Nachricht, dass sich etwa 80 % Ihrer Instinkte direkt übertragen lassen: Es gibt eine Hierarchie zur Organisation von Dingen, eine rollenbasierte Methode zur Zugriffsvergabe, eine OIDC-Lösung für schlüssellose CI und einen Bootstrap-Vorgang zum „Kaltstart Ihres State-Backends“. Die schlechte Nachricht sind die restlichen 20 % - und diese konzentrieren sich auf einige stark frequentierte Bereiche, in denen das AWS-Vorgehen eher eine verwirrende Ablehnung als einen offensichtlichen Fehler hervorruft. Dieser Beitrag ist die Übersetzungsebene: dieselben Aufgaben, die Sie in AWS erledigen, in GCP ausgeführt, mit den aufgezeigten Fallstricken.

Die Kurzversion, falls Sie nur einen Absatz lesen: Die Hierarchie von GCP (organization -> folder -> project -> resource) lässt sich sauber auf AWS Organizations -> OU -> account -> resource abbilden, aber drei Dinge durchbrechen Ihr Muskelgedächtnis. IAM ist eine reine Allow-Richtlinie, die an den Ressourcenbaum gebunden ist und nach unten vererbt wird - es gibt keine Richtlinie, die an einen Benutzer angehängt ist. Die Service-APIs eines Projekts sind alle standardmäßig deaktiviert, und nichts funktioniert, bis Sie jede einzelne aktivieren. Und Sie übernehmen keine Rollen, sondern imitieren Service Accounts, die selbst Ressourcen mit ihrer eigenen Zugriffsrichtlinie sind. Alles Weitere unten führt dies aus.

Die größte Umstellung: Berechtigungen leben am Baum, nicht an Identitäten

In AWS ist das mentale Modell „eine Richtlinie an eine Identität anhängen“. Sie erstellen einen Benutzer oder eine Rolle, heften JSON daran, und die Berechtigung reist mit dem Principal. Ressourcenrichtlinien existieren, aber die an die Identität angehängte Richtlinie ist der Schwerpunkt.

GCP kehrt dies um. Eine IAM-Richtlinie ist eine Reihe von Bindungen - (member, role)-Paare -, die an einen Knoten in der Ressourcenhierarchie (organization, folder, project oder eine einzelne resource) angehängt sind. Die Richtlinie lebt auf dem Objekt, auf das zugegriffen wird, nicht auf der Identität, die den Zugriff durchführt. Ihr effektiver Zugriff zu jedem Zeitpunkt ist die Vereinigung jeder Bindung, die vom Root bis zu diesem Knoten vererbt wird. Gewähren Sie roles/compute.admin einer Gruppe auf Ordnerebene, und jedes Projekt unter diesem Ordner erbt diese.

Wenn Sie bereits mit Azure RBAC in Berührung gekommen sind, wird sich dies vertraut anfühlen - es ist eine Rolle mit einem bestimmten Geltungsbereich und absteigender Vererbung. Die Regel, die Sie rettet:

Wenn GCP etwas verweigert, hören Sie auf, nach „der Richtlinie für den Benutzer“ zu suchen. Suchen Sie nach der Bindung an der org, dem folder, dem project oder der resource - und denken Sie daran, dass sie nach unten vererbt wird, sodass die relevante Berechtigung drei Ebenen höher liegen kann.

Einige Besonderheiten, die sich von AWS unterscheiden:

• Rollen gibt es in drei Stufen. Primitive Rollen (roles/owner, roles/editor, roles/viewer) sind das grobe, veraltete Trio - vermeiden Sie sie in realen Umgebungen. Vordefinierte Rollen sind die feingranularen, dienstspezifischen Rollen, die Sie tatsächlich verwenden sollten (roles/storage.objectViewer, roles/compute.instanceAdmin.v1, ...). Benutzerdefinierte Rollen können Sie selbst erstellen, wenn der vordefinierte Satz zu breit ist.
• Das Basismodell ist additiv und nur erlaubend. Es gibt kein pro-Anweisung Effect: Deny, das in jede Richtlinie eingewoben ist, wie es in AWS der Fall ist. Der effektive Zugriff ist lediglich die Vereinigung von Erlaubnissen.
• Deny ist eine separate Ebene. Wenn Sie tatsächlich ein hartes „niemals, unabhängig von Berechtigungen“ benötigen, schreiben Sie eine IAM-Deny-Richtlinie - ein eigenständiges Objekt, das an org/folder/project angehängt ist und vor den Erlaubnissen ausgewertet wird. Es ist das Nächstbeste zu einer Inline-Deny-Anweisung, aber es ist bewusst außerhalb des Bandes.
• Guardrails sind noch eine dritte Sache: der Organization Policy Service. Constraints wie constraints/compute.vmExternalIpAccess oder constraints/iam.disableServiceAccountKeyCreation sind das GCP-Analogon zu SCPs. Sie werden an org/folder/project angehängt, vererben sich nach unten und beschränken, was existieren oder konfiguriert werden kann, anstatt wer was aufrufen kann. Denken Sie an „SCP-förmige Guardrail“, nicht an „IAM-Rolle“.

Wo AWS Ihnen also eine Erlaubnis-/Verweigerungsgrammatik innerhalb von IAM bietet, verteilt GCP die Aufgabe auf Erlaubnisbindungen, Deny-Richtlinien und Org-Richtlinien-Constraints. Gleiche Ergebnisse, drei Mechanismen.

Alles ist ein project - und seine APIs sind standardmäßig deaktiviert

Das project ist die grundlegende Einheit von GCP. Es ist das grobe Analogon eines AWS-account: eine Isolationsgrenze, ein IAM-Geltungsbereich und ein Abrechnungsziel zugleich. Aber ein project ist weitaus leichter als ein account - günstig zu erstellen, einfach zu löschen, dazu gedacht, dutzendfach erstellt zu werden. Das idiomatische Muster ist ein project pro Workload pro Umgebung (app-qa, app-prod), nicht eine Handvoll geteilter accounts, die durch Tags aufgeteilt werden.

Drei Dinge an projects haben kein sauberes AWS-Äquivalent:

• Ein project hat drei Identifikatoren, und die Unterschiede sind entscheidend. Die project ID ist eine global eindeutige, vom Menschen gewählte, unveränderliche Zeichenfolge (acme-app-prod-7f3a) - sie ist das, was Sie in fast jedem Befehl und Ressourcenpfad angeben. Die project number ist eine global eindeutige Ganzzahl, die GCP zuweist. Der display name ist veränderbar und kosmetisch. Wählen Sie die ID sorgfältig; Sie können sie niemals ändern.
• Service-APIs sind standardmäßig deaktiviert. Dies ist der häufigste Fehler am ersten Tag. Bevor Sie eine VM erstellen können, aktivieren Sie compute.googleapis.com; vor einem Bucket, storage.googleapis.com; und so weiter, pro project. Ihre erste „Ablehnung“ in GCP ist normalerweise überhaupt keine fehlende IAM-Rolle - es ist API [compute.googleapis.com] not enabled on project. In AWS sind Dienste einfach da; in GCP ist jedes project eine leere Leinwand, und Sie schalten genau die Oberfläche ein, die Sie verwenden möchten. (In Terraform ist dies google_project_service; über die CLI, gcloud services enable.)
• Projects sind die natürliche Blast-Radius- und Quota-Grenze. Quotas, Budgets und die meisten Standardwerte sind pro project, daher ist das Starten eines neuen project für ein Experiment der normale, kostengünstige Schritt - nicht die Zeremonie, die ein AWS-account darstellt.

Service Accounts: Sie imitieren, Sie übernehmen nicht

In AWS ist eine Rolle ein Satz von Berechtigungen, die ein Principal über STS übernimmt, gesteuert durch eine Trust Policy. In GCP ist das entsprechende Arbeitstier der Service Account (SA), und er funktioniert anders, was jeden AWS-Ingenieur stolpern lässt.

Ein Service Account ist sowohl eine Identität als auch eine Ressource. Er hat eine E-Mail (deployer@acme-app-prod.iam.gserviceaccount.com), er lebt innerhalb eines project, und - entscheidend - er hat seine eigene IAM-Richtlinie, die regelt, wer ihn verwenden darf. Diese zweite Hälfte ist der Teil ohne AWS-Reflex:

• Um als Service Account zu agieren, benötigt ein Principal eine Rolle auf dem SA selbst - roles/iam.serviceAccountTokenCreator (um kurzlebige Tokens zu prägen und ihn zu imitieren) oder roles/iam.serviceAccountUser (um ihn an eine Ressource anzuhängen, die Sie erstellen, wie eine VM oder einen Cloud Run-Dienst). Dies ist die zweiseitige Berechtigung, die AWS-Leute vergessen: Ihrem CI-Principal umfassende project-Rechte zu geben, ist nutzlos, wenn er nicht der Deployer-SA werden kann.
• Sie imitieren einen SA, indem Sie ein Token anfordern (generateAccessToken), nicht indem Sie eine Rolle mit einem Trust-Policy-Handshake übernehmen. Die Berechtigung zur Imitation existiert als gewöhnliche IAM-Bindung an der SA-Ressource - es gibt kein separates Trust-Dokument.
• Service Account Keys existieren, und Sie sollten sie größtenteils vermeiden. Ein heruntergeladener JSON-Key ist ein langlebiges Credential und ein klassischer Leak-Vektor; viele Orgs deaktivieren die Key-Erstellung organisationsweit über die zuvor erwähnte Constraint. Die schlüssellosen Alternativen sind die, nach denen Sie greifen sollten.
• Schlüssellose CI ist Workload Identity Federation - dieselbe OIDC-Idee wie die OIDC-Föderation von AWS. Ihre GitHub Actions oder externe Workload präsentiert ein OIDC-Token, ein Workload Identity Pool vertraut dem Aussteller, und GCP gibt kurzlebige Credentials für einen SA zurück. Kein gespeichertes Geheimnis. (Innerhalb von GKE ist das Analogon Workload Identity, das einen Kubernetes Service Account an einen Google Service Account bindet - das direkte Gegenstück zu AWS's IRSA.)

Die einzeilige Übersetzung: Eine AWS-Rolle, die Sie über eine Trust Policy übernehmen, wird zu einem GCP Service Account, den Sie über eine Token-Creator-Bindung am SA imitieren.

Die Identitätsdomäne: Cloud Identity, Workspace und die org

GCP trennt Identität von Ressourcen, aber weitaus sanfter als Azure. Der organization node wird gegen eine verifizierte Domain erstellt, die einem Cloud Identity- oder Google Workspace-Konto gehört. Dieses Verzeichnis - Benutzer und Gruppen - wird in der Admin-Konsole (admin.google.com) verwaltet, einer anderen Oberfläche als die Cloud-Konsole, in der Sie Ressourcen verwalten.

• Benutzer und Gruppen werden im Verzeichnis erstellt; der Zugriff wird in IAM gewährt. Sie erstellen keinen „GCP-Benutzer“ so, wie Sie einen IAM-Benutzer in AWS erstellen. Der Mensch existiert in Cloud Identity/Workspace (oder wird von Ihrem IdP föderiert), und Sie referenzieren ihn - idealerweise als Gruppe - in IAM-Bindungen am Ressourcenbaum. Best Practice sind Bindungen an Gruppen, niemals an einzelne Benutzer.
• Es gibt keinen eigenständigen „IAM users“-Speicher wie in AWS. Externe IdPs (Okta, Entra ID und so weiter) föderieren in Cloud Identity; das ist die Norm für den Workforce-Zugriff.
• Zwei Fallstricke, die man sich merken sollte: die speziellen Mitglieder allUsers (buchstäblich jeder im Internet, nicht authentifiziert) und allAuthenticatedUsers (jeder mit einem beliebigen Google-Konto). Eine Rolle an eines davon zu binden, führt dazu, dass Buckets versehentlich öffentlich werden. Behandeln Sie sie so, wie Sie einen Principal: "*" in einer S3-Bucket-Richtlinie behandeln würden.

Die lose Analogie: Der organization plus seine Cloud Identity-Domain ist ungefähr „eine AWS Organization, verschmolzen mit dem Verzeichnis von IAM Identity Center“ - aber die tägliche Ressourcenarbeit erfolgt über IAM-Bindungen am Baum, nicht über identitätsgebundene Richtlinien.

Billing ist ein separates Objekt, das Sie mit projects verknüpfen

Ein billing account in GCP ist eine eigene Ressource - es ist kein Knoten in der org -> folder -> project-Hierarchie. Projects verknüpfen sich mit einem billing account (jedes project mit genau einem), und ein einzelner billing account kann viele projects finanzieren.

• Es hat sein eigenes IAM. roles/billing.admin, roles/billing.user, roles/billing.creator leben auf dem billing account, getrennt von Ihren Ressourcenrollen. Insbesondere um ein neues project an einen billing account anzuhängen, benötigen Sie roles/billing.user auf diesem billing account - umfassende project-Rechte allein reichen nicht aus.
• „Ich kann deployen“ sagt nichts darüber aus, ob „ich ein kostenpflichtiges project erstellen kann.“ Um ein project zu erstellen, das Kosten verursachen kann, benötigen Sie sowohl resourcemanager.projectCreator (auf der org/dem folder) als auch billing.user (auf dem billing account). Wenn Sie das zweite verpassen, gelingt die project-Erstellung nur teilweise in ein project, das tatsächlich nichts ausführen kann.

Dies ist sanfter als die harte Commerce-Plane-Wand von Azure - GCP-Billing ist mit Cloud IAM verbunden, sodass es in denselben gcloud- und Terraform-Oberflächen erscheint, anstatt in einer völlig separaten Welt. Aber es ist immer noch ein eigenständiges Objekt mit eigenständigen Rollen, und es ist die zweithäufigste „aber ich bin Admin“-Überraschung nach nicht aktivierten APIs.

Namen, IDs und eine Netzwerk-Überraschung

Jede GCP-Ressource hat einen relativen Ressourcennamen wie projects/acme-app-prod/zones/us-central1-a/instances/web-1 (und eine vollqualifizierte //compute.googleapis.com/...-Form). Die project ID reist mit jeder Logzeile und jedem API-Aufruf - dieselbe Aufgabe, die ein ARN-Konto in AWS erfüllt - sodass, wie in Azure, Ihre Ressourcennamen weglassen können, was das project bereits kodiert. Dieselben Kurznamen können sicher über Ihre -dev-, -qa- und -prod-projects hinweg wiederholt werden.

Der Netzwerk-Fallstrick, der im Voraus erwähnt werden sollte, weil er stillschweigend AWS-Instinkte verletzt: Ein VPC-Netzwerk in GCP ist eine globale Ressource, und seine Subnetze sind regional. In AWS ist eine VPC auf eine Region beschränkt; in GCP erstreckt sich eine VPC über jede Region, und Sie schnitzen regionale Subnetze darin. Eine einzige globale VPC mit regionalen Subnetzen ist der Standard, keine exotische Multi-Region-Einrichtung - greifen Sie nicht zu VPC-Peering, um das zu tun, was ein Subnetz Ihnen bereits bietet.

Die AWS -> GCP Schnellübersicht

Behalten Sie dies im ersten Monat bei sich:

• Organization -> organization. Gleiche Idee, aber die GCP-org ist an Ihre Cloud Identity/Workspace-Domain gebunden.
• Organizational Unit (OU) -> folder. Verschachtelbarer Gruppierungsknoten; folders können folders enthalten.
• Account -> project. Die Isolations-, IAM- und Abrechnungseinheit - aber leichtgewichtig und wegwerfbar, dutzendfach erstellt.
• SCP (Guardrail) -> Organization Policy constraint im Geltungsbereich einer org/eines folder/eines project - beschränkt, was existieren oder konfiguriert werden kann, vererbt sich nach unten.
• IAM identity-attached policy -> IAM-Bindung (member, role) an einem Baumknoten. Keine Richtlinie für den Benutzer; die Berechtigung lebt auf der Ressource und vererbt sich nach unten.
• IAM-Rolle, die Sie übernehmen (über STS + Trust Policy) -> Service Account, den Sie imitieren (über eine Token-Creator-Bindung am SA). Denken Sie an die zweiseitige Berechtigung.
• Explizite Deny-Anweisung -> IAM-Deny-Richtlinie - ein separates Objekt, das vor den Erlaubnissen ausgewertet wird.
• IRSA (IAM Roles for Service Accounts) -> Workload Identity (GKE) / Workload Identity Federation (externe CI) - dieselbe OIDC-Idee, schlüssellos.
• „Der Dienst ist einfach verfügbar“ -> aktivieren Sie zuerst seine API pro project (google_project_service). Kein AWS-Äquivalent.
• ARN in Logs -> der Ressourcenname (projects/<id>/...); der project-Kontext ist strukturiert, nicht namenscodiert.

Bootstrapping des Terraform-States, übersetzt

Hier ist ein Bereich, in dem Ihr AWS-Runbook fast funktioniert, dann aber bei Schritt Null versagt.

Der AWS-Bootstrap, den Sie kennen: Kaltstart eines State-Backends im Management Account (lokaler State, dann Migration des Backends in sich selbst), Beibehaltung des States der pro-OU-Backends in diesem Root-Backend und Erstellung von Member Accounts mit ihren eigenen Backends. Die Invariante, die es sauber macht, ist, dass Sie immer vom Management Account aus bootstrappen können, weil er immer existiert und einen S3-Bucket halten kann.

GCP bricht diese Invariante bei der Entstehung auf dieselbe Weise wie Azure: Das immer existierende Objekt ist die organization, aber ein org-Knoten kann keine Ressourcen halten. Ein GCS-Bucket lebt in einem project, und ein project benötigt einen Parent und (um etwas Reales zu tun) eine Billing-Verknüpfung und aktivierte APIs. Daher ist GCPs „Root Account“ ein Seed-Project, das Sie bewusst krönen - der idiomatische Name ist so etwas wie prj-bootstrap oder ein Cloud Foundation Toolkit Seed Project.

Der übersetzte Ablauf, wenn die org und ein billing account bereits existieren (der häufigste Fall):

1. Einmaliger Kaltstart: Erstellen Sie das Seed-Project imperativ (gcloud projects create), aktivieren Sie die Bootstrap-APIs darauf (cloudresourcemanager, cloudbilling, serviceusage, iam, storage), verknüpfen Sie das Billing und erstellen Sie den GCS-State-Bucket mit lokalem Terraform-State - dann init -migrate-state in diesen Bucket.
2. Ein Bootstrap Service Account mit org-level Rollen: Gewähren Sie ihm resourcemanager.projectCreator, billing.user und Ihre org-policy/IAM-Admin-Rollen am organization node, damit er jedes nachgelagerte project erstellen und verwalten kann.
3. Alles andere ist ein normaler Apply: Zusätzliche projects, folders und ihre Ressourcen werden von Terraform erstellt, indem es diesen Bootstrap-SA imitiert, wobei der State jedes project unter einem prefix im einen GCS-Backend lebt.

Von Grund auf ist die Reihenfolge erzwungen - Seed-Project zuerst, State-Bucket zweitens -, weil ein Backend ein GCS-Bucket ist und ein Bucket ein project benötigt, um darin zu leben. Und es gibt eine kleine Henne-Ei-Problematik, genau wie bei Azure: Der google-Provider benötigt ein project und aktivierte APIs, um überhaupt etwas zu tun, also erstellen Sie dieses allererste project und aktivieren seine APIs mit einem imperativen gcloud-Aufruf, um es dann später in Terraform zu übernehmen. (Das Modul terraform-google-modules/bootstrap verpackt genau diesen Seed-Project-plus-SA-Tanz.)

Und hier ist GCP tatsächlich einfacher als das AWS-Muskelgedächtnis: Backend-in-Seed-Project plus Ressourcen-in-Member benötigt keine der AWS-Hub-and-Spoke-Vertrauensmechanismen - kein Backend role_arn, kein Provider assume_role, keine zweiseitigen Trust Policies. Ein org-level Service Account mit den richtigen Rollen funktioniert org-weit, weil IAM nach unten vererbt wird; der Provider „springt“ zwischen projects, indem er einfach project setzt; und er wird zur Deployer-Identität, indem er impersonate_service_account setzt. Cross-project ist ein Parameter, keine Vertrauensverhandlung. (Sie werden dies später mit benutzerdefinierten Rollen, pro-project SAs und dedizierten CI-Identitäten straffen - aber selbst dann sind es Rollenbindungen in Geltungsbereichen, niemals ein Trust-Policy-Handshake.) Wenn Sie sich intensiv mit der Kodifizierung einer der beiden Seiten befassen möchten, ist die Prüfung HashiCorp Terraform Authoring & Operations Pro genau auf diese State- und Provider-Muster aufgebaut.

Die vier Stellen, an denen Ihre AWS-Instinkte Sie aktiv in die Irre führen werden

Wenn Sie alles andere vergessen, merken Sie sich diese Punkte:

1. Es gibt keine Richtlinie für den Benutzer. Hören Sie auf, nach dem JSON zu suchen, das an eine Identität geheftet ist. Berechtigungen sind (member, role)-Bindungen an der org, dem folder, dem project oder der resource, und sie vererben sich nach unten. Die Berechtigung, die Sie benötigen, kann drei Ebenen höher liegen.
2. Nichts funktioniert, bis Sie die API aktivieren. Ihr erster 403-Fehler bei einem neuen project ist normalerweise API not enabled, nicht eine fehlende Rolle. Jeder Dienst ist deaktiviert, bis Sie ihn pro project einschalten.
3. Sie imitieren Service Accounts, Sie übernehmen keine Rollen. Und der SA ist eine Ressource mit seiner eigenen Zugriffsrichtlinie - Ihrem Principal umfassende project-Rechte zu geben, ist nutzlos ohne eine Token-Creator-Bindung am SA.
4. Billing ist ein separates Objekt. „Ich kann alles deployen“ sagt nichts darüber aus, ob „ich ein kostenpflichtiges project erstellen oder ein billing account verknüpfen kann.“ Andere Ressource, andere Rollen - billing.user auf dem billing account, nicht project admin.

Welche Zertifizierungen jede Seite vertiefen

Cloud-Governance - Hierarchie, Identität, Guardrails und State - ist das Rückgrat der Architektur- und Administrationsprüfungen in beiden Clouds, daher ist das Lernen dafür auch der schnellste Weg, die oben genannten Konzepte zu verinnerlichen. Wenn Sie bereits die AWS-Zertifizierung besitzen, ist die Google Cloud-Zertifizierung in derselben Reihe Ihr natürlicher nächster Schritt.

Auf der AWS-Seite (das Wissen, aus dem Sie übersetzen):

• AWS Certified Cloud Practitioner (CLF-C02) - die Grundlagen von accounts, IAM und Organizations.
• AWS Certified Solutions Architect - Associate (SAA-C03) - IAM, Multi-account-Struktur und Kernarchitektur.
• AWS Certified Solutions Architect - Professional (SAP-C02) - Multi-account Organizations, SCPs und Cross-account-Zugriff im großen Maßstab.
• AWS Certified Security - Specialty (SCS-C03) - IAM-Tiefe, SCPs und Schlüsselverwaltung.

Auf der Google Cloud-Seite (das Wissen, in das Sie übersetzen):

• Google Cloud Digital Leader - organizations, projects, IAM und Billing auf grundlegender Ebene.
• Google Cloud Associate Cloud Engineer - die tägliche Ebene: projects, IAM-Bindungen, Service Accounts und gcloud.
• Google Cloud Professional Cloud Architect - die org/folder/project-Hierarchie, Landing-Zone-Design und Governance im großen Maßstab.
• Google Cloud Professional Cloud Security Engineer - IAM-Tiefe, org policy, Service-Account-Sicherheit und Schlüsselverwaltung.

Ein pragmatischer Weg, wenn Sie heute AWS-zertifiziert sind: Beginnen Sie mit dem Cloud Digital Leader, um das Vokabular zu erfassen, springen Sie dann zum Associate Cloud Engineer (der in der project- und IAM-Ebene angesiedelt ist, die Sie am häufigsten verwenden werden), und fügen Sie den Professional Cloud Architect oder Professional Cloud Security Engineer hinzu, je nachdem, ob Ihre Arbeit eher auf Architektur oder Sicherheit ausgerichtet ist.

Das Fazit

GCP ist nicht schwieriger als AWS - es ist anders faktorisiert. AWS heftet Berechtigungen an Identitäten, gibt Ihnen ein schwergewichtiges account, bei dem alles eingeschaltet ist, und fasst die meiste Autorität in IAM zusammen. GCP hängt Berechtigungen an einen Ressourcenbaum, der nach unten vererbt wird, gibt Ihnen günstige, wegwerfbare projects, die als leere Leinwände beginnen, und lässt Sie Service Accounts imitieren, anstatt Rollen zu übernehmen. Übersetzen Sie die Konzepte einmal - Richtlinien wechseln von Identitäten zum Baum, accounts werden zu projects mit deaktivierten APIs, Rollen werden zu Service Accounts, die Sie imitieren, und Billing ist ein separates Objekt, das Sie verknüpfen - und der Rest ist Vokabular. Üben Sie es mit den oben genannten Zertifizierungen, und die Teile, die sich wie willkürliche Ablehnungen anfühlten, beginnen sich als kohärentes, bewusstes Design zu lesen.