DevOps

Date de sortie : 22 avril 2026 Nom de code : ハル (Haru — « Printemps » en japonais) Kubernetes v1.36 est sorti fin avril 2026 sous le nom de code Haru (printemps en japonais), et c’est une release dense. Voici mon tour d’horizon des changements les plus significatifs. 🔐 Sécurité : des fondations qui arrivent enfin à maturité User Namespaces : 🟢 Stable Le problème : Par défaut, un processus qui tourne en tant que root (UID 0) dans un conteneur est aussi root sur le nœud hôte. En cas de fuite de conteneur (container escape), l’attaquant dispose immédiatement de privilèges root sur la machine, ce qui compromet l’ensemble des workloads du nœud. ...

Qu’est-ce que c’est ? Renovate est un outil d’automatisation des mises à jour de dépendances. Il permet de garder les dépendances à jour en créant automatiquement des pull requests pour les nouvelles versions, les correctifs de sécurité et les mises à jour majeures. Exemple de PR avec Renovate Comment ça fonctionne ? Renovate fonctionne en scannant à intervalles réguliers les dépôts Git pour détecter les mises à jour de dépendances. Lorsqu’une mise à jour est disponible, il crée automatiquement une pull request avec les changements nécessaires, y compris un changelog et des notes de version. ...

Cocogitto est un outil de gestion de commit qui facilite la rédaction de messages de commit conformes à la convention Conventional Commit. Il propose notamment une CLI pour rédiger des messages de commit structurés et standardisés, automatiser certaines tâches liées aux commits (génération de changelog, bump de versions …). Si vous ne savez pas ce qu’est la convention Conventional Commit, je vous invite à lire le premier article de cette série à ce sujet : Conventional Commit. ...

Je démarre ici une nouvelle série d’articles sur les bonnes pratiques de développement, en commençant par une convention de commit que j’utilise au quotidien. Introduction Conventional Commit est une convention pour formater les messages de commit de manière structurée et standardisée. Elle permet de faciliter la lecture et la compréhension des messages de commit, ainsi que d’automatiser certaines tâches comme la génération de changelogs ou la gestion des versions. Exemple de commit suivant la convention Conventional Commit ...

Si vous ne savez pas ce qu’est Dependency Track, je vous invite à lire mon article d’introduction à Dependency Track ici. Configuration Les éléments à déployer sont très simples : Un namespace pour isoler les ressources de Dependency Track Un HelmRepository pour indiquer à FluxCD où trouver les charts de Dependency Track Un HelmRelease pour déployer Dependency Track avec les valeurs de configuration souhaitées dependency-track.yaml apiVersion: v1 kind: Namespace metadata: name: dependency-track --- apiVersion: source.toolkit.fluxcd.io/v1 kind: HelmRepository metadata: name: dependency-track namespace: dependency-track spec: interval: 1h url: https://dependencytrack.github.io/helm-charts --- apiVersion: helm.toolkit.fluxcd.io/v2 kind: HelmRelease metadata: name: dependency-track namespace: dependency-track spec: interval: 1h timeout: 15m chart: spec: chart: dependency-track version: "0.44.0" sourceRef: kind: HelmRepository name: dependency-track namespace: dependency-track values: frontend: image: tag: "4.14.1" apiServer: image: tag: "4.14.1" persistentVolume: enabled: true size: 20Gi resources: requests: cpu: "500m" memory: 1Gi limits: memory: 5Gi On applique la configuration avec : ...

Si vous ne savez pas ce qu’est Dependency Track, je vous invite à lire mon article d’introduction à Dependency Track ici. Prerequis Un cluster Kubernetes fonctionnel (Cloud (AWS, GCP, Azure) ou local (Kind, Minikube, K3s) Helm installé et configuré Une instance ArgoCD pour le déploiement en GitOps Pattern App of Apps Le pattern App of Apps consiste à créer une application principale (appelée “App of Apps”) qui référence d’autres applications (appelées “child apps”). Cela permet de regrouper plusieurs applications sous une même hiérarchie et de les gérer de manière centralisée. ...

Voici la première partie d’une série d’articles dédiés à Dependency Track et à son déploiement en mode GitOps avec ArgoCD ou FluxCD sur un cluster Kubernetes. Qu’est ce que c’est ? C’est une plateforme qui permet de suivre les composants logiciels utilisés dans nos applications, d’identifier les vulnérabilités associées et de gérer les risques liés à ces dépendances. C’est un outil particulièrement utile pour répondre aux exigences de sécurité et de conformité de nos systèmes comme le Cyber Resilience Act (CRA) en Europe ou l’IEC 81001-5-1 pour les dispositifs médicaux. ...

Préambule Si vous ne savez pas ce qu’est une SBOM (Software Bill of Materials), je vous invite à lire mon article sur SBOM. Grype - Qu’est-ce que c’est ? Dans l’article précédant je vous ai présenté Syft pour générer ces fameuses SBOM, Grype est un outil complémentaire et développé par la même équipe, qui permet de scanner ces SBOM à la recherche de vulnérabilités connues. Il est notamment utile dans une chaine de CI/CD pour automatiser la détection de vulnérabilités dans les dépendances utilisées par votre projet. ...

Qu’est-ce que c’est ? Une SBOM (Software Bill of Materials) est un fichier qui liste tous les composants logiciels utilisés dans un projet, y compris leurs versions et leurs dépendances. C’est un peu comme une liste d’ingrédients pour une recette de cuisine, mais pour les logiciels. Elles peuvent exister sous plusieurs formats notamment pour les plus connus : CycloneDX, SPDX. Les différents formats CycloneDX CycloneDX est un format de SBOM conçu pour être facile à lire et à analyser. Il utilise une structure hiérarchique pour représenter les composants logiciels et leurs dépendances, ce qui facilite la compréhension des relations entre les différents éléments d’un projet. Il est notamment développé par la fondation OWASP et est largement utilisé dans l’industrie pour la gestion des vulnérabilités et la conformité. ...