Guide

Appliquer des garde-fous préventifs au sein d'une organisation, comme la restriction des emplacements de ressources ou la désactivation de la création de clés de compte de service.

→Appliquer des contraintes de politique d'organisation (par exemple, `constraints/gcp.resourceLocations`, `constraints/iam.disableServiceAccountKeyCreation`) au niveau de l'organisation ou du dossier.

Pourquoi: Les politiques d'organisation sont héritées et appliquées au niveau de l'API, empêchant les actions non conformes avant qu'elles ne se produisent. C'est plus efficace que la détection et la correction réactives.

Référence↗

Structurer une organisation multi-département, multi-environnement pour gérer efficacement les politiques et le contrôle d'accès.

→Concevoir une hiérarchie de dossiers, typiquement : Organisation > Unité Commerciale (Dossier) > Environnement (par exemple, prod, staging) (Sous-dossier) > Projets.

Pourquoi: Cette structure permet une héritabilité granulaire des politiques. Les politiques communes sont définies au niveau de l'unité commerciale, tandis que les politiques spécifiques à l'environnement (par exemple, plus restrictives pour `prod`) sont définies au niveau de l'environnement.

Regrouper les journaux de tous les projets pour la conformité, l'analyse de sécurité et le dépannage opérationnel avec optimisation des coûts.

→Créer un collecteur de journaux agrégé au niveau de l'organisation. Acheminer les journaux vers plusieurs destinations en fonction des besoins : BigQuery pour l'analyse, Cloud Storage (Coldline/Archive) pour l'archivage à long terme/à faible coût, et Pub/Sub pour le streaming en temps réel vers un SIEM.

Pourquoi: Cette approche échelonnée optimise à la fois les coûts et les capacités. BigQuery offre des capacités de requête puissantes, tandis que Cloud Storage propose un archivage bon marché. L'utilisation d'une seule destination est soit trop chère, soit pas assez performante pour tous les cas d'utilisation.

Référence↗

Prévenir l'exfiltration de données depuis des services gérés comme BigQuery et Cloud Storage, en n'autorisant l'accès qu'à partir de réseaux ou d'identités autorisés.

→Créer un périmètre VPC Service Controls autour des projets contenant des données sensibles. Définir des niveaux d'accès pour autoriser l'accès depuis des plages IP spécifiques (réseau d'entreprise) ou des appareils.

Pourquoi: VPC Service Controls crée un périmètre virtuel autour des services basés sur API, atténuant les risques liés aux identifiants volés ou aux politiques IAM mal configurées en bloquant l'accès depuis l'extérieur du périmètre.

Établir des garde-fous de sécurité qui ne peuvent pas être outrepassés par les propriétaires de projets, comme empêcher l'octroi d'un rôle spécifique.

→Implémenter des politiques de refus IAM au niveau de l'organisation ou du dossier. Ces politiques refusent explicitement les autorisations et annulent toujours toutes les politiques d'`autorisation`.

Pourquoi: Les politiques de refus offrent un moyen puissant d'appliquer des contrôles de sécurité à l'échelle de l'organisation qui ne peuvent pas être contournés aux niveaux inférieurs de la hiérarchie des ressources, garantissant une posture de sécurité cohérente.

S'assurer que tous les nouveaux projets sont provisionnés avec une configuration de base standard (mise en réseau, IAM, journalisation, etc.).

→Utiliser l'Infrastructure as Code (par exemple, Terraform avec Cloud Build) pour créer une "zone d'atterrissage". Automatiser la création et la configuration des projets via un pipeline.

Pourquoi: L'automatisation assure la cohérence, réduit les erreurs manuelles et accélère le provisionnement des projets. Elle codifie les meilleures pratiques, rendant la gouvernance auditable et reproductible.

Permettre aux systèmes externes (comme GitHub Actions ou CI/CD sur site) d'accéder aux ressources GCP sans utiliser de clés de compte de service de longue durée.

→Configurer la Workload Identity Federation. Créer un fournisseur qui fait confiance à l'IdP externe (par exemple, GitHub OIDC) et mapper les identités externes à un compte de service GCP. Utiliser des conditions d'attribut pour restreindre l'accès à des dépôts/branches spécifiques.

Pourquoi: Cela élimine la nécessité de gérer et de faire pivoter les clés de compte de service, ce qui constitue un risque de sécurité majeur. Cela fournit des identifiants éphémères basés sur l'identité.

Centraliser l'administration réseau (VPC, sous-réseaux, pare-feu) tout en permettant à des équipes distinctes de gérer leurs propres ressources de projet.

→Mettre en œuvre Shared VPC. Créer un "projet hôte" pour les ressources réseau et des "projets de service" pour les charges de travail applicatives. Accorder `roles/compute.networkUser` aux identités des projets de service.

Pourquoi: Shared VPC découple l'administration réseau de l'administration des projets, offrant un contrôle centralisé et une sécurité tout en donnant de l'autonomie aux équipes. Il évolue mieux et est plus sécurisé que VPC Peering pour ce cas d'utilisation.

Gérer les configurations de cluster GKE et les applications de manière déclarative à partir d'un dépôt Git.

→Utiliser un dépôt Git comme source unique de vérité pour les manifestes. Installer Config Sync dans les clusters GKE pour réconcilier en continu l'état du cluster avec la configuration du dépôt.

Pourquoi: GitOps offre un moyen auditable, versionné et automatisé de gérer Kubernetes. Il sépare l'intégration continue (construction d'artefacts) du déploiement continu (synchronisation de l'état).

Empêcher le déploiement d'images de conteneurs présentant des vulnérabilités critiques.

→Activer l'analyse automatique des vulnérabilités dans Artifact Registry. Dans le pipeline Cloud Build, ajouter une étape qui utilise l'API Container Analysis pour vérifier les vulnérabilités et faire échouer la build si des problèmes critiques sont détectés.

Pourquoi: Cela crée une porte de qualité automatisée dans le pipeline CI, empêchant les artefacts vulnérables d'atteindre un état déployable. Cela déplace la sécurité vers la gauche.

Appliquer à l'exécution que seules les images de conteneurs fiables et signées peuvent être déployées sur GKE ou Cloud Run.

→Implémenter Binary Authorization. Créer des certificateurs (par exemple, pour la réussite des analyses de vulnérabilité, l'approbation QA). Configurer le pipeline CI pour créer des attestations. Appliquer une politique sur GKE/Cloud Run qui exige des attestations spécifiques pour le déploiement.

Pourquoi: Binary Authorization offre une application forte basée sur des politiques au moment du déploiement. Il protège contre le déploiement d'images compromises ou non vérifiées, même si elles parviennent dans le registre.

Référence↗

Accéder à des informations sensibles comme des clés API ou des mots de passe lors d'une exécution Cloud Build sans les exposer dans les journaux ou le code source.

→Stocker les secrets dans Secret Manager. Dans le `cloudbuild.yaml`, utiliser le champ `availableSecrets` pour monter le secret en tant que variable d'environnement ou fichier.

Pourquoi: C'est l'intégration native et sécurisée. Cloud Build gère l'authentification et masque automatiquement les valeurs secrètes des journaux, empêchant ainsi toute exposition accidentelle.

Établir une chaîne de traçabilité vérifiable pour les artefacts logiciels afin de garantir qu'ils ont été construits par un système de confiance à partir d'un code source de confiance.

→Utiliser Cloud Build pour générer des attestations de provenance conformes à SLSA. Stocker ces attestations dans Artifact Registry aux côtés des images. Utiliser Binary Authorization pour vérifier la provenance avant le déploiement.

Pourquoi: SLSA fournit un cadre pour renforcer la chaîne d'approvisionnement logicielle. Cette combinaison d'outils offre une chaîne de confiance vérifiable de bout en bout, de la source à la production.

Exécuter des tâches CI/CD qui nécessitent d'accéder à des ressources dans un VPC privé, comme un Artifact Registry privé ou une base de données Cloud SQL.

→Créer un pool privé Cloud Build et configurer le peering VPC entre le réseau du pool et votre VPC cible. Configurer les builds pour qu'elles s'exécutent dans ce pool.

Pourquoi: Les pools privés offrent une isolation réseau et permettent aux builds d'accéder en toute sécurité aux ressources d'un réseau privé sans les exposer à Internet.

Supprimer automatiquement les images de conteneurs anciennes ou inutilisées pour gérer les coûts de stockage tout en conservant les images importantes.

→Configurer les politiques de nettoyage d'Artifact Registry. Utiliser une politique de `conservation` pour les tags comme `production` et `latest`. Utiliser des politiques de `suppression` basées sur l'âge, les modèles de tags et le nombre de versions pour les autres images.

Pourquoi: Les politiques de nettoyage offrent un moyen déclaratif et automatisé de gérer le cycle de vie des images, en équilibrant les économies de coûts avec la nécessité de conserver les artefacts de production et de développement récents.

Automatiser un déploiement multi-étapes du développement à la pré-production et à la production avec des approbations et différentes stratégies par environnement.

→Définir un pipeline de livraison Cloud Deploy unique avec une progression de cibles (dev, staging, prod). Configurer `requireApproval: true` pour la cible de production et spécifier différentes stratégies de déploiement (par exemple, canary) pour chaque cible.

Pourquoi: Cloud Deploy fournit un service de livraison continue géré et auditable. Il simplifie les modèles de livraison progressive comme les déploiements canary et bleu-vert avec des approbations et des retours arrière intégrés.

Définir des métriques pour mesurer la fiabilité d'un service du point de vue de l'utilisateur.

→Définir des indicateurs de niveau de service (SLI) basés sur les préoccupations de l'utilisateur : disponibilité (pourcentage de requêtes réussies), latence (pourcentage de requêtes plus rapides qu'un seuil), et exactitude/fraîcheur (pourcentage de données traitées correctement ou à jour).

Pourquoi: Les SLI doivent mesurer la satisfaction de l'utilisateur, et non la santé interne du serveur. Des métriques comme l'utilisation du CPU sont des causes, tandis qu'une latence élevée est un symptôme. L'ingénierie de la fiabilité des sites (SRE) se concentre sur la surveillance et la gestion des symptômes.

Être averti des violations de SLO suffisamment tôt pour réagir, sans être inondé d'alertes pour des problèmes mineurs et transitoires.

→Configurer des alertes basées sur le taux de consommation du SLO (la vitesse à laquelle le budget d'erreur est consommé). Utiliser des alertes multi-fenêtres : un taux de consommation élevé sur une courte période pour les pages critiques, et un taux de consommation plus faible sur une longue période pour les tickets non urgents.

Pourquoi: L'alerte par taux de consommation est prédictive. Elle alerte sur le *taux* de défaillance, ce qui indique un problème réel, plutôt que sur une seule requête échouée, réduisant la fatigue d'alerte et se concentrant sur ce qui compte.

Référence↗

Diagnostiquer les problèmes de latence dans une architecture de microservices en comprenant le cycle de vie complet d'une requête.

→Instrumenter les services avec les SDK OpenTelemetry et exporter les traces vers Cloud Trace. S'assurer que le contexte de trace est propagé à travers les appels de service (y compris via les files d'attente de messages comme Pub/Sub).

Pourquoi: OpenTelemetry fournit une norme neutre vis-à-vis des fournisseurs pour l'instrumentation. Cloud Trace visualise le flux de requête de bout en bout, facilitant l'identification du service ou de l'opération constituant le goulot d'étranglement.

S'assurer que les journaux d'application dans GKE sont correctement analysés, interrogeables et ont le bon niveau de gravité dans Cloud Logging.

→Configurer les applications pour écrire les journaux sur `stdout`/`stderr` au format JSON. Inclure un champ `severity` qui correspond aux valeurs attendues par Google Cloud (par exemple, "INFO", "ERROR").

Pourquoi: L'agent de journalisation par défaut de GKE récupère et analyse automatiquement les journaux JSON de stdout, les rendant structurés et interrogeables dans Cloud Logging sans nécessiter de sidecar ou d'agent personnalisé.

Suivre, visualiser et alerter sur la conformité SLO et la consommation du budget d'erreur pour un service.

→Utiliser la fonctionnalité de surveillance de service de Cloud Monitoring. Définir un service, créer des SLI (par exemple, disponibilité à partir d'un équilibreur de charge), définir des cibles SLO et configurer des politiques d'alerte de taux de consommation.

Pourquoi: Cette fonctionnalité native automatise les calculs complexes de conformité SLO et de budgets d'erreur, fournit des tableaux de bord prêts à l'emploi et s'intègre au système d'alerte.

Trouver rapidement la cause profonde d'un problème en liant les métriques, les traces et les journaux.

→S'assurer que les identifiants de trace sont inclus dans les journaux structurés. Utiliser les fonctionnalités de Cloud Monitoring comme les exemplaires de trace sur les graphiques de métriques pour sauter à une trace spécifique lors d'une anomalie métrique, puis de cette trace, sauter aux journaux corrélés.

Pourquoi: La capacité de pivoter de manière transparente entre les trois piliers de l'observabilité (métriques, journaux, traces) est essentielle pour réduire le temps moyen de résolution (MTTR).

Créer des métriques et des alertes personnalisées pour des événements spécifiques à l'application qui ne sont disponibles que dans les données de journal, comme les inscriptions d'utilisateurs ou les échecs de paiement.

→Dans Cloud Logging, créer une métrique basée sur les journaux. Définir un filtre pour correspondre aux entrées de journal pertinentes et configurer le type de métrique (compteur ou distribution). Utiliser cette métrique personnalisée dans les tableaux de bord et les politiques d'alerte.

Pourquoi: Les métriques basées sur les journaux permettent de transformer des données de journal non structurées ou semi-structurées en données de séries temporelles structurées, ce qui facilite la surveillance et l'alerte sur les KPI au niveau métier sans modifier le code de l'application.

Diagnostiquer les problèmes de performance de la base de données, tels que les requêtes lentes, sans ajouter de charge à la base de données.

→Activer Cloud SQL Insights et Query Insights sur l'instance Cloud SQL. Utiliser le tableau de bord pour identifier les requêtes à forte charge, analyser les plans d'exécution et voir les tendances de performance.

Pourquoi: Query Insights offre une surveillance légère et sans agent des performances des requêtes. Il aide les administrateurs de bases de données et les développeurs à identifier les requêtes inefficaces sans la surcharge des outils de profilage traditionnels.

Surveiller de manière proactive les parcours utilisateur critiques ou la disponibilité des API depuis une perspective externe.

→Utiliser les vérifications de disponibilité de Cloud Monitoring pour de simples vérifications HTTP/TCP. Pour les flux utilisateur multi-étapes (par exemple, connexion, ajout au panier, paiement), utiliser les moniteurs synthétiques, qui exécutent des scripts personnalisés (par exemple, Puppeteer) dans un environnement géré.

Pourquoi: La surveillance synthétique simule les interactions réelles des utilisateurs, ce qui permet de détecter les problèmes avant les utilisateurs. Elle teste l'ensemble de la pile de l'extérieur vers l'intérieur.

Équilibrer le besoin de fiabilité du service avec la nécessité de publier de nouvelles fonctionnalités.

→Définir un objectif de niveau de service (SLO) (par exemple, 99,9 % de disponibilité). Les 0,1 % restants constituent le budget d'erreur. Si le budget est majoritairement intact, livrer des fonctionnalités. Si le budget est épuisé, suspendre les livraisons de fonctionnalités et se concentrer sur les améliorations de la fiabilité.

Pourquoi: Le budget d'erreur fournit un cadre basé sur les données pour prendre des décisions de risque, alignant les équipes d'ingénierie, de produit et commerciales sur un objectif commun.

Apprendre des incidents pour éviter qu'ils ne se reproduisent, tout en favorisant une culture de sécurité psychologique.

→Mener des post-mortems non-blâmantes après les incidents. Concentrer l'enquête sur les facteurs systémiques, les lacunes des processus et les défaillances des outils, et non sur l'attribution de la faute à des individus. Le résultat devrait être une liste d'éléments d'amélioration actionnables.

Pourquoi: Une culture non-blâmante encourage une communication honnête et ouverte, menant à une compréhension plus précise des causes profondes d'un incident et à des actions préventives plus efficaces.

Coordonner efficacement la réponse à un incident majeur, en évitant la confusion et la duplication des efforts.

→Mettre en œuvre un système de commandement des incidents (ICS) avec des rôles clairement définis : Commandant d'incident (coordination générale), Responsable des opérations (enquête/correction technique) et Responsable des communications (mises à jour des parties prenantes).

Pourquoi: L'ICS fournit une structure standardisée et évolutive pour la réponse aux incidents, garantissant des lignes d'autorité et de communication claires, ce qui est crucial pour résoudre rapidement les problèmes complexes.

Mesurer la performance d'une organisation de livraison de logiciels.

→Suivre les quatre métriques DORA clés : Fréquence de déploiement (à quelle fréquence), Délai de mise en production (rapidité du commit au déploiement), Taux d'échec des changements (quel pourcentage de déploiements provoque des échecs) et Temps de restauration de service (MTTR).

Pourquoi: Ces quatre métriques offrent une vue équilibrée de la vélocité de développement et de la stabilité opérationnelle, et il a été prouvé qu'elles sont corrélées avec les organisations très performantes.

Une équipe SRE passe trop de temps sur des tâches opérationnelles manuelles et répétitives (toil), ne laissant pas de temps pour les projets d'ingénierie.

→Identifier et quantifier le toil le plus chronophage. Prioriser et automatiser ces tâches (par exemple, implémenter l'autoscaling au lieu de la mise à l'échelle manuelle, l'auto-remédiation pour les alertes courantes). Limiter le toil à < 50 % du temps d'ingénieur.

Pourquoi: Le toil est un frein à la productivité et au moral. Le réduire systématiquement par l'automatisation libère les ingénieurs pour travailler sur des améliorations de la fiabilité à long terme.

Attribuer les coûts cloud avec précision à différentes équipes, services ou environnements dans une infrastructure partagée.

→Implémenter une stratégie de labellisation/tagging cohérente. Utiliser ces labels pour filtrer dans les rapports de facturation Cloud. Pour GKE, activer l'allocation des coûts GKE pour ventiler les coûts par namespace ou charge de travail.

Pourquoi: Une allocation précise des coûts offre de la visibilité, ce qui favorise la responsabilisation. Les équipes qui peuvent voir leurs dépenses sont habilitées à les optimiser.

Optimiser les coûts de calcul pour un ensemble diversifié de charges de travail (stables, interruptibles, dev/test).

→Faire correspondre la charge de travail au modèle de tarification. Utiliser les remises pour engagement d'utilisation (CUDs) pour les charges de travail stables 24h/24 et 7j/7. Utiliser les VM Spot pour les tâches tolérantes aux pannes et interruptibles (par exemple, le traitement par lots). Planifier l'arrêt des environnements de développement/test en dehors des heures ouvrables.

Pourquoi: Une approche unique pour la tarification du calcul est inefficace. Utiliser le bon outil pour la tâche peut entraîner des économies importantes (>70 %) sans impacter les performances.

Optimiser les coûts et les performances de GKE en s'assurant que les pods demandent des quantités appropriées de CPU et de mémoire.

→Déployer le Vertical Pod Autoscaler (VPA) en mode `recommendation`. Analyser ses suggestions pour ajuster les `requests` de ressources des pods. Une fois confiant, passer en mode `auto` pour un redimensionnement continu.

Pourquoi: Le sur-provisionnement des pods gaspille de l'argent, tandis que le sous-provisionnement entraîne des problèmes de performance (étranglement, OOMKilled). Le VPA utilise les données d'utilisation réelles pour faire des recommandations de dimensionnement précises, améliorant à la fois l'efficacité et la stabilité.

Réduire la latence causée par les démarrages à froid pour un service Cloud Run.

→Configurer une valeur `min-instances` pour maintenir un certain nombre d'instances chaudes. De plus, optimiser l'image du conteneur (image de base plus petite, moins de couches) et le code de démarrage de l'application (initialisation paresseuse).

Pourquoi: `min-instances` est le moyen le plus direct de réduire les démarrages à froid, mais cela a un coût. Le combiner avec l'optimisation du conteneur et du code offre une approche équilibrée de la performance et du coût.

Optimiser les coûts pour une charge de travail d'analyse BigQuery à grande échelle avec des modèles de requêtes variables.

→Passer de la tarification à la demande aux éditions BigQuery (slots). Acheter un engagement de slots de base pour une charge prévisible et activer l'autoscaling pour les pics. De plus, optimiser les requêtes en utilisant des tables partitionnées/clusterisées et en évitant `SELECT *`.

Pourquoi: Pour les charges de travail cohérentes, la tarification basée sur les slots est plus rentable que la tarification à la demande. L'autoscaling offre une flexibilité pour les pics tout en contrôlant les coûts. L'optimisation des requêtes et des tables réduit la quantité de données traitées, diminuant directement les coûts.

Réduire les coûts élevés de sortie réseau pour une application distribuée mondialement.

→Utiliser Cloud CDN pour mettre en cache le contenu statique en périphérie, plus près des utilisateurs. Pour le trafic dynamique, choisir le niveau de service réseau approprié (Premium pour les performances, Standard pour les économies de coûts). Traiter les données régionalement pour minimiser le trafic inter-régions.

Pourquoi: La sortie est un facteur de coût majeur. Le CDN décharge le trafic de l'origine, réduisant directement la sortie. Une utilisation judicieuse des niveaux de réseau et du traitement régional des données peut réduire considérablement les coûts.