Structurer votre entreprise sur Google Cloud Platform

• Assurez-vous d'un alignement organisationnel
• Choisissez votre propre parcours
• Mettez en place les identités via des groupes et rôles utilisateurs
• Centralisez vos réseaux avec des Shared VPC
• Planifiez l'ensemble de vos ressources
• Taguez vos ressources pour un meilleur reporting
• Configurez des alertes budgétaires
• Organisez vos dépôts de code source pour l'IaC
• Configurez des alertes de sécurité et de monitoring
• Utilisez un bastion (jump host)
• Protégez vos données
• Utilisez Cloud Security Command Center
• Documentez et testez vos plans de reprise et de continuité d'activité
• Associez-vous à des experts qui l'ont déjà fait

Bien que cet article se concentre sur les fonctionnalités de Google Cloud Platform (GCP), je m'en voudrais de ne pas saluer le CEO d'AWS, Andy Jassy, qui a élégamment résumé quatre clés de la réussite d'une transformation cloud, et oserais-je dire de toute initiative :

1. Conviction et alignement de l'équipe de direction
2. Objectifs ambitieux portés par le sommet
3. Formez vos builders
4. Ne laissez pas la paralysie [par l'analyse] vous bloquer avant même de commencer

Mon mantra personnel quand j'essaie quelque chose de nouveau : d'abord, faire que ça marche, ensuite faire que ce soit bien fait, puis faire que ce soit rapide.

Google met à disposition d'excellentes ressources en ligne sur les bonnes pratiques pour les entreprises, ainsi que l'illustration ci-dessous présentant les étapes recommandées pour des Secure Google Cloud Services. Les besoins varient d'une organisation à l'autre : cette feuille de route est donc un excellent point de départ pour planifier votre infrastructure ou découvrir ce qui est disponible.

Source : Google

Démarrez avec une politique de moindre privilège et désactivez immédiatement la possibilité de créer des projets au niveau de l'organisation. Seuls les DevOps, la facturation et les OrgAdmins devraient avoir cette capacité, idéalement via un seul compte de service côté DevOps dédié à votre automatisation d'infrastructure (par exemple Terraform). Dans la mesure du possible, n'ajoutez pas d'individus à votre IAM.

• Organization Administrators ([email protected])
• Network Administrators ([email protected])
• Security Administrators ([email protected])
• Billing Administrators ([email protected])
• DevOps ([email protected])
• Development ([email protected])
• DataScience ([email protected]) [optionnel]

Une fois ces groupes créés, éventuellement avec Cloud Identity (en vous connectant à votre AD ou IdP existant) ou dans votre organisation GSuite, ajoutez au moins une personne par groupe. Attribuez ensuite les rôles nécessaires uniquement au besoin à chaque groupe, soit au niveau Organisation, soit au niveau Folder.

Source : Google

Si vous suivez l'approche GitOps, les équipes de développement peuvent déployer leurs workloads* dans les namespaces de cluster Kubernetes correspondants via des pipelines CI/CD depuis le contrôle de source. Cette approche facilite la gestion des accès et des quotas, et donc le contrôle des coûts cloud et la budgétisation.

*uniquement les binaires approuvés issus d'un dépôt d'images privé de confiance

Dans les secteurs fortement régulés ou pour maintenir une conformité de type SOC 2, vos contrôles peuvent imposer une stricte séparation des responsabilités. Une pratique courante en entreprise consiste à séparer la gestion du réseau de celle des DevOps et du développement applicatif. GCP simplifie tout cela grâce à son Shared VPC et à son élégante hiérarchie de projets, à savoir les host et service projects.

Concevez et planifiez votre réseau pour éviter les collisions, et supprimez tous les réseaux par défaut au sein des projets — vous me remercierez plus tard !

Comme indiqué, il s'agit d'une approche assumée ; la vôtre peut différer. La bonne pratique que je recommande est d'encapsuler vos service projects dans un host project et de centraliser votre configuration réseau en un seul endroit, en n'accordant l'accès à ces projets qu'au groupe des administrateurs réseau.

Pour l'allocation des IP de vos sous-réseaux, selon votre échelle et vos prévisions de croissance, une plage CIDR /16 pour un VPC devrait amplement suffire (65 000 adresses). Kubernetes, en revanche, requiert un grand nombre d'IP pour les services et les pods, ces derniers se voyant attribuer dynamiquement des IP pour des conteneurs éphémères. Je suggère de réserver une plage supplémentaire inutilisée pour les IP secondaires, comme ci-dessous :

• sous-réseau dans la plage /16 du VPC : k8s-nodes-prod (10.10.0.0/22)

secondaire : k8s-services-prod (10.80.64.0/22)

secondaire : k8s-pods-prod (10.80.0.0/18)

sous-réseau : bastion-prod (10.10.64.0/29)

• sous-réseau dans la plage /16 du VPC : k8s-nodes-stage (10.11.0.0/22)

secondaire : k8s-services-stage (10.81.64.0/22)

secondaire : k8s-pods-stage (10.81.0.0/18)

sous-réseau : bastion-stage (10.11.64.0/29)

• sous-réseau dans la plage /16 du VPC : k8s-nodes-demo (10.12.0.0/22)

secondaire : k8s-services-demo (10.82.64.0/22)

secondaire : k8s-pods-demo (10.82.0.0/18)

sous-réseau : bastion-demo (10.12.64.0/29)

• sous-réseau dans la plage /16 du VPC : k8s-nodes-qa (10.13.0.0/22)

secondaire : k8s-services-qa (10.83.64.0/22)

secondaire : k8s-pods-qa (10.83.0.0/18)

sous-réseau : bastion-qa (10.13.64.0/29)

• sous-réseau dans la plage /16 du VPC : k8s-nodes-dev (10.14.0.0/22)

secondaire : k8s-services-dev (10.84.64.0/22)

secondaire : k8s-pods-dev (10.84.0.0/18)

sous-réseau : bastion-dev (10.14.64.0/29)

Cela laisse amplement d'espace dans votre VPC pour des sous-réseaux supplémentaires destinés à des serveurs de bases de données ou à d'autres ressources.

Google Cloud Platform organise les ressources par organisation, folder et projet. La gestion des utilisateurs et des groupes s'en trouve simplifiée, sans la folie multi-comptes qu'on connaît sur d'autres plateformes. Beaucoup d'entreprises ayant adopté le cloud très tôt sont coincées à construire des solutions sur mesure pour gérer ce désordre de comptes et de permissions, véritable cauchemar pour la sécurité et la conformité — GCP, lui, a vu juste.

├── DevOps
│   └── project-devops
│       ├── bucket-terraform-state
│       ├── cluster-devops
│       │   ├── namespace-cicd
│       │   └── namespace-vault
│       ├── sink-application-logs
│       └── sink-audit-logs
├── RnD
│   ├── Non-Production
│   │   └── project-shared-network-nonprod
│   │       ├── sink-application-logs
│   │       ├── sink-audit-logs
│   │       ├── vpc-demo-10-12-0-0
│   │       │   └── project-demo
│   │       │       ├── cluster-demo
│   │       │       │   ├── namespace-team1
│   │       │       │   ├── namespace-team2
│   │       │       │   └── namespace-vault
│   │       │       ├── sink-application-logs
│   │       │       └── sink-audit-logs
│   │       ├── vpc-dev-10-14-0-0
│   │       │   └── project-development
│   │       │       ├── cluster-development
│   │       │       │   ├── namespace-team1
│   │       │       │   ├── namespace-team2
│   │       │       │   └── namespace-vault
│   │       │       ├── sink-application-logs
│   │       │       └── sink-audit-logs
│   │       └── vpc-qa-10-13-0-0
│   │           └── project-development
│   │               └── cluster-qa
│   │                   ├── namespace-team1
│   │                   ├── namespace-team2
│   │                   └── namespace-vault
│   ├── Production
│   │   └── project-shared-network-prod
│   │       ├── sink-application-logs
│   │       ├── sink-audit-logs
│   │       ├── vpc-prod-10-10-0-0
│   │       │   └── project-production
│   │       │       ├── cluster-production
│   │       │       │   ├── namespace-team1
│   │       │       │   ├── namespace-team2
│   │       │       │   └── namespace-vault
│   │       │       ├── sink-application-logs
│   │       │       └── sink-audit-logs
│   │       └── vpc-stage-10-11-0-0
│   │           └── project-stage
│   │               ├── cluster-stage
│   │               │   ├── namespace-team1
│   │               │   ├── namespace-team2
│   │               │   └── namespace-vault
│   │               ├── sink-application-logs
│   │               └── sink-audit-logs
│   └── project-monitoring
│       ├── bucket-development-logs
│       ├── bucket-production-logs
│       ├── workspace-development
│       └── workspace-production
└── Security
    └── project-security
        └── bucket-audit-logs

L'un des défis les plus fréquents et l'une des principales sources de confusion avec les clouds publics concerne la facturation, le reporting et le contrôle des coûts. Une façon de maîtriser vos coûts consiste à concevoir votre infrastructure avec des namespaces par équipe, comme illustré plus haut. Cela accélère l'onboarding et la productivité des développeurs, en évitant une courbe d'apprentissage trop raide ou un vivier de talents trop restreint. Autre bonne pratique : taguer vos ressources (tags/labels) pour pouvoir mettre en place ensuite des alertes, budgets et rapports.

Un de mes collègues a écrit un article à ce sujet : Auto Tagging Google Cloud Resources, à partir de notre outil open source IRIS. De nombreux autres articles existent sur le sujet ; pensez à planifier vos tags en amont pour vous épargner bien des migraines plus tard.

Tags suggérés par ressource :

• Owner — qui en est actuellement responsable (peut avoir changé d'équipe)
• Creator — qui l'a créée à l'origine (utile pour des questions ultérieures)
• Project — par exemple my-company-production, pour un meilleur regroupement
• Working Hours — économisez jusqu'à 60 % en planifiant automatiquement vos ressources de dev avec Zorya

Beaucoup de CFO redoutent le cloud à cause du manque de visibilité et du risque de dépenses sans fin liées à une mauvaise configuration. Avec les alertes budgétaires, vous suivez la dépense quotidienne et réagissez rapidement pour aligner vos dépenses cloud sur les revenus de l'entreprise. Il est judicieux de partager les informations de coûts avec vos équipes et d'inviter les responsables à se réunir régulièrement pour suivre le budget.

Une fois votre plan de hiérarchie des ressources défini, vous vous retrouvez face à un dilemme de la poule et de l'œuf. Faut-il tout provisionner avec Terraform, et si oui, comment Terraform obtient-il les permissions nécessaires pour tout construire ? La suggestion : votre Org Admin crée le folder et le projet DevOps, et votre équipe DevOps crée un Terraform Service Account avec les permissions nécessaires pour créer/supprimer des projets, etc. Commencez par le strict minimum et, à mesure que vous rencontrez des erreurs, ajoutez les rôles requis.

L'un de mes collègues a écrit un excellent article, Refactoring Terraform The Right Way, en phase avec les recommandations de l'équipe d'experts de Gruntwork.io, créateurs de Terragrunt. En résumé : séparez vos ressources, services et environnements live dans trois dépôts distincts, et gérez les permissions de groupes via votre contrôle de source en conséquence.

Le monitoring et l'alerting devraient être au premier plan de votre processus de planification, et heureusement de nombreuses fonctionnalités intégrées de Google Cloud Platform facilitent cette tâche. Le scan des CIS benchmarks dans Cloud Security Command Center (CSCC), présenté ci-dessous, détecte les éléments de monitoring manquants et fournit des instructions étape par étape pour configurer correctement chaque projet. Plus d'informations sur le CSCC ci-dessous.

Pour plus de commodité, voici un Gist des configurations de monitoring recommandées.

J'ai omis les VM des bastion hosts dans le diagramme ci-dessus pour des raisons de simplicité, mais la bonne pratique pour un accès sécurisé consiste à les utiliser. Je suggère d'ajouter une plage de sous-réseau par projet pour une VM bastion, d'éliminer toutes les IP externes et de configurer des clusters privés. Créez un managed instance group d'une seule instance pour que GCP en relance une nouvelle en cas de défaillance. Vous pouvez vous connecter au bastion via VPN ou, approche plus moderne et plus sécurisée, via Cloud Identity Aware Proxy (IAP). Vous pouvez encore renforcer votre bastion en restreignant les clés SSH des utilisateurs.

Source : Google

Il existe de nombreux articles sur les bonnes pratiques Kubernetes, mais celui des Engineers de Google, Completely Private GKE Clusters With No Internet Connectivity, est une bonne référence et confirme la structure de base proposée ci-dessus.

Vous devez planifier et concevoir votre infrastructure pour respecter les politiques définies par l'équipe sécurité de votre organisation, ce qui inclut souvent différents niveaux de chiffrement. Les ressources GCP sont chiffrées au repos par défaut, mais vous devez identifier vos besoins en clés de chiffrement (managées par Google, auto-managées, BYOK) au repos comme en transit.

Vous pouvez aussi vouloir isoler les accès aux données au sein de votre organisation, jusqu'au niveau des individus ou des applications. C'est possible avec les VPC Service Controls, comme illustré ci-dessous.

Si vous expédiez des logs ou des données pour le monitoring, comme illustré dans l'exemple de hiérarchie de ressources, vous pouvez configurer vos log sinks pour exploiter les API Cloud Data Loss Prevention (Cloud DLP) et retirer près de 100 types de données PII avant le stockage.

Une pépite méconnue de GCP : Cloud Security Command Center. Ce produit offre une vue unifiée pour la gestion des actifs, la détection des menaces et anomalies, le WAF et le scan de vulnérabilités. À mon sens, le scan est l'une des fonctionnalités les plus intéressantes : vous pouvez configurer quels projets scanner, mais vous ne pouvez pas contrôler quand le scan a lieu (1 à 2 fois par jour). Il met en évidence les violations des CIS et NIST benchmarks pour chaque projet et chaque ressource, avec une remédiation pas à pas.

À noter : la nouvelle tarification divisera le CSCC en deux niveaux (gratuit, premium).

Cloud Security Command Center — source wideops.com

• Excellente ressource et checklist : les CIS Benchmarks for Google Cloud — il en existe aussi des spécifiques pour Kubernetes et d'autres systèmes, le tout gratuitement.

Il existe d'autres excellents outils tiers comme Forseti Security et Prisma Cloud de Palo Alto Networks pour scanner et aider à optimiser vos configurations et déploiements de code (anciennement les outils Twistlock et Redlock).

Cela va sans dire, mais vous devez disposer d'un plan automatisé de sauvegarde et de restauration pour l'ensemble de vos données, qu'elles soient dans des buckets ou des bases de données. Testez le processus de sauvegarde et de restauration au moins une fois par an, et idéalement plus souvent.

Pour la continuité d'activité et la tranquillité d'esprit, il est vivement recommandé de définir votre infrastructure as code (IaC) avec Terraform. Si votre équipe est rigoureuse dans la gestion de l'état de votre infrastructure as code, vous pourrez facilement produire des rapports d'audit pour la conformité et vous remettre d'une défaillance majeure.

Je n'ai fait qu'effleurer les éléments clés à considérer lors d'une transformation cloud d'entreprise, et cela peut sembler vertigineux ; la meilleure chose à faire reste tout simplement de commencer. Je suis peut-être partial, mais le deuxième meilleur réflexe pour maximiser vos chances de succès est de vous associer à des professionnels qui l'ont déjà fait des dizaines de fois.

DoiT International a accompagné des milliers d'entreprises dans leur parcours cloud, avec des revues d'architecture, du support expert et des outils sur mesure de budgétisation et de reporting cloud — le tout sans coût supplémentaire pour nos clients (nous sommes partenaire revendeur cloud). Notre objectif est de faire monter en compétence vos équipes et de leur donner les moyens de gérer avec succès leur infrastructure cloud, et lorsque c'est nécessaire, nous sommes toujours là pour vous.

Vous voulez plus d'articles de Mike ? Consultez notre blog sur Medium, ou suivez Mike sur Twitter.