Sécurité

Le problème des secrets en GitOps Dans une approche GitOps, tout passe par le repo Git : les manifests Kubernetes, les configurations, et idéalement les secrets aussi. Mais comment gérer les secrets de manière sécurisée dans un repo Git ? SOPS : Secrets OPerationS Principe : chiffrement côté fichier SOPS s’intègre aux KMS, par exemple sur GCP Cloud Key Management via le principe d’Envelope Encryption : il génère une clé symétrique éphémère (DEK) pour chiffrer les secrets, et délègue à GCP KMS le chiffrement de cette DEK. ...

Qu’est-ce que c’est ? CMCTL est un outil en ligne de commande pour interagir avec Cert Manager. CMCTL permet de gérer les ressources Cert Manager, de diagnostiquer les problèmes et d’automatiser certaines tâches liées à la gestion des certificats. Puisque nous l’avons installé dans le précédent article il me parassait intéressant de partager mes commandes préférées pour interagir avec Cert Manager via cmctl. Installation brew install cert-manager/cert-manager/cmctl Sinon pour Windows via scoop ...

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é. ...