DevOps and Security

claire.md

@@ -0,0 +1,87 @@
+Claire:
+Descriptif:
+Dans un environnement basé sur les conteneurs comme Docker, la sécurité est un enjeu majeur. Même si les conteneurs offrent un certain isolement, ils ne sont pas invulnérables : ils peuvent embarquer des vulnérabilités dans leurs images. C’est là qu’intervient Clair, un outil open source développé par CoreOS (maintenant intégré à Red Hat), conçu pour analyser la sécurité des images Docker.
+Clair fonctionne comme un système de scan de vulnérabilités. Il analyse les différentes couches d’une image de conteneur, en extrayant les métadonnées des paquets installés, puis en les comparant à une base de données publique de vulnérabilités (comme le NVD, National Vulnerability Database). Le résultat est un rapport clair et détaillé qui liste toutes les failles de sécurité connues affectant les composants de l’image.
+Ce type d’analyse est crucial pour intégrer la sécurité dans une approche DevSecOps. On peut automatiser l’analyse avec Clair dans des pipelines CI/CD pour détecter les vulnérabilités avant même que les images soient déployées en production. Cela permet non seulement de sécuriser les applications, mais aussi de maintenir la conformité avec certaines normes de sécurité.
+En résumé, Clair est un outil indispensable pour analyser les vulnérabilités des images Docker, s’assurer que le code embarqué n’introduit pas de failles connues, et renforcer la sécurité globale des environnements conteneurisés.
+Code:
+Pour l’installation de claire il est préférable de le faire avec Linux ou Wsl que Windows.
+On passe ensuite à l'installation dans un premier temps il faut prendre en compte le fait qu’il est utile de créer une base PostgreSQL puisqu’elle nous sera utile pour stocker et organiser une grande quantité de données nécessaires à l’analyse de vulnérabilités. On ajoute donc les éléments suivant à notre fichier docker-compose:
+ clair-db:
+    image: postgres:13
+    restart: always
+    environment:
+      POSTGRES_DB: clair
+      POSTGRES_USER: clair
+      POSTGRES_PASSWORD: clair
+    ports:
+      - "5432:5432"
+    volumes:
+      - clair-db-data:/var/lib/postgresql/data
+    networks:
+      - clairnet
+  clair:
+    image: quay.io/projectquay/clair:4.7.2
+    container_name: clair
+    depends_on:
+      - clair-db
+    networks:
+      - clairnet
+    ports:
+      - "6060:6060"
+    command: ["clair", "-config", "/config/config.yaml"]
+    volumes:
+      - ./config.yaml:/config/config.yaml
+volumes:
+  clair-db-data:
+
+networks:
+  clairnet:
+
+
+Si nécessaire il sera possible de pull les images des deux en utilisant les commandes suivantes:
+docker pull quay.io/projectquay/clair:v4.7.2
+docker pull postgres:13
+
+
+On va également en plus d’ajouter à docker-compose les deux éléments, créer un fichier config.yaml que l’on va placer dans le même dossier et qui sera de la forme suivante:
+http_listen_addr: ":6060"
+log_level: "info"
+
+indexer:
+  connstring: host=clair-dblocalhost user=clair dbname=clair password=clair sslmode=disable
+  scanlock_retry: 10
+  layer_scan_concurrency: 5  
+  migrations: true
+
+matcher:
+  connstring: host=clair-db user=clair dbname=clair password=clair sslmode=disable
+
+notifier:
+  connstring: host=clair-db user=clair dbname=clair password=clair sslmode=disable
+  delivery_interval: 1m
+  poll_interval: 5m
+
+auth:
+  psk:
+    key: "bXlzZWNyZXRrZXk="  
+    iss: ["clairctl"]
+
+metrics:
+  name: "prometheus"
+
+On passe ensuite à l’ajout de clairctl qui permet d'analyser des images Docker pour trouver des failles de sécurité. Car par défaut, Clair ne comprend pas les images Docker directement : il attend des données bien préparées qu'on doit lui envoyer via des requêtes techniques.
+wget https://github.com/jgsqware/clairctl/releases/download/v1.2.8/clairctl-linux-amd64 -O clairctl
+
+
+Point de blocage:
+
+Mise en place multi-container:
+
+Clair nécessite un environnement avec une base PostgreSQL : cela demande une configuration Docker Compose non triviale.
+
+Défis pour faire fonctionner Clair en tant que client REST et gérer le lien avec PostgreSQL (variable d’environnement CLAIR_DATABASE_URL difficile à configurer).
+
+Scan d’images:
+
+Lancer un scan implique de bien comprendre le mécanisme de “Indexer” et “Matcher”, ce qui a été flou au départ.

in-toto.md

@@ -0,0 +1,20 @@
+Descriptif:
+in-toto est un framework de sécurité qui permet d’assurer l’intégrité de la chaîne de développement logiciel, du code source jusqu’au déploiement. Son objectif principal est de garantir que chaque étape d’un processus (comme le développement, les tests, la compilation, ou le déploiement) a bien été réalisée comme prévu, par les bonnes personnes et sans modification malveillante.
+Concrètement, in-toto fonctionne en définissant une supply chain (chaîne d'approvisionnement logicielle) sous forme de métadonnées cryptographiquement signées. Chaque acteur ou étape du pipeline (comme un développeur, un outil CI, ou un script de build) génère des preuves signées attestant de ce qui a été fait. À la fin, ces métadonnées sont vérifiées pour confirmer que le logiciel livré est bien celui qui a été construit en suivant toutes les règles définies au départ.
+Ce système est particulièrement utile pour se protéger contre les attaques sur la chaîne d'approvisionnement logicielle, comme celles qui injectent du code malveillant lors de la compilation ou dans une dépendance. in-toto est souvent utilisé en complément d'autres outils comme TUF ou Sigstore, pour renforcer la confiance dans les processus de build et de livraison continue.
+En résumé, in-toto permet de tracer et vérifier tout ce qui se passe dans une chaîne de production logicielle, garantissant que rien n’a été compromis entre le développement initial et le déploiement final.
+
+
+Point de blocage:
+
+Concepts peu documentés:
+
+Les notions de layout, keys, étapes de la supply chain et attestation sont peu connues et assez abstraites.
+
+Difficile de faire le lien concret entre in-toto et un projet réel sans exemple simple.
+
+Utilisation en ligne de commande:
+
+La création de clés (in-toto-keygen), la définition des étapes (in-toto-record start/end) et la finalisation (in-toto-verify) nécessitent une rigueur stricte dans les noms, chemins et signatures.
+
+Nombreux échecs à la vérification (in-toto-verify) dus à des erreurs subtiles (chemin relatif, étape manquante, etc).

inSpec.md

@@ -0,0 +1,62 @@
+InSpec
+Descriptif:
+InSpec est un framework open source développé par Chef qui permet d’écrire des tests d’infrastructure sous forme de code. Son but est de vérifier que les systèmes, les serveurs ou les conteneurs sont bien configurés selon les règles de sécurité, de conformité ou d’exploitation attendues. Ces tests peuvent porter sur la présence de paquets, les permissions de fichiers, la configuration d’un service, ou même les règles réseau.
+L’intérêt principal d’InSpec, c’est qu’il permet d’automatiser les audits de sécurité. Au lieu de faire les vérifications manuellement, on écrit des fichiers de tests déclaratifs, en Ruby, qui décrivent ce qui doit être présent ou interdit sur un système. C’est donc une approche “compliance-as-code”, où la conformité devient vérifiable de façon reproductible.
+Dans le cadre de notre projet, InSpec nous permet de nous assurer que nos services déployés dans Docker respectent certaines bonnes pratiques de sécurité, comme ne pas exposer de ports inutiles, avoir des permissions limitées, ou interdire l’accès en root à certains fichiers. On peut intégrer ces tests directement dans un pipeline CI/CD pour que chaque déploiement soit automatiquement validé.
+Code:
+On commence par créer une image personnalisé de InSpec avec un Dockerfile:
+FROM ruby:3.2
+RUN gem install inspec
+WORKDIR /share
+RUN inspec --version
+ENTRYPOINT ["inspec"]
+
+Dans le dossier où se trouve le Dockerfile:
+docker build -t custom-inspec .
+
+Créer un dossier pour profil InSpec pour la suite:
+mkdir inspec-profile
+cd inspec-profile
+
+Puis on initialise le profil ce qui va créer la structure du profil avec un dossier controls/
+docker run --rm -it -v "${PWD}:/share" custom-inspec init profile /share
+
+
+1. Écrire les contrôles (tests)
+Après avoir créé le profil InSpec avec :
+
+docker run --rm -it -v "${PWD}:/share" custom-inspec init profile /share
+
+
+On aura un dossier controls/ où l’on peut écrire les tests en Ruby. Par exemple, crée un fichier controls/example.rb avec un test simple :
+control 'ssh-1' do
+  impact 1.0
+  title 'Le service SSH doit être installé'
+  describe package('openssh-server') do
+    it { should be_installed }
+  end
+end
+
+
+
+2. Exécuter les tests localement
+Pour lancer les tests depuis le dossier de ton profil, utilise :
+
+docker run --rm -v "${PWD}:/share" custom-inspec exec /share
+
+Cela exécutera les tests dans le profil et donnera un rapport de conformité.
+
+
+Point de blocage:
+
+Création d’un profil:
+
+La commande inspec init profile fonctionne bien, mais la structure générée n’est pas évidente à adapter sans expérience en Ruby.
+
+Les fichiers controls/example.rb sont verbeux et la syntaxe des tests n’est pas intuitive sans exemples précis.
+
+Exécution des tests:
+
+Exécution avec Docker : il a fallu créer une image custom de InSpec (via Dockerfile) car l’image officielle ne couvrait pas tous.
+
+Montage de volume (-v "${PWD}:/share") sensible aux erreurs.

vault.md

@@ -0,0 +1,72 @@
+Descriptif:
+Vault est un outil développé par HashiCorp qui sert à sécuriser, stocker et contrôler l’accès aux secrets utilisés dans une infrastructure informatique, comme les mots de passe, les tokens, les clés API ou les certificats. Plutôt que de laisser ces informations sensibles traîner dans des fichiers de configuration ou dans le code, Vault les centralise dans un coffre-fort chiffré, accessible uniquement via des politiques d’accès bien définies.
+Ce qui le rend particulièrement puissant, c’est sa capacité à générer des secrets dynamiques, c’est-à-dire temporaires, comme des identifiants pour une base de données qui expirent automatiquement. Cela réduit fortement les risques de fuite ou d’utilisation abusive. Vault permet aussi la rotation automatique des secrets, ainsi qu’un suivi précis de qui accède à quoi, grâce à son système d’audit.
+Dans notre projet, Vault est utilisé pour sécuriser la gestion des secrets entre les différents services Docker. Plutôt que de définir les mots de passe dans les fichiers docker-compose, chaque service va interagir avec Vault pour récupérer ce dont il a besoin, de manière sécurisée et centralisée. C’est une solution fiable pour renforcer la sécurité d’une architecture distribuée.
+Code:
+On commence par télécharger l’image de vault pour l’utiliser avec dockers.
+On passe ensuite à la configuration du fichier vault config que l’on placera dans le dossier config, pour la configuration du vault qui ressemblera à ça :
+
+storage "file" {
+  path = "/vault/data"
+}
+
+listener "tcp" {
+  address     = "0.0.0.0:8200"
+  tls_disable = true
+}
+
+api_addr = "http://localhost:8200"
+ui = true
+
+
+Ensuite on passe à l’ajout de Vault au docker.compose.yml:
+
+ vault:
+    image: hashicorp/vault:latest
+    container_name: vault-new
+    ports:
+      - "8200:8200"
+      - "8201:8201"
+    environment:
+      VAULT_ADDR: "https://vault1.poc.thecloudgarage.com:8200"
+      VAULT_API_ADDR: "https://vault1.poc.thecloudgarage.com:8200"
+      VAULT_ADDRESS: "https://vault1.poc.thecloudgarage.com:8200"
+    volumes:
+      - ./logs:/vault/logs/:rw
+      - ./data:/vault/data/:rw
+      - ./config:/vault/config/:rw
+      - ./certs:/certs/:rw
+      - ./file:/vault/file/:rw
+    cap_add:
+      - IPC_LOCK
+    entrypoint: vault server -config=/vault/config/vault-config.hcl
+
+Puis on peut lancer le vault dans le terminal avec la commande suivante en se plaçant ici dans le dossier api:
+
+docker compose up 
+
+
+On peut ensuite stocker les secrets dans le vault avec la commande suivante ici par exemple on veut stocker le mot de passe pour le sécuriser:
+
+docker exec -it vault vault kv put secret/mysql password="tlc"
+
+
+Ensuite si l’on souhaite le lire par la suite la commande sera la suivante:
+
+docker exec -it vault vault kv get secret/mysql
+
+
+
+Point de blocage:
+
+Installation et lancement:
+
+Vault nécessite une phase d’initialisation et de déverrouillage (unseal) assez déroutante pour un premier usage.
+
+Comprendre le fonctionnement des “keys” d’unseal et du root token a demandé plusieurs essais.
+
+Utilisation avec Docker:
+
+Complexité pour exposer Vault en mode dev dans un container Docker et y accéder depuis l’extérieur.
+
+Problèmes de ports ou de configuration réseau liés à l’accessibilité de l’API Vault depuis d'autres services.