Cloud Nord 2023 : Les retours de nos Sfeiriens - Partie 2

C'est parti pour la deuxième partie des debriefs de l'édition Cloud Nord 2023. Si vous n'avez pas lu la partie 1, il n'est jamais trop tard 😉

On démarre ce debrief par le Workshop sur Crossplane. 2 Sfeiriens ont eu la chance d'y assister.

Faire du Kubernetes multi-providers en mode GitOps avec CrossPlane

Présenté par Laurent Grangeau, il s'agissait d'un atelier pour mettre en place une infrastructure Cloud avec Crossplane. Nous sommes parties d'un cluster Kubernetes sur lequel nous déployons l'opérateur Crossplane. Ensuite, nous avons utilisé des ressources Crossplane et examiné l'architecture de Crossplane, pour déployer d'autres clusters Kubernetes sur Google Cloud et AWS.

Nous avons étudié comment fonctionne Crossplane, ainsi que les providers communautaires et officiels.

C'était aussi l'occasion de creuser les détails du fonctionnement de Crossplane, que j'ai déjà vu il y a quelques années. Et de se poser des questions sur le fonctionnement de Crossplane par rapport à Terraform, notamment au niveau du state, de la détection de drift et de l'application des modifications.

Crossplane présente de nombreux avantages et inconvénients par rapport à Terraform. On peut déjà citer la communauté, qui est forcément moins importante que celle de Terraform. Les avantages de Crossplane par rapport à Terraform sont assez évidents, notamment la détection immédiate du drift et une application des modifications plus unitaire que sur Terraform. En ce qui concerne les inconvénients, on note le manque de feedback. On a toujours envie de vérifier les modifications qui vont être appliquées avant de les effectuer. Il existe l'équivalent d'un "Terraform Plan" sur Crossplane, mais il semble moins bien intégré, surtout lorsque l'on parle de ressources YAML que l'on applique sans avoir de feedback direct.

En fin de compte, c'était vraiment un atelier intéressant. Pour ma part, le projet est encore trop jeune pour être utilisé en production, mais c'est une technologie à suivre de près.

Bravo et merci à Laurent Grangeau pour ce hands'on qui a nécessité un gros travail de préparation. Il est d'ailleurs disponible ici musk8teers/crossplane-anthos.

Observabilité : prenez des décisions éclairées pour un numérique responsable !

Les avancées technologiques ont entraîné une décentralisation des systèmes, passant des solutions sur site aux environnements cloud, mobiles et virtualisés.

Cette évolution offre des avantages en termes de mutualisation des ressources, mais elle nécessite une surveillance attentive. Il est essentiel de passer de la simple supervision des données techniques à l'observabilité qui relie ces données à des métriques métier pertinentes. Par exemple, au lieu de se concentrer sur des métriques techniques telles que la consommation CPU ou la latence, l'observabilité peut se concentrer sur des mesures comme le nombre de paniers de commande dans le contexte d'une plateforme e-commerce.

Le concept de numérique responsable vise à réduire l'impact environnemental et social des technologies de l'information et de la communication. Cela implique d'harmoniser la technologie avec l'environnement, en créant de la valeur tout en minimisant l'empreinte écologique.

L'observabilité joue un rôle clé en automatisant la collecte de données observables dès le déploiement, en les rendant accessibles à tous et en garantissant leur qualité pour toutes les équipes. Les équipes de développement doivent également être conscientes de l'observabilité, tout comme les équipes OPS qui gèrent l'infrastructure. Cela permet de garantir la pertinence des données collectées et une meilleure optimisation des ressources.

La mesure de la consommation de ressources informatiques, des échanges de données, et de la charge du processeur et de la RAM est importante, mais il est tout aussi crucial de déterminer si les fonctions de l'application sont effectivement utilisées. Réduire le code inutile réduit les coûts de maintenance et la consommation de ressources. L'idéal est également d'ouvrir ces fonctions à un large public, ce qui peut apporter de la valeur et justifier leur maintenance.

Toutes ces considérations peuvent être évaluées en termes d'impact sur la planète, en mesurant l'utilisation des ressources telles que l'eau, l'électricité et l'empreinte carbone, ainsi que la valeur ajoutée par fonction. Pour atteindre des objectifs de numérique responsable, il est essentiel de créer des tableaux de bord accessibles à tous, d'établir des objectifs clairs, de mettre en place des plans d'actions concrets et de suivre régulièrement les progrès réalisés.

Accélérer sa transformation DevOps ... avec Accelerate !

Lors de sa conférence, Jean-Rémy REVY, responsable de l'architecture, a partagé des idées essentielles pour améliorer les performances IT et les résultats en production, mettant l'accent sur la nécessité d'indicateurs de performance. 

Ces indicateurs sont divisés en deux catégories : la vitesse et la stabilité, et leur suivi est essentiel à chaque livraison. Un point clé est le "Time to Restore" en cas de problème en production, qui influence la perception du service par les utilisateurs. Il souligne qu'”Accelerate” n'est pas une solution clé en main, car chaque entreprise est unique et nécessite une approche personnalisée.

Sur le terrain, il recommande de réaliser un Quick Check DORA, composé de 5 questions, pour évaluer le niveau de l'équipe dans ces domaines. Il insiste également sur la loi du rendement décroissant, soulignant que l'augmentation illimitée du nombre de développeurs ne résoudra pas tous les problèmes. Pour favoriser l'amélioration continue, il encourage l'utilisation du “Test-Driven Development” (TDD) et des principes Lean.

Les actions concrètes à entreprendre incluent l'automatisation des tests, l'intégration continue, et la documentation. En cas de complexité, le “value stream mapping”, en utilisant le lean management, peut lever les verrous et améliorer la fiabilité de la production.

Il est important de suivre les progrès en utilisant les indicateurs de DORA, de consulter le marché et de s'assurer que la confiance dans le référentiel augmente.  Jean-Rémy REVY rappelle également la "Loi de Goodhart," soulignant que lorsqu'une mesure devient un objectif, elle perd son efficacité comme indicateur.

Les slides sont disponible ici

Ma Wardley Map me dit de ne pas apprendre Kubernetes, que dit la vôtre ?

Ça faisait un moment que j’étais pitché par cette approche, mais sans jamais vraiment avoir creusé la question des cartes de Wardley. C’était l’occasion de plonger dedans grâce à la conférence d’Olivier Wulveryck.

De quoi s’agit-il ? Une carte de Wardley est une représentation de différents concepts, services, produits, de la relation entre ces éléments, et le niveau de maturité dans l’entreprise.

Olivier est revenu sur les fondations des cartes de Wardley, pour bien comprendre comment ces cartes fonctionnent, en prenant référence aux stratégies militaires de Sun Tzu et de John Boyd.

Olivier nous a montré ensuite comment construire une carte de Wardley avec l’exemple d’une tasse de thé, et comment les différents éléments se relient entre eux. J’étais particulièrement intéressé par le sujet, et le concept est resté encore un peu flou pour moi, j’aurais aimé avoir un peu plus de concret, et comprendre comment une carte de Wardley peut m’aider dans une vision stratégique. Comme, par exemple, savoir pourquoi je ne devrais pas apprendre Kubernetes ;).

Pour aller plus loin, vous pouvez lire l'article d'Olivier sur ce sujet.

Exploitation de vulns dans AWS : le Hacker, le Newbie et la CloudSec

Présentation par Benjamin Merieau et Jean Verrons

Equipés de leurs 3 chapeaux, Ben et Jean nous ont fait un petit jeu de rôle dans lequel ils alternaient entre 3 personnages : l’admin débutant, le hacker et le spécialiste cyber sécurité.

Ils nous ont montré qu’exploiter des vulnérabilités sur une plateforme AWS peut se faire en utilisant plusieurs techniques malveillantes. Voici quelques unes de leurs actions :

• Injection de code GitHub Action par le titre d'une PR : En exploitant une faille de sécurité dans GitHub Actions, un attaquant pourrait insérer du code malveillant dans le flux de travail d'une Pull Request (PR) en modifiant son titre. Ce code injecté peut être utilisé pour exécuter des commandes non autorisées ou détourner le processus de CI/CD pour compromettre les systèmes AWS.
• Récupération d'informations par l'EC2 instance metadata : Les instances EC2 d'AWS exposent des métadonnées sensibles auxquelles un attaquant peut accéder s'il peut compromettre une instance. En exploitant des vulnérabilités, un attaquant peut récupérer des informations critiques, telles que des clés d'accès IAM ou d'autres données de configuration, ce qui peut lui permettre d'accéder à des ressources AWS de manière non autorisée.
• Utilisation de privilèges excessifs pour récupérer des fichiers d'un bucket S3 : Si un utilisateur AWS dispose de privilèges excessifs, par exemple en ayant des politiques IAM trop permissives, un attaquant peut exploiter cette configuration pour accéder à des fichiers dans un bucket S3. En conséquence, il peut récupérer des données confidentielles ou sensibles stockées dans S3, compromettant ainsi la sécurité de l'environnement AWS.

La prévention de ces vulnérabilités implique une gestion rigoureuse des autorisations et des politiques IAM, une configuration sécurisée de GitHub Actions, et des bonnes pratiques de sécurité pour limiter l'accès aux données sensibles sur AWS, notamment en contrôlant l'accès aux buckets S3 et en utilisant les métadonnées de l'instance EC2 de manière sécurisée.

Au travers de leur jeu de rôle, Ben et Jean nous ont démontré l’importance de respecter quelques règles simples qui permettent de rendre plus robuste un environnement Cloud AWS.

Keynote de Clôture

La journée se termine avec la keynote de Solène Lapouge qui nous partage sa reconversion dans l’informatique, un bel exemple de résilience tout au long de sa vie professionnelle et personnelle. Mention spéciale à Solène pour ses talents d’oratrice. A noter que nous avons été bluffés par sa capacité à prendre la parole quasi sans support de présentation.