GitOps, Policy as Code et gouvernance du cycle de déploiement

Extrait du mémoire de Master 2 Cybersécurité et Cloud de Holali David GAVI — Partie 6/6.

6.1 Principes GitOps et réconciliation continue

Le GitOps, terme forgé par Alexis Richardson (Weaveworks, 2017), représente un paradigme opérationnel où Git est la source unique de vérité (single source of truth) pour l’état déclaratif de l’infrastructure et des applications. Le principe central est la réconciliation continue : un agent dans le cluster compare en permanence l’état réel du cluster avec l’état désiré décrit dans Git, et corrige automatiquement toute dérive (drift).

OpenGitOps (CNCF, 2022) formalise quatre principes fondamentaux :

• Déclaratif — L’état complet du système est décrit de manière déclarative (YAML, HCL, JSON)
• Versionné et immuable — L’état désiré est stocké dans un système de contrôle de version (Git), créant un historique immuable et auditable
• Tiré automatiquement (Pull-based) — Les agents tirent l’état désiré depuis Git, plutôt que de pousser les changements (push). Ce modèle élimine le besoin d’accès direct au cluster depuis les pipelines CI
• Réconcilié en continu — Les agents détectent et corrigent automatiquement les dérives entre l’état réel et l’état désiré

L’avantage sécuritaire du modèle pull est significatif : le pipeline CI n’a plus besoin de credentials d’accès au cluster Kubernetes. Seul l’agent GitOps (ArgoCD/Flux), déployé à l’intérieur du cluster, dispose des permissions nécessaires. Cela réduit drastiquement la surface d’attaque — une compromission du serveur CI ne donne plus accès au cluster de production (Limoncelli et al., 2020).

6.2 ArgoCD et Flux en pratique

ArgoCD (Intuit, CNCF graduated) est la solution GitOps la plus adoptée, avec plus de 16 000 étoiles GitHub et une adoption par 60% des organisations utilisant GitOps (CNCF Survey, 2024). Son architecture repose sur trois composants principaux :

• Application Controller — Surveille les Applications (CRD) et compare l’état réel avec l’état Git. Détecte les dérives et déclenche la synchronisation.
• Repo Server — Clone les dépôts Git, génère les manifests finaux (Helm template, Kustomize build, plain YAML) et les transmet au controller.
• API Server — Expose l’API REST et le dashboard web. Gère l’authentification (OIDC, LDAP, SAML) et les RBAC ArgoCD (distinct du RBAC Kubernetes).

Le pattern App of Apps est la pratique recommandée pour les déploiements à grande échelle : une Application ArgoCD racine pointe vers un répertoire Git contenant les définitions de toutes les autres Applications. Ajouter un nouveau service au cluster revient à ajouter un fichier YAML dans ce répertoire et créer une Pull Request (ArgoCD Documentation, 2024).

Les ApplicationSets étendent ce modèle avec des générateurs dynamiques : un seul template peut générer des Applications pour chaque cluster, chaque namespace ou chaque entrée dans une liste. Le générateur git crée automatiquement une Application pour chaque répertoire dans un dépôt — idéal pour le multi-tenancy.

Flux (Weaveworks, CNCF graduated) adopte une approche plus modulaire avec des contrôleurs spécialisés :

• Source Controller — Gère les sources (GitRepository, HelmRepository, OCIRepository, Bucket)
• Kustomize Controller — Applique les manifests Kustomize et les YAML bruts
• Helm Controller — Gère les HelmReleases (installation, upgrade, rollback automatique)
• Notification Controller — Envoie des alertes (Slack, Teams, webhook) et reçoit des webhooks (GitHub, GitLab) pour déclencher la réconciliation

Le choix entre ArgoCD et Flux dépend du contexte : ArgoCD offre un dashboard web riche et une gestion visuelle des Applications, adapté aux équipes qui préfèrent une interface graphique. Flux est plus léger, entièrement CLI/YAML-driven, et s’intègre mieux dans les workflows automatisés où l’interface web n’est pas nécessaire (Weaveworks, 2023).

6.3 Policy as Code

Le Policy as Code applique les principes de l’IaC aux politiques de sécurité, de conformité et de gouvernance : les règles sont définies dans du code versionné, testées automatiquement et appliquées systématiquement. Cette approche remplace les documents de politique statiques (souvent obsolètes et ignorés) par des contrôles automatisés et auditables.

OPA (Open Policy Agent), projet CNCF graduated, est un moteur de politique généraliste. Les politiques sont écrites en Rego, un langage déclaratif conçu pour interroger des structures de données JSON. Dans Kubernetes, Gatekeeper expose OPA comme admission controller via des CRD :

• ConstraintTemplate — Définit un type de politique réutilisable (ex: « les containers doivent avoir des resource limits »)
• Constraint — Instancie un ConstraintTemplate avec des paramètres spécifiques (ex: « CPU limit ≤ 4, memory limit ≤ 8Gi »)

OPA/Gatekeeper opère en mode deny (bloque les requêtes non conformes) ou warn (alerte sans bloquer, utile pour la phase d’adoption). L’audit mode vérifie rétroactivement les ressources existantes et signale les violations.

Kyverno — Alternative à OPA native Kubernetes, créée par Nirmata. Les politiques sont écrites en YAML standard plutôt qu’en Rego, ce qui réduit significativement la barrière d’entrée. Kyverno offre trois types d’actions :

• Validate — Vérifie qu’une ressource respecte une politique (ex: label obligatoire, image provenant d’un registre approuvé)
• Mutate — Modifie automatiquement une ressource (ex: ajouter un sidecar, injecter des labels par défaut, définir des resource limits manquants)
• Generate — Crée des ressources associées (ex: créer automatiquement un NetworkPolicy pour chaque nouveau namespace)

Crossplane (Upbound, CNCF incubating) étend le modèle déclaratif Kubernetes à l’infrastructure cloud externe. Les ressources cloud (RDS, S3, VPC, IAM) sont représentées comme des CRD Kubernetes et gérées par des contrôleurs de réconciliation. Les Compositions permettent de créer des abstractions de haut niveau (« un environnement de dev = 1 VPC + 1 cluster EKS + 1 instance RDS + 1 bucket S3 ») exposées aux développeurs comme un simple YAML à appliquer (Crossplane Documentation, 2024).

6.4 Multi-tenancy et isolation dans Kubernetes

Le multi-tenancy — l’hébergement de plusieurs équipes, projets ou clients sur un même cluster Kubernetes — est un enjeu économique (mutualisation des ressources, réduction des coûts opérationnels) et un défi de sécurité (isolation entre locataires). Le SIG Multi-Tenancy de Kubernetes (2024) distingue deux modèles :

Soft multi-tenancy — Isolation logique via les namespaces, RBAC, Network Policies et Resource Quotas. Les tenants se font confiance mutuellement (équipes internes d’une même organisation). Ce modèle repose sur la configuration correcte de Kubernetes — une erreur de RBAC peut exposer les données d’un tenant à un autre.

Hard multi-tenancy — Isolation forte avec des mécanismes additionnels : runtime sandboxé (gVisor, Kata Containers), nœuds dédiés par tenant, chiffrement des données par tenant, audit logging séparé. Nécessaire quand les tenants ne se font pas confiance (SaaS multi-client, clusters partagés entre organisations).

Le projet vCluster (Loft Labs) crée des clusters virtuels à l’intérieur d’un cluster hôte. Chaque tenant reçoit son propre API server, son propre etcd et sa propre vue du cluster — avec une isolation quasi complète tout en partageant l’infrastructure physique. Les virtual clusters s’intègrent avec ArgoCD pour un déploiement GitOps par tenant.

Les Hierarchical Namespaces (HNC), développés par le SIG Multi-Tenancy, permettent de créer des hiérarchies de namespaces : un namespace parent « team-a » peut avoir des sous-namespaces « team-a-dev », « team-a-staging », « team-a-prod » qui héritent automatiquement des quotas, RBAC et Network Policies du parent.

6.5 FinOps et optimisation des coûts cloud

Le FinOps (Cloud Financial Operations), formalisé par la FinOps Foundation (2023), est une pratique culturelle et technique qui vise à maximiser la valeur métier de chaque euro dépensé dans le cloud. Le rapport FinOps Foundation indique que les organisations gaspillent en moyenne 32% de leurs dépenses cloud — principalement en raison de ressources surprovisionnées et d’instances non utilisées.

Dans Kubernetes, l’optimisation des coûts passe par plusieurs leviers :

Right-sizing — Ajustement des requests et limits CPU/mémoire à la consommation réelle. Le VPA (Vertical Pod Autoscaler) en mode recommendation analyse la consommation historique et suggère des valeurs optimales. Kubecost (maintenant OpenCost, projet CNCF) attribue les coûts par namespace, deployment, label ou équipe, offrant une visibilité granulaire sur les dépenses (OpenCost Documentation, 2024).

Spot/Preemptible instances — Les instances spot AWS (ou preemptible GCP, spot Azure) coûtent 60-90% moins cher que les instances on-demand, mais peuvent être interrompues avec un préavis de 2 minutes. Karpenter gère automatiquement la diversification des types d’instances spot pour minimiser le risque d’interruption simultanée. Les workloads tolérants aux interruptions (batch, CI/CD, tests) sont les candidats idéaux.

Scale-to-zero — KEDA et Knative permettent de scaler les workloads à zéro Pod quand aucune charge n’est présente. Pour les environnements de développement et staging, un scale-to-zero nocturne (via des CronJobs ou des planifications KEDA) peut réduire les coûts de 40-60%.

Reserved instances / Savings Plans — Engagement d’utilisation sur 1 ou 3 ans pour les workloads stables (bases de données, services critiques). Les économies atteignent 30-72% selon la durée et le niveau de paiement anticipé. La combinaison reserved (workloads stables) + spot (workloads flexibles) + on-demand (pics) optimise le rapport coût/disponibilité.

6.6 Conformité réglementaire

La conformité réglementaire dans les environnements cloud-native nécessite une approche intégrée combinant contrôles techniques, processus organisationnels et documentation continue.

ISO 27001:2022 — Standard international pour les systèmes de management de la sécurité de l’information (SMSI). Les contrôles pertinents pour les environnements cloud-native incluent : A.8.9 (gestion de la configuration), A.8.25 (cycle de développement sécurisé), A.8.26 (exigences de sécurité applicative), A.8.31 (séparation des environnements). L’approche GitOps facilite la conformité en fournissant un historique versionné de toutes les configurations (ISO, 2022).

SOC 2 Type II — Rapport d’audit développé par l’AICPA, évaluant les contrôles de sécurité, disponibilité, intégrité du traitement, confidentialité et vie privée sur une période de 6 à 12 mois. Les preuves d’audit (logs Kubernetes, historique Git, dashboards de monitoring, rapports de scan de vulnérabilités) doivent être collectées et archivées en continu. Des outils comme Drata ou Vanta automatisent la collecte de preuves pour SOC 2.

RGPD (Règlement Général sur la Protection des Données) — Le règlement européen impose des contraintes spécifiques sur les environnements cloud :

• Localisation des données — Les données personnelles des résidents européens doivent être traitées conformément au RGPD, ce qui impose souvent un hébergement en région EU. Les providers cloud proposent des régions dédiées (eu-west-1, europe-west1).
• Droit à l’effacement (Article 17) — L’architecture doit permettre la suppression complète des données d’un utilisateur, y compris dans les backups, les caches et les logs. Les systèmes d’Event Sourcing doivent prévoir un mécanisme de « crypto-shredding » (suppression de la clé de chiffrement rendant les données illisibles).
• Privacy by Design (Article 25) — La protection des données doit être intégrée dès la conception. Le chiffrement at-rest et in-transit, la pseudonymisation et la minimisation des données sont des contrôles techniques recommandés.
• Registre des traitements (Article 30) — Documentation exhaustive des traitements de données personnelles, incluant les finalités, les catégories de données, les destinataires et les durées de conservation.

La compliance as code — l’automatisation des contrôles de conformité via OPA/Kyverno, les scans de sécurité automatisés (Trivy, Falco) et les dashboards de conformité (Kubecost, Grafana) — transforme la conformité d’un exercice annuel ponctuel en un processus continu et vérifiable. Chef InSpec, HashiCorp Sentinel et les frameworks cloud-native de compliance (NSA Kubernetes Hardening Guide, CIS Benchmarks) fournissent des bibliothèques de contrôles prêts à l’emploi.

Références

• ArgoCD Documentation (2024). « App of Apps Pattern » et « ApplicationSets ». argo-cd.readthedocs.io.
• CNCF (2024). Cloud Native Survey 2024. Cloud Native Computing Foundation.
• Crossplane Documentation (2024). « Compositions and Claims ». docs.crossplane.io.
• FinOps Foundation (2023). State of FinOps 2023. finops.org.
• ISO (2022). ISO/IEC 27001:2022 — Information Security Management Systems. iso.org.
• Kubernetes SIG Multi-Tenancy (2024). « Multi-tenancy Concepts ». kubernetes.io.
• Limoncelli, T. A., Chalup, S. R. & Hogan, C. J. (2020). The Practice of Cloud System Administration, 2nd Edition. Addison-Wesley.
• OpenCost Documentation (2024). « Kubernetes Cost Monitoring ». opencost.io.
• OpenGitOps (2022). « GitOps Principles v1.0 ». opengitops.dev.
• Richardson, A. (2017). « GitOps — Operations by Pull Request ». Weaveworks Blog.
• Weaveworks (2023). « Flux vs ArgoCD ». fluxcd.io.