GCP pour les ingénieurs AWS : comment vos instincts AWS se traduisent (et où ils échouent)

Si vous maîtrisez AWS et que vous vous penchez maintenant sur Google Cloud, la bonne nouvelle est qu'environ 80 % de vos instincts se transfèrent directement : il existe une hiérarchie pour organiser les choses, une méthode basée sur les rôles pour accorder l'accès, une approche OIDC pour le CI sans clé, et une danse d'amorçage pour "démarrer à froid votre state backend". La mauvaise nouvelle, ce sont les 20 % restants - et ils sont concentrés dans quelques zones très fréquentées où faire les choses à la manière d'AWS produit un refus déroutant plutôt qu'une erreur évidente. Cet article est la couche de traduction : les mêmes tâches que vous effectuez dans AWS, réalisées dans GCP, avec les pièges signalés.

En bref, si vous ne lisez qu'un seul paragraphe : la hiérarchie de GCP (organisation -> dossier -> projet -> ressource) se transpose clairement sur AWS Organizations -> OU -> compte -> ressource, mais trois choses brisent votre mémoire musculaire. IAM est une politique d'autorisation uniquement liée à l'arborescence des ressources et héritée vers le bas - il n'y a pas de politique attachée à un utilisateur. Les API de service d'un projet sont toutes désactivées au départ, et rien ne fonctionne tant que vous n'avez pas activé chacune d'elles. Et vous n'assumez pas de rôles, vous usurpez l'identité de comptes de service, qui sont eux-mêmes des ressources avec leur propre politique d'accès. Tout ce qui suit développe ces points.

Le plus grand changement : les permissions résident sur l'arborescence, pas sur les identités

Dans AWS, le modèle mental est "attacher une politique à une identité". Vous créez un utilisateur ou un rôle, y attachez du JSON, et la permission voyage avec le principal. Les politiques de ressources existent, mais la politique attachée à l'identité est le centre de gravité.

GCP inverse cela. Une politique IAM est un ensemble de liaisons - paires (member, role) - attachées à un nœud de la hiérarchie des ressources (organisation, dossier, projet ou une ressource individuelle). La politique réside sur la chose accédée, et non sur l'identité qui y accède. Votre accès effectif à tout moment est l'union de chaque liaison héritée de la racine jusqu'à ce nœud. Accordez roles/compute.admin à un groupe au niveau du dossier et chaque projet sous ce dossier l'hérite.

Si vous avez déjà utilisé Azure RBAC, cela vous semblera familier - c'est un rôle à portée avec héritage descendant. La règle qui vous sauve :

Lorsque GCP refuse quelque chose, arrêtez de chercher "la politique sur l'utilisateur". Cherchez la liaison sur l'organisation, le dossier, le projet ou la ressource - et rappelez-vous qu'elle hérite vers le bas, donc l'autorisation qui compte peut se trouver trois niveaux plus haut.

Quelques spécificités qui diffèrent d'AWS :

• Les rôles se déclinent en trois catégories. Les rôles primitifs (roles/owner, roles/editor, roles/viewer) sont le trio grossier hérité - évitez-les dans les environnements réels. Les rôles prédéfinis sont les rôles par service à grain fin que vous devriez réellement utiliser (roles/storage.objectViewer, roles/compute.instanceAdmin.v1, ...). Les rôles personnalisés sont les vôtres à créer lorsque l'ensemble prédéfini est trop large.
• Le modèle de base est additif et n'autorise que. Il n'y a pas de Effect: Deny par instruction intégré à chaque politique comme c'est le cas dans AWS. L'accès effectif est simplement l'union des autorisations.
• Le refus est une couche distincte. Lorsque vous avez réellement besoin d'un "jamais, quelles que soient les autorisations", vous écrivez une politique de refus IAM - un objet distinct attaché à l'organisation/dossier/projet qui est évalué avant les autorisations. C'est ce qui se rapproche le plus d'une instruction Deny en ligne, mais elle est délibérément hors bande.
• Les garde-fous sont une troisième chose : le service de politique d'organisation. Des contraintes comme constraints/compute.vmExternalIpAccess ou constraints/iam.disableServiceAccountKeyCreation sont l'analogue GCP des SCP. Elles s'attachent au niveau de l'organisation/dossier/projet, héritent vers le bas et restreignent ce qui peut exister ou être configuré plutôt que qui peut appeler quoi. Pensez "garde-fou en forme de SCP", pas "rôle IAM".

Ainsi, là où AWS vous offre une grammaire d'autorisation/refus unique au sein d'IAM, GCP répartit la tâche entre les liaisons d'autorisation, les politiques de refus et les contraintes de politique d'organisation. Mêmes résultats, trois mécanismes.

Tout est un projet - et ses API sont désactivées au départ

Le projet est l'unité fondamentale de GCP. C'est l'analogue approximatif d'un compte AWS : une limite d'isolation, une portée IAM et une cible de facturation, tout à la fois. Mais un projet est beaucoup plus léger qu'un compte - peu coûteux à créer, facile à supprimer, destiné à être créé par douzaines. Le modèle idiomatique est un projet par charge de travail par environnement (app-qa, app-prod), et non une poignée de comptes partagés découpés par des balises.

Trois choses concernant les projets n'ont pas d'équivalent clair dans AWS :

• Un projet a trois identifiants, et les différences sont importantes. L'ID de projet est une chaîne de caractères globalement unique, choisie par l'utilisateur, immuable (acme-app-prod-7f3a) - c'est ce que vous mettez dans presque toutes les commandes et chemins de ressources. Le numéro de projet est un entier globalement unique attribué par GCP. Le nom d'affichage est modifiable et cosmétique. Choisissez l'ID avec soin ; vous ne pourrez jamais le modifier.
• Les API de service sont désactivées par défaut. C'est l'erreur la plus courante le premier jour. Avant de pouvoir créer une VM, vous activez compute.googleapis.com ; avant un bucket, storage.googleapis.com ; et ainsi de suite, par projet. Votre premier "refus" sur GCP n'est généralement pas du tout un rôle IAM manquant - c'est API [compute.googleapis.com] not enabled on project. Dans AWS, les services sont simplement là ; dans GCP, chaque projet est une page blanche et vous activez exactement la surface que vous avez l'intention d'utiliser. (Dans Terraform, c'est google_project_service ; depuis la CLI, gcloud services enable.)
• Les projets sont la limite naturelle de rayon d'action et de quota. Les quotas, les budgets et la plupart des valeurs par défaut sont par projet, donc lancer un nouveau projet pour une expérience est la démarche normale et peu coûteuse - et non la cérémonie qu'est un compte AWS.

Comptes de service : vous usurpez l'identité, vous n'assumez pas de rôles

Dans AWS, un rôle est un ensemble de permissions qu'un principal assume via STS, régi par une politique de confiance. Dans GCP, le cheval de bataille équivalent est le compte de service (SA), et il fonctionne différemment d'une manière qui déroute tout ingénieur AWS.

Un compte de service est à la fois une identité et une ressource. Il a une adresse e-mail (deployer@acme-app-prod.iam.gserviceaccount.com), il réside à l'intérieur d'un projet, et - de manière cruciale - il a sa propre politique IAM régissant qui peut l'utiliser. Cette seconde partie est celle qui n'a pas de réflexe AWS :

• Pour agir en tant que compte de service, un principal a besoin d'un rôle sur le SA lui-même - roles/iam.serviceAccountTokenCreator (pour créer des jetons de courte durée et usurper son identité) ou roles/iam.serviceAccountUser (pour l'attacher à une ressource que vous créez, comme une VM ou un service Cloud Run). C'est l'autorisation à deux volets que les gens d'AWS oublient : donner à votre principal CI de larges droits de projet est inutile s'il ne peut pas devenir le SA de déploiement.
• Vous usurpez l'identité d'un SA en demandant un jeton (generateAccessToken), et non en assumant un rôle avec une poignée de main de politique de confiance. La permission d'usurper l'identité réside en tant que liaison IAM ordinaire sur la ressource SA - il n'y a pas de document de confiance séparé.
• Les clés de compte de service existent et vous devriez les éviter la plupart du temps. Une clé JSON téléchargée est une credential de longue durée et un vecteur de fuite classique ; de nombreuses organisations désactivent la création de clés à l'échelle de l'organisation via la contrainte mentionnée précédemment. Les alternatives sans clé sont celles à privilégier.
• Le CI sans clé est la fédération d'identité de charge de travail (Workload Identity Federation) - la même idée OIDC que la fédération OIDC d'AWS. Vos GitHub Actions ou votre charge de travail externe présente un jeton OIDC, un pool d'identité de charge de travail fait confiance à l'émetteur, et GCP renvoie des credentials de courte durée pour un SA. Aucun secret stocké. (À l'intérieur de GKE, l'analogue est Workload Identity, qui lie un compte de service Kubernetes à un compte de service Google - le pendant direct de l'IRSA d'AWS.)

La traduction en une ligne : un rôle AWS que vous assumez via une politique de confiance devient un compte de service GCP que vous usurpez via une liaison de créateur de jeton sur le SA.

Le domaine d'identité : Cloud Identity, Workspace et l'organisation

GCP sépare l'identité des ressources, mais de manière beaucoup plus douce qu'Azure. Le nœud d'organisation est créé par rapport à un domaine vérifié qui est détenu par un compte Cloud Identity ou Google Workspace. Ce répertoire - utilisateurs et groupes - est administré dans la console d'administration (admin.google.com), une interface différente de la console Cloud où vous gérez les ressources.

• Les utilisateurs et les groupes sont créés dans le répertoire ; l'accès est accordé dans IAM. Vous ne créez pas un "utilisateur GCP" de la même manière que vous créez un utilisateur IAM dans AWS. L'humain existe dans Cloud Identity/Workspace (ou est fédéré depuis votre IdP), et vous le référencez - idéalement en tant que groupe - dans les liaisons IAM sur l'arborescence des ressources. La meilleure pratique est de lier aux groupes, jamais aux utilisateurs individuels.
• Il n'y a pas de magasin "utilisateurs IAM" autonome comme celui d'AWS. Les IdP externes (Okta, Entra ID, etc.) se fédèrent dans Cloud Identity ; c'est la norme pour l'accès de la main-d'œuvre.
• Deux pièges à mémoriser : les membres spéciaux allUsers (littéralement n'importe qui sur Internet, non authentifié) et allAuthenticatedUsers (n'importe qui avec un compte Google). Lier un rôle à l'un ou l'autre est la façon dont les buckets deviennent accidentellement publics. Traitez-les comme vous traiteriez un Principal: "*" sur une politique de bucket S3.

L'analogie lâche : l'organisation plus son domaine Cloud Identity est à peu près "une organisation AWS fusionnée avec le répertoire d'IAM Identity Center" - mais le travail quotidien sur les ressources se fait via des liaisons IAM sur l'arborescence, et non via une politique attachée à l'identité.

La facturation est un objet distinct que vous liez aux projets

Un compte de facturation dans GCP est sa propre ressource - ce n'est pas un nœud dans la hiérarchie org -> dossier -> projet. Les projets se lient à un compte de facturation (chaque projet à un seul), et un seul compte de facturation peut financer de nombreux projets.

• Il a son propre IAM. roles/billing.admin, roles/billing.user, roles/billing.creator résident sur le compte de facturation, séparément de vos rôles de ressource. En particulier, pour attacher un nouveau projet à un compte de facturation, vous avez besoin de roles/billing.user sur ce compte de facturation - de larges droits de projet seuls ne suffiront pas.
• "Je peux déployer" ne dit rien sur "Je peux créer un projet facturable". Pour créer un projet qui peut entraîner des frais, vous avez besoin à la fois de resourcemanager.projectCreator (au niveau de l'organisation/dossier) et de billing.user (sur le compte de facturation). Manquez le second et la création du projet réussit à moitié, aboutissant à un projet qui ne peut en fait rien exécuter.

C'est plus souple que le mur rigide du plan commercial d'Azure - la facturation GCP est connectée à Cloud IAM, elle apparaît donc dans les mêmes interfaces gcloud et Terraform plutôt que dans un monde entièrement séparé. Mais c'est toujours un objet distinct avec des rôles distincts, et c'est la deuxième surprise la plus courante du "mais je suis un administrateur" après les API non activées.

Noms, ID et une surprise de mise en réseau

Chaque ressource GCP a un nom de ressource relatif comme projects/acme-app-prod/zones/us-central1-a/instances/web-1 (et une forme entièrement qualifiée //compute.googleapis.com/...). L'ID de projet accompagne chaque ligne de journal et chaque appel d'API - le même travail que le compte d'un ARN dans AWS - donc, comme dans Azure, vos noms de ressources peuvent omettre ce que le projet encode déjà. Les mêmes noms courts peuvent se répéter en toute sécurité dans vos projets -dev, -qa et -prod.

Le piège de la mise en réseau à signaler d'emblée, car il viole silencieusement les instincts AWS : un réseau VPC dans GCP est une ressource globale, et ses sous-réseaux sont régionaux. Dans AWS, un VPC est limité à une seule région ; dans GCP, un VPC s'étend sur toutes les régions, et vous y découpez des sous-réseaux régionaux. Un seul VPC global avec des sous-réseaux régionaux est la valeur par défaut, et non une configuration multi-régions exotique - ne cherchez pas le peering VPC pour faire ce qu'un sous-réseau vous offre déjà.

La carte rapide AWS -> GCP

Gardez ceci à portée de main pendant le premier mois :

• Organization -> organisation. Même idée, mais l'organisation GCP est liée à votre domaine Cloud Identity/Workspace.
• Organizational Unit (OU) -> dossier. Nœud de regroupement imbricable ; les dossiers peuvent contenir des dossiers.
• Account -> projet. L'unité d'isolation, IAM et de facturation - mais légère et jetable, créée par douzaines.
• SCP (garde-fou) -> Contrainte de politique d'organisation à l'échelle d'une organisation/dossier/projet - restreint ce qui peut exister ou être configuré, hérite vers le bas.
• Politique IAM attachée à l'identité -> Liaison IAM (member, role) sur un nœud d'arborescence. Pas de politique sur l'utilisateur ; l'autorisation réside sur la ressource et hérite vers le bas.
• Rôle IAM que vous assumez (via STS + politique de confiance) -> compte de service dont vous usurpez l'identité (via une liaison de créateur de jeton sur le SA). N'oubliez pas l'autorisation à deux volets.
• Instruction Deny explicite -> Politique de refus IAM - un objet distinct, évalué avant les autorisations.
• IRSA (IAM Roles for Service Accounts) -> Workload Identity (GKE) / Workload Identity Federation (CI externe) - la même idée OIDC, sans clé.
• "Le service est simplement disponible" -> activez d'abord son API par projet (google_project_service). Pas d'équivalent AWS.
• ARN dans les journaux -> le nom de la ressource (projects/<id>/...) ; le contexte du projet est structuré, non encodé dans le nom.

Initialisation de l'état Terraform, traduite

Voici un endroit où votre runbook AWS fonctionne presque, puis échoue à l'étape zéro.

L'amorçage AWS que vous connaissez : démarrer à froid un backend d'état dans le compte de gestion (état local, puis migrer le backend en lui-même), conserver l'état des backends par OU dans ce backend racine, et créer des comptes membres en utilisant leurs propres backends. L'invariant qui rend cela propre est que vous pouvez toujours amorcer depuis le compte de gestion, car il existe toujours et peut contenir un bucket S3.

GCP rompt cet invariant à la genèse de la même manière qu'Azure : l'objet qui existe toujours est l'organisation, mais un nœud d'organisation ne peut pas contenir de ressources. Un bucket GCS réside dans un projet, et un projet a besoin d'un parent et (pour faire quoi que ce soit de réel) d'un lien de facturation et d'API activées. Ainsi, le "compte racine" de GCP est un projet de démarrage que vous couronnez consciemment - le nom idiomatique est quelque chose comme prj-bootstrap ou un projet de démarrage Cloud Foundation Toolkit.

Le flux traduit, lorsque l'organisation et un compte de facturation existent déjà (le cas courant) :

1. Un seul démarrage à froid, pour toujours : créez le projet de démarrage de manière impérative (gcloud projects create), activez les API d'amorçage dessus (cloudresourcemanager, cloudbilling, serviceusage, iam, storage), liez la facturation, et créez le bucket d'état GCS avec l'état Terraform local - puis init -migrate-state dans ce bucket.
2. Un compte de service d'amorçage avec des rôles au niveau de l'organisation : accordez-lui resourcemanager.projectCreator, billing.user, et vos rôles d'administrateur de politique d'organisation/IAM au niveau du nœud d'organisation, afin qu'il puisse créer et gouverner chaque projet en aval.
3. Tout le reste est une application normale : les projets, dossiers et leurs ressources supplémentaires sont créés par Terraform en usurpant l'identité de ce SA d'amorçage, l'état de chaque projet résidant sous un prefix dans le backend GCS unique.

À partir de zéro, l'ordre est forcé - projet de démarrage d'abord, bucket d'état ensuite - car un backend est un bucket GCS et un bucket a besoin d'un projet pour exister. Et il y a une petite complexité de l'œuf et de la poule, tout comme celle d'Azure : le fournisseur google a besoin d'un projet et d'API activées pour faire quoi que ce soit, vous créez donc ce tout premier projet et activez ses API avec un appel gcloud impératif, puis vous l'adoptez dans Terraform par la suite. (Le module terraform-google-modules/bootstrap encapsule exactement cette danse projet de démarrage plus SA.)

Et voici où GCP est véritablement plus simple que la mémoire musculaire AWS : le backend dans le projet de démarrage plus les ressources dans le membre n'ont besoin d'aucune des machineries de confiance en étoile d'AWS - pas de role_arn de backend, pas de assume_role de fournisseur, pas de politiques de confiance bilatérales. Un compte de service au niveau de l'organisation avec les bons rôles fonctionne à l'échelle de l'organisation car IAM hérite vers le bas ; le fournisseur "saute" entre les projets en définissant simplement project ; et il devient l'identité du déployeur en définissant impersonate_service_account. Le cross-projet est un paramètre, pas une négociation de confiance. (Vous affinerez cela plus tard avec des rôles personnalisés, des SA par projet et des identités CI dédiées - mais même alors, ce sont des liaisons de rôles à des portées, jamais une poignée de main de politique de confiance.) Si vous voulez approfondir la codification de l'un ou l'autre côté, l'examen HashiCorp Terraform Authoring & Operations Pro est construit autour de ces mêmes modèles d'état et de fournisseur.

Les quatre points où vos instincts AWS vous induiront activement en erreur

Si vous oubliez tout le reste, souvenez-vous de ceci :

1. Il n'y a pas de politique sur l'utilisateur. Arrêtez de chercher le JSON agrafé à une identité. Les permissions sont des liaisons (member, role) sur l'organisation, le dossier, le projet ou la ressource, et elles héritent vers le bas. L'autorisation dont vous avez besoin peut se trouver trois niveaux plus haut.
2. Rien ne fonctionne tant que vous n'avez pas activé l'API. Votre premier 403 sur un nouveau projet est généralement API not enabled, et non un rôle manquant. Chaque service est désactivé jusqu'à ce que vous l'activiez, par projet.
3. Vous usurpez l'identité de comptes de service, vous n'assumez pas de rôles. Et le SA est une ressource avec sa propre politique d'accès - donner à votre principal de larges droits de projet est inutile sans une liaison de créateur de jeton sur le SA.
4. La facturation est un objet distinct. "Je peux déployer n'importe quoi" ne dit rien sur "Je peux créer un projet facturable ou lier un compte de facturation". Ressource différente, rôles différents - billing.user sur le compte de facturation, pas administrateur de projet.

Quelles certifications couvrent chaque aspect

La gouvernance du cloud - hiérarchie, identité, garde-fous et état - est l'épine dorsale des examens d'architecture et d'administration sur les deux clouds, donc les étudier est aussi le moyen le plus rapide de faire en sorte que les concepts ci-dessus s'ancrent. Si vous détenez déjà la certification AWS, celle de Google Cloud sur la même ligne est votre prochaine étape naturelle.

Du côté AWS (les connaissances à partir desquelles vous traduisez) :

• AWS Certified Cloud Practitioner (CLF-C02) - les fondations des comptes, IAM et Organizations.
• AWS Certified Solutions Architect - Associate (SAA-C03) - IAM, structure multi-comptes et architecture de base.
• AWS Certified Solutions Architect - Professional (SAP-C02) - Organizations multi-comptes, SCP et accès inter-comptes à l'échelle.
• AWS Certified Security - Specialty (SCS-C03) - Profondeur IAM, SCP et gestion des clés.

Du côté Google Cloud (les connaissances vers lesquelles vous traduisez) :

• Google Cloud Digital Leader - organisations, projets, IAM et facturation au niveau fondamental.
• Google Cloud Associate Cloud Engineer - le plan quotidien : projets, liaisons IAM, comptes de service et gcloud.
• Google Cloud Professional Cloud Architect - la hiérarchie org/dossier/projet, la conception de zones d'atterrissage et la gouvernance à l'échelle.
• Google Cloud Professional Cloud Security Engineer - Profondeur IAM, politique d'organisation, sécurité des comptes de service et gestion des clés.

Un chemin pragmatique si vous êtes certifié AWS aujourd'hui : commencez par le Cloud Digital Leader pour cartographier le vocabulaire, puis passez à l'Associate Cloud Engineer (qui se situe dans le plan projet et IAM que vous utiliserez le plus), et ajoutez le Professional Cloud Architect ou le Professional Cloud Security Engineer selon que votre travail penche vers l'architecture ou la sécurité.

Le mot de la fin

GCP n'est pas plus difficile qu'AWS - il est factorisé différemment. AWS attache les permissions aux identités, vous donne un compte lourd avec tout activé, et intègre la plupart de l'autorité dans IAM. GCP accroche les permissions à une arborescence de ressources qui hérite vers le bas, vous donne des projets jetables et bon marché qui commencent comme des pages blanches, et vous fait usurper l'identité de comptes de service au lieu d'assumer des rôles. Traduisez les concepts une fois - les politiques passent des identités à l'arborescence, les comptes deviennent des projets avec leurs API désactivées, les rôles deviennent des comptes de service dont vous usurpez l'identité, et la facturation est un objet distinct que vous liez - et le reste est du vocabulaire. Entraînez-vous avec les certifications ci-dessus, et les parties qui semblaient être des refus arbitraires commenceront à être lues comme une conception cohérente et délibérée.