Google Cloud Platform

Ton CV montre un projet GCP (Penpot). L'entretien va vérifier que tu comprends le modèle de sécurité et le réseau, pas que tu connais les 200 services par cœur.

Hiérarchie des ressources

Organization (renault.com)
└── Folders (ex : digital-backbone, prod, non-prod)
    └── Projects (ex : dbb-kafka-prod)
        └── Ressources (VM, buckets, topics...)

Le projet est l'unité de facturation, de quotas et d'isolation. Il a un ID unique et immuable.
Les politiques IAM s'héritent de haut en bas. Un rôle donné au folder s'applique à tous ses projets. On ne peut pas retirer plus bas un droit donné plus haut (sauf avec les deny policies, plus récentes).
Les Organization Policies imposent des contraintes globales : interdire les IP publiques sur les VM, restreindre les régions autorisées, interdire la création de clés de comptes de service.

IAM

Un binding IAM = qui (principal) + quel rôle + sur quelle ressource.

Principaux : compte Google, groupe Google, compte de service, domaine, identité fédérée.

Types de rôles :

Type	Exemple	Usage
Basique	`roles/owner`, `roles/editor`, `roles/viewer`	À éviter en prod, beaucoup trop larges
Prédéfini	`roles/compute.instanceAdmin.v1`, `roles/storage.objectViewer`	Le choix normal
Custom	défini par l'entreprise	Quand aucun prédéfini ne colle au moindre privilège

Bonne pratique : donner les rôles à des groupes, pas à des personnes. Quand quelqu'un change d'équipe, on le retire du groupe.

Comptes de service

Une identité pour une application ou une VM, pas pour un humain.

Chaque VM tourne avec un compte de service. Celui par défaut (Compute Engine default) a le rôle Editor : à remplacer par un compte dédié avec le minimum.
Clés JSON : des identifiants longue durée. C'est le principal risque de fuite sur GCP. À éviter autant que possible.
Impersonation : un humain ou un autre compte obtient des tokens courts d'un compte de service via le rôle roles/iam.serviceAccountTokenCreator. Pas de clé à stocker.

Workload Identity Federation

Permet à une identité externe (GitLab CI, GitHub Actions, AWS) d'obtenir un accès GCP temporaire sans clé JSON.

Le principe avec GitLab :

GitLab génère un token OIDC signé pour le job (id_tokens dans .gitlab-ci.yml).
Ce token contient des claims : projet, branche, environnement.
GCP vérifie la signature via le pool et le provider configurés, et peut filtrer sur ces claims (par exemple « seulement la branche main du projet infra »).
GCP échange le token contre un accès court à un compte de service.

deploy:
  id_tokens:
    GITLAB_OIDC_TOKEN:
      aud: https://iam.googleapis.com/projects/123/locations/global/workloadIdentityPools/gitlab/providers/gitlab
  script:
    - echo "$GITLAB_OIDC_TOKEN" > token.txt
    - gcloud iam workload-identity-pools create-cred-config ... --credential-source-file=token.txt --output-file=creds.json
    - gcloud auth login --cred-file=creds.json

C'est LA bonne réponse à « comment ton pipeline s'authentifie sur GCP ? ».

Workload Identity pour GKE : même idée côté Kubernetes. Un compte de service Kubernetes est associé à un compte de service GCP, les pods obtiennent des tokens sans clé montée en secret.

Réseau (VPC)

Différence majeure avec AWS : le VPC GCP est global. Les sous-réseaux sont régionaux. Une VM à Paris et une à Francfort dans le même VPC communiquent en IP privée sans peering.

Mode auto : un subnet créé dans chaque région. Mode custom : on choisit. En entreprise, toujours custom.
Règles de pare-feu : définies au niveau du VPC, appliquées aux VM via des network tags ou des comptes de service (plus sûr, car un tag se modifie facilement). Par défaut : tout le sortant autorisé, tout l'entrant refusé.
Shared VPC : un projet hôte possède le réseau, des projets de service y déploient leurs ressources. Le standard dans les grandes entreprises : l'équipe réseau garde la main sur le VPC.
VPC Peering : relie deux VPC. Non transitif (A-B et B-C ne donnent pas A-C).
Cloud NAT : sortie Internet pour les VM sans IP publique. Ne permet pas d'entrer.
Private Google Access : une VM sans IP publique peut joindre les API Google (Storage, Pub/Sub...).
Cloud VPN / Interconnect : lien avec les datacenters de l'entreprise.

Accéder à une VM sans IP publique

IAP TCP forwarding (Identity-Aware Proxy) : Google vérifie ton identité et ton rôle IAM, puis tunnelise la connexion. Il faut autoriser la plage 35.235.240.0/20 en entrée sur le port 22.

gcloud compute ssh ma-vm --zone europe-west9-a --tunnel-through-iap

OS Login : les accès SSH sont gérés par IAM (roles/compute.osLogin, roles/compute.osAdminLogin) au lieu de clés posées dans les métadonnées. Révocation immédiate quand quelqu'un part.

Compute

Service	Quoi	Quand
Compute Engine	VM	Contrôle total de l'OS, logiciels classiques, brokers auto-gérés
MIG (Managed Instance Group)	Groupe de VM identiques issues d'un instance template	Autoscaling, autohealing via health check, rolling updates
GKE	Kubernetes managé	Conteneurs à l'échelle. Mode Autopilot (Google gère les nœuds) ou Standard
Cloud Run	Conteneurs serverless	Services HTTP sans état, facturés à l'usage
Cloud Functions	Fonctions	Petits traitements déclenchés par événement

Régions et zones : europe-west9 = Paris, europe-west1 = Belgique, europe-west4 = Pays-Bas. Une zone = un datacenter (europe-west9-a). La haute dispo se fait en répartissant sur plusieurs zones.

Stockage et données

Cloud Storage : objets dans des buckets. Classes Standard, Nearline (accès mensuel), Coldline (trimestriel), Archive (annuel). Lifecycle rules pour passer automatiquement d'une classe à l'autre ou supprimer. Versioning pour se protéger des suppressions. C'est là qu'on met le state Terraform.
Persistent Disk : disques des VM, avec snapshots.
Cloud SQL : PostgreSQL ou MySQL managé, HA régionale, sauvegardes automatiques.
BigQuery : entrepôt de données analytique.

Messaging : Pub/Sub

Le service de messaging managé de Google, lien direct avec le Digital Backbone.

Un topic reçoit les messages des publishers.
Une ou plusieurs subscriptions sur ce topic. Chaque subscription reçoit une copie de chaque message.
Mode pull (le consommateur demande) ou push (Pub/Sub appelle un endpoint HTTP).
Le consommateur doit acquitter (ack) chaque message, sinon il est redistribué après l'ack deadline.
Dead letter topic pour les messages qui échouent trop de fois.
Rétention configurable, rejeu possible via seek.

Différence avec Kafka : pas de partitions à gérer, pas de cluster. En échange, moins de contrôle fin.

Observabilité

Cloud Logging : logs centralisés, requêtes, sinks vers BigQuery ou Storage. Les audit logs (Admin Activity, toujours actifs) disent qui a fait quoi.
Cloud Monitoring : métriques, dashboards, uptime checks, alerting.
L'Ops Agent sur les VM remonte logs et métriques système.

Secret Manager

echo -n "s3cr3t" | gcloud secrets create db-password --data-file=-
gcloud secrets versions add db-password --data-file=nouveau.txt
gcloud secrets versions access latest --secret=db-password

Les secrets sont versionnés, l'accès est contrôlé par IAM (roles/secretmanager.secretAccessor), chaque lecture est tracée dans les audit logs.

Commandes gcloud utiles

gcloud config list
gcloud config set project mon-projet
gcloud auth list
gcloud compute instances list
gcloud compute instances describe ma-vm --zone europe-west9-a
gcloud projects get-iam-policy mon-projet
gcloud iam service-accounts list
gcloud logging read 'severity>=ERROR' --limit 20 --freshness 1h
gcloud pubsub topics list

Questions d'entretien à préparer

Comment ton pipeline GitLab s'authentifie-t-il sur GCP ? (Workload Identity Federation)
Pourquoi éviter les clés de comptes de service ?
Différence entre un VPC GCP et un VPC AWS ? (global vs régional)
Comment accéder en SSH à une VM sans IP publique ? (IAP, OS Login)
Comment garantir qu'une VM n'a jamais d'IP publique dans toute l'organisation ? (Organization Policy compute.vmExternalIpAccess)
Une VM sans IP publique doit télécharger des paquets. Comment ? (Cloud NAT)
Différence entre MIG et GKE ?
Comment tu choisis entre Pub/Sub et un Kafka auto-géré sur Compute Engine ?