De nombreuses entreprises françaises ont commencé à expérimenter sur le Cloud AWS il y a quelques années, et ce parfois en toute indépendance des structures Groupe. Que se passe-t-il alors quand, quelques années plus tard, toutes les applications sont sur le Cloud AWS, mais sans que n’aient été prises en compte toutes les exigences Cloud prescrites par la maison mère ? Comment se mettre en conformité a posteriori aux règles de gestion de la gouvernance Cloud, d’architecture d’une Landing zone, de paramétrage des comptes et de gestion des droits d’accès, etc. ?

Dans la partie 1 de cet article, nous avons vu l’état des lieux des problématiques sécurité, les objectifs établis, le cadrage du projet et les besoins d’évolution de la chaîne CI/CD. Nous passons ici au bilan CI/CD et Sécurité, et aux enseignements tirés de ce projet.

Bilan au niveau de la chaîne CI/CD

D’un point de vue de la chaîne CI/CD, le bilan projet est le suivant :

• Rationalisation des instances Jenkins : passage de plus de 20 instances à 2, gérées de façon automatisée en Infrastructure as code (IAC).
• Migration d’environ 300 jobs Jenkins (builds Java, Node, Scala, docker et déploiements Ansible).
• Mise à jour aux dernières versions de Nexus et SonarQube.
• Déploiement d’un cluster AWS ECS pour l’hébergement des outils conteneurisés.
• Mise en place de chaînes automatisées de déploiement des outils et de leurs infrastructures avec Terraform.

La migration à proprement parler a été réalisée pour Jenkins, Nexus et SonarQube, avec une mise à jour aux versions les plus récentes. Tout a été mis en conteneurs sur un cluster AWS ECS pour simplifier la mise à jour, la gestion de l’infrastructure via cluster AWS ECS et suivre la logique de rationalisation des ressources. 

Jenkins a été déployé au sein d’une infrastructure scalable avec usage de workers dynamiques (en fonction de la charge, on ajoute ou on enlève automatiquement des workers sur des spots instances EC2).

Ce passage à une infrastructure élastique a permis de rationaliser le nombre de masters Jenkins et de proposer une configuration unique et simple des workers (contenant uniquement docker).

Bilan Sécurité 

Nous avons mené plusieurs ateliers de spécification avec les équipes, afin de traiter les enjeux sécurité et gouvernance en terme d’organisation des comptes AWS, de configuration réseau, de chiffrement, de modélisation de l’infrastructure, de gestion des accès aux outils, d’organisation des répertoires d’IAC, l’organisation des pipelines de déploiement de ces infrastructures.

Pour la partie CI/CD, nous avons recommandé de créer un compte AWS spécifique. Ceci s’est fait dans le respect des processus Groupe, via une demande d’un compte standard de Landing zone. Si ce choix a entraîné une petite perte d’indépendance, puisqu’il n’est plus possible de créer des rôles de sécurité au sein de l’entité (il faut en faire la demande), cela a contribué en revanche à établir un climat de confiance avec l’équipe Groupe en charge de la fourniture des comptes. 

Afin de ne plus exposer les outils (Jenkins, Nexus, Sonar) sur Internet, nous avons préconisé de rattacher le compte AWS au réseau interne. La mise en œuvre s’est faite avec AWS Transit Gateway en collaboration avec les équipes réseau du client. 

Dans cette logique de sécurisation, l’accès aux comptes AWS a également été revu pour utiliser un système de rôles. Les quelques secrets restants sont désormais gérés avec Secret Manager, grâce à  son intégration native avec le service AWS ECS. 

Enfin, tous les outils ont été configurés pour utiliser le proxy sortant de l’équipe sécurité Groupe du client, qui désormais contrôle tous les flux à destination d’internet.  

Un pilote pour découvrir

Avant de lancer la phase de migration massive de l’ensemble des pipelines des applications, nous avons opté pour une phase de livraison minimale (MVP) des outils CI/CD. Il nous a aussi semblé important que ce MVP soit testé à travers la migration d’une première application pilote simple . Cela nous a permis de nous assurer du bon fonctionnement de l’ensemble des nouveaux pipelines et de sa maîtrise par les équipes de développement. Cette étape nous a aussi permis de parfaire notre connaissance des outils et pratiques des équipes dev et devops, et d’ajuster au fil de l’eau notre accompagnement et notre démarche de migration. 

Cette migration pilote a fait l’objet d’un REX de notre part auprès des équipes de développement, afin d’expliciter les composants qui devaient être mis à jour et les modifications de jobs à apporter pour s’adapter à la nouvelle chaîne CI/CD. Ce REX a agi comme un déclencheur et les équipes ont commencé à prendre en main le sujet de leur côté. Cette approche était importante aussi en termes de transparence, et donc de confiance. Les équipes Devoteam Revolve ont migré beaucoup d’autres composants par suite, mais toujours avec la compréhension et la validation des équipes internes.

Une généralisation sur mesure

Une fois le pilote validé, toutes les applications ont été intégrées une à une dans la nouvelle chaîne CI/CD ; tissant toujours plus la relation avec les équipes de développement, de telle sorte que le transfert de compétences s’est fait au fur et à mesure des migrations. 

Pour garder la cadence de migration et éviter tout blocage nous avons mis en place de courts ateliers techniques quotidiens avec chaque équipe pendant sa phase de migration. Au menu, questions/réponses sur les pipelines existants, tests et débogages en direct, explications et démonstrations. Tous les ingrédients pour maintenir le contact, la transparence et le transfert de connaissances. 

Concernant la documentation, tout a été réalisé dans Confluence. Confluence a aussi été l’outil de présentation et de documentation lors des sessions de transfert de connaissances. L’avantage de cette approche est qu’elle nous a permis d’éprouver la qualité et la pertinence de notre documentation ; mais également de favoriser une meilleure appropriation par les équipes, non seulement du fonctionnement, de la configuration des outils et de leur exploitabilité, mais aussi des exigences de sécurité auxquelles ils devaient répondre.

L’accès aux outils par exemple, ne se fait plus à partir de comptes locaux mais par une authentification SSO. Dans la documentation, nous avons pu d’une part expliquer et présenter le service SSO proposé par l’équipe Habilitation du client mais également référencer directement leur documentation à la nôtre pour fournir plus de détails ou du support.

La mission cachée

La conduite de la phase de cadrage de ce projet a été déterminante pour la réussite de ce projet. Au-delà de la simple migration, ce projet nous a permis de répondre au besoin du client de reprendre en main son propre environnement et de pallier la perte de connaissances due aux nombreux départs récents.

Au final, le challenge technique du projet relevait plus du processus de “reverse engineering” que nous avons dû mener qu’à la complexité des technologies utilisées. Mais bien évidemment, ce travail n’aurait servi à rien si nous n’avions pas également relevé le challenge humain qui consistait à retransmettre ces découvertes aux équipes internes afin de leur redonner confiance dans leurs outils de CI/CD.