Utilisation de GitOps avec Amazon Elastic Kubernetes Service par Landbay

Dans le paysage évolutif des prêts numériques, Landbay, un prêteur hypothécaire primé sur le marché britannique de l’achat à la location, révolutionne son infrastructure numérique. Dotée d’une plateforme de courtage de premier ordre prenant en charge ses opérations de souscription, la plateforme de Landbay repose sur les services AWS et comprend environ 60 microservices, suivant une architecture à trois niveaux, combinant des serveurs Web, Amazon Elastic Kubernetes Service (Amazon EKS) et une couche de données multicouche. En combinant la puissance des services Cloud AWS avec des projets open source, Landbay a pu exploiter cette nouvelle approche pour créer une architecture de premier ordre basée sur Amazon Elastic Kubernetes Service.

L’avantage de GitOps

Alors que les architectures de microservices gagnent en importance, GitOps est devenu une nouvelle norme pour ce scénario de déploiement. Deux produits remarquables ont vu le jour au sein de la Cloud Native Computing Foundation (CNCF) : Flux et ArgoCD. Landbay a sélectionné Flux pour son intégration native à Kubernetes en exposant des définitions de ressources personnalisées (CRD) pour définir les déploiements, les versions de Helm, les Kustomisations, et plus encore. Cela a permis aux ingénieurs logiciels de maîtriser Kubernetes et de mieux comprendre comment Flux s’intègre dans l’écosystème.

Présentation de la solution

Pour bien comprendre la mise en œuvre de GitOps par Landbay, passons en revue les principaux composants architecturaux et leurs relations au sein de l’écosystème AWS :

• Amazon Elastic Container Registry (ECR) : Landbay exploite Amazon ECR pour stocker les Charts de Helm, ainsi que les images Docker.
• Contrôleurs externes DNS et AWS Elastic Load Balancing : ces contrôleurs sont utilisés pour configurer Route53 et les équilibreurs de charge, garantissant ainsi un accès externe aux entrées Kubernetes.
  
• Intégration d’AWS Secrets Manager : pour des raisons d’architecture et de sécurité, Landbay a opté pour une intégration directe avec AWS Secrets Manager, plutôt que d’utiliser des outils externes tels qu’un contrôleur de secrets externe, qui s’aligne sur le modèle de responsabilité partagée d’AWS et améliore la posture de sécurité globale de la solution.
  
• Gestion de la configuration Terraform : Terraform peut être utilisé pour combler le fossé en fournissant une ConfigMap et en résumant les principaux éléments de configuration (points de terminaison, sous-réseaux CIDR, etc.). Flux peut ensuite utiliser la carte de configuration via sa fonctionnalité de post-construction (voir figure 2).
  

Environnement Kubernetes et architecture de données de Landbay

Landbay est un fervent adepte de Terraform et toute son infrastructure est codifiée avec l’infrastructure en tant que code (IAC). Cette approche garantit la synchronicité entre les environnements de test et de production et garantit que tous les changements d’infrastructure passent par le processus de cycle de vie de développement logiciel standard.

Pour garantir l’absence de durée d’indisponibilité lors des mises à niveau d’Amazon EKS, Landbay utilise des groupes de nœuds gérés par EKS avec trois groupes de nœuds gérés, chacun ciblant une zone de disponibilité spécifique. Cette configuration leur permet d’utiliser des volumes persistants, grâce au pilote CSI Amazon Elastic Block Store (EBS). En outre, Landbay utilise topologySpreadConstraints (DoNotSchedule) pour garantir que les StatefulSets sont répartis dans les zones de disponibilité.

Pour les services critiques, des classes de priorité personnalisées sont utilisées pour éliminer les déploiements moins prioritaires.

Pour réduire les coûts liés à l’environnement de test, Landbay exploite la puissance des instances Spot Amazon EC2 via Terraform et les groupes de nœuds gérés par Amazon EKS.

Enfin, Landbay a adopté Bottlerocket en présentant une surface d’attaque nettement réduite.  Son opérateur Kubernetes est utilisé pour mettre à niveau progressivement les nœuds d’un cluster en utilisant le concept de vagues. Bien que l’accès au système de fichiers racine soit verrouillé, l’intégration avec IAM et Systems Manager (SSM) répond aux exigences fondamentales de Landbay.

Modules complémentaires Amazon EKS

Outre le plug-in CNI Amazon Virtual Private Cloud (Amazon VPC), Landbay exécute les modules complémentaires suivants :

1. CoreDNS : garantit la résolution du service DNS au sein du cluster
2. KubeProxy : sous-tend la découverte des services et la mise en réseau au sein de Kubernetes.
   
3. Amazon VPC CNI avec enableNetworkPolicy  : permet l’application de politiques réseau, aidant Landbay à sécuriser les différents accès aux espaces de noms et aux pods.
   
4. Pilote CSI Amazon EBS : permet l’utilisation de volumes persistants.
   

Configuration de la gestion des accès

Landbay utilise AWS IAM Identity Center pour contrôler tous les accès aux API AWS. Amazon EKS permet de mapper les rôles SSO dans les groupes Kubernetes, ce qui permet un mappage indirect avec les groupes d’ID Azure Entra par l’intermédiaire de l’équipe d’administration informatique. Cette approche garantit une séparation des préoccupations entre l’équipe d’administration informatique et le reste de l’organisation.

Le fragment ci-dessus peut ensuite être utilisé pour définir une ressource kubernetes_config_map_v1-data aws_auth :

Pour éviter une prolifération de rôles, Kubernetes fournit un mécanisme permettant de regrouper les autorisations des autres versions de Helm dans des groupes existants en utilisant « aggregate-to-admin » :

AWS Load Balancer Controller

Pour améliorer l’intégration entre les services, Landbay a tiré parti d’AWS Load Balancer Controller (LBC) et d’un contrôleur DNS externe.

AWS Load Balancer Controller permet d’allouer des équilibreurs de charge directement depuis Ingresses, ainsi que de réutiliser des équilibreurs de charge gérés en externe et d’attribuer des pods cibles. En séparant l’allocation des équilibreurs de charge dans un projet distinct, les équipes DevOps peuvent bénéficier de plus de privilèges sur un référentiel de code source tout en fournissant les outils nécessaires à la tâche aux ingénieurs qui gèrent les cibles.

Le contrôleur gère également les groupes de sécurité si nécessaire sur le dorsal entre l’équilibreur de charge et ses cibles. De plus, en utilisant l’annotation group.name, le même équilibreur de charge peut être partagé avec plusieurs groupes cibles en arrière-plan

Landbay utilise également AWS Load Balancer Controller pour allouer des Network Load Balancers afin de permettre l’entrée des fonctions AWS Lambda exécutées dans le VPC dans l’infrastructure EKS.

En complément, le contrôleur DNS externe permet aux pods Kubernetes de limiter l’accès en écriture à Route53. Cette fonctionnalité facilite l’exposition automatique des services externes avec des noms DNS conviviaux, améliorant ainsi l’expérience utilisateur globale.

Du point de vue de la sécurité, le contrôleur d’Application Load Balancer (ALB) et le contrôleur DNS externe nécessitent un ensemble limité d’autorisations IAM, qui peuvent être verrouillées de manière stricte. Par exemple, le contrôleur DNS nécessite simplement un accès en écriture à des zones Route 53 spécifiques (route53:ChangeResourceRecordSets) ainsi qu’une poignée d’autorisations de liste.

Gestion des secrets dans Kubernetes

Alors que la plupart des solutions résolvent les problèmes liés à la gestion des secrets, tels que la rotation des secrets et l’intégration, l’utilisation du stockage secret Kubernetes ou la synchronisation de secrets externes avec Kubernetes entraîne le stockage des secrets en texte clair dans l’etcd sous-jacent de Kubernetes.  Bien que l’utilisation de « secrets chiffrés dans EKS » contribue à atténuer les vecteurs d’attaque physiques, l’accès via l’API Kubernetes expose les valeurs brutes du secret, conformément au modèle de responsabilité partagée d’AWS.

L’utilisation du pilote CSI (Container Storage Interface) fourni par AWS présente des avantages, mais éloigne également l’architecture de la gestion native de Kubernetes. Étant donné que le pilote CSI et la solution d’un fournisseur externe nécessitent une intégration directe avec le fournisseur de secrets externe,  Landbay a décidé d’intégrer ses microservices directement à AWS Secret Manager.

L’option d’intégration directe évite de complexifier l’environnement, ce qui pourrait entraîner une augmentation des coûts de maintenance et de support. Cela permet également d’éviter la présence de secrets en texte clair dans les volumes de conteneurs, ce qui renforce encore la sécurité.

Allocation de Flux dans l’environnement AWS

Flux, la solution GitOps choisie par Landbay, apporte un fournisseur Terraform pour le démarrage des clusters EKS. À intervalles réguliers configurables, Flux s’assure que tous les manifestes Kubernetes définis dans le référentiel Git se réconcilient avec les ressources existantes déployées sur Kubernetes, annulant ainsi toute dérive détectée. Une fois que Flux est démarré, il peut effectuer sa première réconciliation, en installant les services configurés, les pods, les ensembles dynamiques, etc. sur le cluster Kubernetes, comme indiqué dans la figure ci-dessous.

Flux peut tirer parti d’AWS Elastic Container Registry (ECR) en tant que référentiel Helm, car ECR propose un support de premier ordre pour les artefacts OCI. Cela permet à Flux d’agir comme le ciment entre ECR et EKS, en utilisant Kustomizations pour appliquer des configurations spécifiques à l’environnement.

L’un des principaux avantages de cette approche est la séparation logique entre la partie intégration continue (CI) du pipeline de déploiement (construction, test et package) et la partie déploiement continu (CD) (livraison dans l’environnement). Du point de vue de la sécurité, Flux extrait les modifications, ce qui permet de verrouiller de manière significative les autorisations d’accès pour les déploiements quotidiens. Pour éviter les retards de déploiement, la seule autorisation requise est que l’outil de génération « notifie » Flux d’une réconciliation anticipée, qui peut être effectuée via un kubeconfig verrouillé, avec un utilisateur restreint.

Par conséquent, le déploiement, la restauration ou la promotion d’un nouveau microservice deviennent aussi simples que la mise à jour d’un fragment de gestion sémantique de version (semver) dans un fichier YAML ou l’annulation d’un commit. En cas de modification de Git, Flux déclenche une réconciliation avec Kubernetes et met à jour le service concerné en conséquence.

Structure du référentiel Flux et composants partagés

Flux fournit une documentation complète sur les  structures de référentiel recommandées. L’approche de Landbay est relativement simple et suit ces bonnes pratiques.

Les configurations de cluster sont définies dans leurs propres dossiers dédiés, chacun faisant référence à des composants partagés. Dans ces dossiers de cluster, l’utilisation intensive de Kustomizations garantit l’isolation entre les clusters. Cela permet des configurations spécifiques à l’environnement, telles que la gestion des versions et la mémoire.

La structure illustrée ci-dessus établit un équilibre entre le partage de code et le maintien de la nature déclarative et explicite du paradigme GitOps, permettant à un ingénieur de lire un référentiel Git et de déterminer quels composants, versions ou packages ont été installés sur le cluster.

En séparant les composants, Landbay peut rationaliser le processus de création de nouveaux clusters. À partir de là, la configuration des clusters consiste à choisir des « briques LEGO » et à les assembler avec une configuration spécifique à l’environnement.

En outre, alors que certains clusters fonctionnent dans le cloud et nécessitent des composants supplémentaires, d’autres clusters peuvent être destinés aux ingénieurs DevOps travaillant localement. Cette approche de développement local permet une boucle de rétroaction plus rapide et n’inclut pas les composants directement liés aux services AWS.

Le développement local comme tremplin

Cette approche de développement local constitue également le tremplin pour des déploiements rapides d’environnements de développement éphémères basés sur le cloud. En utilisant les espaces de noms Kubernetes et en supprimant les dépendances vis-à-vis des services gérés AWS, Landbay est en mesure d’utiliser Flux pour démarrer rapidement de nouveaux environnements autonomes.

Dans ce cas, l’environnement de développement de Landbay pourrait remplacer Amazon Relational Database Service (RDS) par un simple conteneur MariaDB, Amazon OpenSearch Service par le conteneur OpenSearch équivalent. Bien que cette approche permette aux environnements de développement de rester « en phase » sur le plan architectural (par exemple, espacement de noms similaire, découverte de services, mise en réseau), le compromis résulte en un manque de résilience opérationnelle, ce qui peut être acceptable pour certains environnements de développement.

Intégration des services EKS, GitOps et AWS

Chez Landbay, l’infrastructure AWS est entièrement gérée par Terraform. Il est donc impératif de combler le fossé entre les éléments provisionnés par Terraform (RDS, OpenSearch, etc.) et les autres pods exécutés au sein du cluster. La méthode native pour accéder à la configuration dans Kubernetes dans les microservices est via ConfigMaps.

Le schéma suivant montre l’interrelation entre nos projets Terraform et Flux.

Le premier projet Terraform est chargé de mettre en place tous les réseaux de base, les équilibreurs de charge connectés à Internet et les services gérés AWS. Le second projet établit le cluster EKS, initialise Flux dans le cluster, sécurise le cluster EKS, configure tous les rôles IAM et gère les problèmes de bas niveau tels que les groupes de nœuds gérés exécutant Bottlerocket. Ce projet crée un environnement ConfigMap qui interroge AWS pour toutes les variables d’environnement et les injecte dans Kubernetes.

Le projet final est un projet Flux dédié. Il définit la configuration du cluster pour l’environnement,  établit des liens vers un ensemble de composants partagés, puis kustomise les versions de Helm et les manifestes Kubernetes en fonction de l’environnement concerné. L’environnement ConfigMap peut ensuite être utilisé dans le cadre de kustomisations au sein du référentiel Flux. Flux propose également une fonctionnalité de substitution de variables après la construction, permettant d’utiliser des substitutions de variables avec un ensemble riche de fonctions de remplacement de chaînes bash bien définies.

Par exemple, dans un Chart de Helm, les valeurs peuvent utiliser la substitution de variables après la construction. Comme le montre l’illustration ci-dessous, cette approche améliore le référentiel GitOps afin que les composants partagés puissent être indépendants de l’environnement.

Conclusion

La décision de Landbay d’adopter GitOps via Flux, étroitement intégré à Amazon EKS et à l’écosystème AWS dans son ensemble, a changé la donne. En adoptant cette approche de pointe, Landbay a obtenu une myriade d’avantages qui ont rationalisé ses opérations et amélioré sa posture de sécurité. L’un des avantages les plus importants a peut-être été la réalisation de gains d’efficacité en matière d’ingénierie à tous les niveaux. Qu’il s’agisse de déploiements plus rapides, de réduction des temps d’attente ou d’une exploitation fluide de solutions tierces, l’intégration de GitOps aux services EKS et AWS a révolutionné les processus de développement de Landbay.

En outre, le paysage de sécurité de Landbay a été renforcé, devenant plus robuste et plus rentable à entretenir. En exploitant Bottlerocket, en séparant les tâches via des autorisations SCM/Git et en permettant des mises à niveau sans effort via Helm, Landbay a renforcé son engagement en matière de sécurité tout en optimisant les coûts opérationnels.

L’impact le plus significatif de cette transformation réside dans la visibilité et la transparence accrues de l’état et des modifications de la charge de travail EKS. Avec GitOps, la configuration est déclarée à l’aide de YAML et toutes les modifications sont stockées sous forme de commits Git. Ce changement de paradigme a apporté des avantages significatifs aux équipes de support, de gestion des risques, de conformité et d’audit de Landbay, en leur donnant des informations et un contrôle sans précédent sur leurs systèmes critiques.

Si vous êtes prêt à transformer votre start-up comme Landbay, rejoignez AWS Activate pour accéder à des modèles déployables, à des crédits AWS et à des opportunités de formation.