Pipeline CI/CD¶

Concepts fondamentaux¶

Qu'est-ce que la CI/CD ?¶

La CI/CD (Continuous Integration / Continuous Delivery) est un ensemble de pratiques DevOps qui automatisent le cycle de vie du logiciel, de l'ecriture du code jusqu'a son deploiement en production.

Concept	Definition	Objectif
Continuous Integration (CI)	Chaque commit declenche automatiquement la compilation, les tests et l'analyse du code	Detecter les erreurs au plus tot, maintenir un code toujours deployable
Continuous Delivery (CD)	Le code valide est automatiquement prepare pour le deploiement, avec approbation manuelle	Reduire le temps entre le developpement et la mise en production
Continuous Deployment	Le deploiement en production est entierement automatique apres validation	Eliminer les interventions manuelles, deployer plusieurs fois par jour

Approche Shift-Left¶

Le Shift-Left consiste a integrer la securite le plus tot possible dans le cycle de developpement, plutot qu'en fin de chaine. Chaque defaut detecte tot coute exponentiellement moins cher a corriger.

flowchart LR
    subgraph SHIFT["Shift-Left : securite integree a chaque etape"]
        direction LR
        CODE["Code"] --> SAST["SAST<br/>SonarQube"]
        SAST --> SECRETS["Secrets<br/>GitLeaks"]
        SECRETS --> BUILD["Build<br/>Docker"]
        BUILD --> SCAN["Scan<br/>Trivy"]
        SCAN --> DAST["DAST<br/>OWASP ZAP"]
        DAST --> DEPLOY["Deploy"]
    end

    style SAST fill:#E65100,color:#fff
    style SECRETS fill:#B71C1C,color:#fff
    style SCAN fill:#1565C0,color:#fff
    style DAST fill:#7B1FA2,color:#fff

Etapes du pipeline¶

Vue d'ensemble¶

Le pipeline CI/CD implemente 5 etapes de validation avant tout deploiement :

flowchart TB
    COMMIT["Commit Git"] --> S1

    subgraph S1["1. Qualite du code"]
        SQ["SonarQube SAST<br/>Analyse statique"]
    end

    subgraph S2["2. Detection de secrets"]
        GL["GitLeaks<br/>Scan regex"]
    end

    subgraph S3["3. Securite conteneurs"]
        TR["Trivy<br/>Scan CVE images"]
    end

    subgraph S4["4. Tests dynamiques"]
        ZAP["OWASP ZAP<br/>DAST web"]
    end

    subgraph S5["5. Deploiement"]
        DEP["Deploy staging<br/>puis production"]
    end

    S1 --> S2 --> S3 --> S4 --> S5

    style S1 fill:#E65100,color:#fff
    style S2 fill:#B71C1C,color:#fff
    style S3 fill:#1565C0,color:#fff
    style S4 fill:#7B1FA2,color:#fff
    style S5 fill:#2E7D32,color:#fff

Outils de securite¶

SonarQube -- SAST (Static Application Security Testing)¶

SonarQube analyse le code source sans l'executer pour detecter les problemes de qualite et de securite.

Capacite	Description
Vulnerabilites	Injection SQL, XSS, path traversal, deserialization
Code smells	Code duplique, complexite cyclomatique, methodes trop longues
Bugs	Null pointer, resource leak, dead code
Dette technique	Estimation du temps necessaire pour corriger tous les problemes
Quality Gate	Seuil configurable (0 vulnerabilite critique, couverture > 80%)

Fonctionnement¶

SonarQube construit un AST (Abstract Syntax Tree) du code source et applique des regles de detection. Chaque probleme est classe par severite (Blocker, Critical, Major, Minor, Info) et associe a une categorie CWE (Common Weakness Enumeration).

GitLeaks -- Detection de secrets¶

GitLeaks scanne le code et l'historique Git a la recherche de secrets exposes (cles API, mots de passe, tokens, certificats prives).

Type de secret	Pattern detecte	Exemple
Cles API	Regex sur les formats connus (AWS, GCP, Azure)	AKIA... (AWS Access Key)
Mots de passe	Variables password, passwd, secret en dur	password = "admin123"
Tokens	Patterns JWT, OAuth, GitLab tokens	glpat-... (GitLab Personal Access Token)
Cles privees	Blocs PEM -----BEGIN PRIVATE KEY-----	Cles SSH, certificats TLS

Fonctionnement¶

GitLeaks utilise des expressions regulieres configurables pour identifier les motifs de secrets dans le code. Il scanne non seulement les fichiers actuels mais aussi l'historique Git complet, car un secret commite puis supprime reste accessible dans l'historique.

Trivy -- Securite des conteneurs¶

Trivy (Aqua Security) scanne les images Docker pour identifier les vulnerabilites connues (CVE) dans les paquets systeme et les dependances applicatives.

Capacite	Description
CVE scanning	Identification des vulnerabilites connues dans les paquets OS
Dependances	Analyse des librairies applicatives (npm, pip, gem, go modules)
Misconfiguration	Detection des erreurs de configuration Dockerfile
SBOM	Generation de la nomenclature logicielle (Software Bill of Materials)
Severite	Classification CVSS (Critical, High, Medium, Low)

Fonctionnement¶

Trivy decompresse chaque couche (layer) de l'image Docker, inventorie tous les paquets installes et les compare avec les bases de vulnerabilites (NVD, Red Hat, Debian, Alpine). Le scan est rapide (quelques secondes) et peut etre integre directement dans le pipeline CI.

OWASP ZAP -- DAST (Dynamic Application Security Testing)¶

OWASP ZAP (Zed Attack Proxy) teste les applications web en cours d'execution en simulant des attaques reelles.

Type de test	Description
Spider	Cartographie automatique de l'application (pages, formulaires, API)
Active scan	Injection de payloads malveillants (SQLi, XSS, LFI, SSRF)
Passive scan	Analyse des reponses HTTP (headers de securite, cookies, CORS)
API scan	Test des endpoints REST/GraphQL via OpenAPI/Swagger
Authentication	Tests avec et sans authentification pour verifier les controles d'acces

Difference SAST vs DAST¶

Critere	SAST (SonarQube)	DAST (OWASP ZAP)
Quoi	Analyse le code source	Analyse l'application en execution
Quand	Avant la compilation	Apres le deploiement (staging)
Acces	Necessite le code source	Necessite l'URL de l'application
Forces	Couverture complete du code, detection precise	Detecte les problemes de runtime et de configuration
Faiblesses	Faux positifs, ne voit pas les problemes de runtime	Couverture limitee aux chemins atteints

Strategies de deploiement¶

Blue/Green¶

Le deploiement Blue/Green utilise deux environnements identiques. Le trafic est bascule instantanement de l'ancien (Blue) vers le nouveau (Green) :

flowchart LR
    LB["Load Balancer"] -->|100% trafic| BLUE["Blue<br/>(v1 -- actif)"]
    LB -.->|0% trafic| GREEN["Green<br/>(v2 -- standby)"]

    LB2["Load Balancer"] -.->|0% trafic| BLUE2["Blue<br/>(v1 -- standby)"]
    LB2 -->|100% trafic| GREEN2["Green<br/>(v2 -- actif)"]

    BLUE -->|"Bascule instantanee"| GREEN2

    style BLUE fill:#1565C0,color:#fff
    style GREEN fill:#2E7D32,color:#fff
    style BLUE2 fill:#1565C0,color:#fff
    style GREEN2 fill:#2E7D32,color:#fff

Avantage	Inconvenient
Rollback instantane (rebascule vers Blue)	Necessite le double de ressources
Zero downtime	Complexite de synchronisation des donnees
Test complet avant bascule	Cout plus eleve

Canary¶

Le deploiement Canary envoie progressivement un pourcentage croissant du trafic vers la nouvelle version :

Etape	Trafic v1	Trafic v2	Duree	Action
1	95%	5%	15 min	Monitoring des metriques
2	80%	20%	30 min	Verification des erreurs
3	50%	50%	1h	Validation performance
4	0%	100%	-	Bascule complete

Si une anomalie est detectee a n'importe quelle etape, le trafic est immediatement redirige a 100% vers v1 (rollback automatique).

Rolling update¶

Le Rolling update remplace les instances une par une, en maintenant toujours un nombre minimum d'instances saines. C'est la strategie par defaut de Docker Compose et Kubernetes.

GitLab CI¶

Architecture¶

Le pipeline est defini dans le fichier .gitlab-ci.yml a la racine de chaque projet :

Concept	Description
Stages	Etapes sequentielles du pipeline (build, test, scan, deploy)
Jobs	Taches executees dans un stage (peuvent etre paralleles au sein d'un stage)
Runners	Machines qui executent les jobs (VMs dediees VLAN 114)
Artifacts	Fichiers produits par un job et transmis aux jobs suivants
Cache	Fichiers reutilises entre pipelines pour accelerer l'execution
Environments	Cibles de deploiement (staging, production) avec historique

Integration Vault¶

Les pipelines recuperent les secrets et certificats TLS directement depuis HashiCorp Vault via son API, sans stocker de credentials dans les variables GitLab :

sequenceDiagram
    participant GL as GitLab Runner
    participant VL as Vault (10.15.100.74)
    participant NX as Nexus (10.15.100.65)
    participant TG as Cible deploiement

    GL->>VL: 1. Authentification JWT (token GitLab)
    VL->>GL: 2. Token Vault temporaire (TTL 1h)
    GL->>VL: 3. Lecture secrets (KV) + certificat TLS (PKI)
    VL->>GL: 4. Secrets + certificat (TTL 24h)
    GL->>NX: 5. Pull image Docker signee
    NX->>GL: 6. Image verifiee
    GL->>TG: 7. Deploiement avec secrets injectes

Methode d'authentification¶

Etape	Detail
1. JWT	GitLab emet un JWT signe contenant le projet, la branche et le pipeline ID
2. Vault Auth	Vault verifie le JWT via la methode jwt auth backend
3. Policy	Vault applique une policy Vault qui limite l'acces aux secrets du projet
4. Secrets	Le runner lit les secrets autorises (KV) et demande des certificats (PKI)
5. TTL	Tous les secrets ont une duree de vie limitee (1h pour les tokens, 24h pour les certificats)

Infrastructure CI/CD¶

Composant	IP	VLAN	Role
GitLab CE	10.15.100.71	106 (Infra)	Forge logicielle, registre de conteneurs, CI/CD
Nexus OSS	10.15.100.65	106 (Infra)	Registre Docker, proxy RPM/npm/PyPI, stockage artifacts
GitLab Runners	VLAN 114	114 (Dev)	Execution des jobs CI/CD (machines dediees)
SonarQube	10.15.100.72	106 (Infra)	Analyse statique du code (SAST)
Vault	10.15.100.74	106 (Infra)	Gestion des secrets et certificats pour les pipelines

Workflow complet¶

flowchart TB
    DEV["Developpeur<br/>git push"] --> GL["GitLab<br/>10.15.100.71"]

    GL --> S1["Stage 1: Build"]
    S1 --> S1a["Compilation / Build image Docker"]
    S1a --> S1b["Push image vers Nexus"]

    S1b --> S2["Stage 2: Test"]
    S2 --> S2a["Tests unitaires"]
    S2a --> S2b["Tests d'integration"]

    S2b --> S3["Stage 3: Security Scan"]
    S3 --> S3a["SonarQube (SAST)"]
    S3 --> S3b["GitLeaks (secrets)"]
    S3 --> S3c["Trivy (CVE conteneurs)"]

    S3a & S3b & S3c --> S4["Stage 4: Dynamic Test"]
    S4 --> S4a["OWASP ZAP (DAST)"]

    S4a --> S5["Stage 5: Deploy Staging"]
    S5 --> S5a["Deploiement staging"]
    S5a --> S5b["Tests de fumee"]

    S5b --> S6["Stage 6: Deploy Production"]
    S6 --> S6a["Approbation manuelle"]
    S6a --> S6b["Deploiement production"]
    S6b --> S6c["Verification sante"]

    S6c --> MON["Monitoring<br/>Zabbix + Wazuh"]

    style S3 fill:#B71C1C,color:#fff
    style S6a fill:#FF9800,color:#fff
    style MON fill:#2E7D32,color:#fff