Évaluations & Projet Certifiant : M2 DevOps - Mise en Application DevOps¶

Établissement : Sup de Vinci Promotion : Mastère DevOps — M2 (Session 2026-2027) Titre RNCP : RNCP 40165 - Bloc 5 (option) : Piloter l'alignement stratégique entre architectures et DevSecOps Contribution certifiante : Synthèse technique « Mise en œuvre d'une plateforme sécurisée » pour le Dossier écrit individuel du Bloc 5 (MSPR 4.1). Volume horaire : 35 heures (5 journées de 7 heures)

Modalités Globales de Validation & Barème¶

L'évaluation de ce module valorise à la fois l'appropriation personnelle des concepts d'ingénierie et la capacité à construire, éprouver et défendre en équipe une plateforme de production, preuves à l'appui :

pie title Répartition de la note finale du module (100%)
    "QCM Individuel Wayground (40 questions)" : 50
    "Projet Certifiant & Soutenance (trinôme, avec audit croisé)" : 50

1. Guide de l'Évaluation QCM (50%)¶

Philosophie de l'Épreuve¶

Ce questionnaire évalue vos réflexes d'ingénieurs Platform, SRE et DevSecOps face aux décisions qui font qu'une plateforme tient en production, et non votre capacité à réciter une documentation.

L'objectif est de valider votre maîtrise personnelle :

1. Du pilotage d'une usine logicielle sécurisée et du contrôle des changements (B5C1).
2. Des stratégies de durcissement des machines et de l'orchestrateur selon les standards de l'industrie (B5C4).
3. De la démonstration de la robustesse par le stress, la surcharge et l'injection de pannes (B5C3).
4. De l'identification automatique des composants défaillants et des causes racines, et de la documentation d'exploitation.

Référentiel des 8 Domaines de Révision¶

Les questions portent sur 8 domaines techniques, directement issus des présentations et des TP du module :

1. Usine Logicielle Sécurisée & Contrôle des Changements

• Quality Gates pilotées par les risques : Registre des risques, chaîne de traçabilité risque → contrôle → preuve.
• Supply chain : Signature Cosign keyless (OIDC, Fulcio, Rekor), attestation SBOM, niveaux SLSA.
• Promotion immuable : Build once, deploy many, référence d'image par digest plutôt que par tag.
• Contrôle des changements : Branches protégées, merge par Merge Request, pipeline au vert obligatoire, approbations et CODEOWNERS.
• GitOps comme registre d'audit : Pourquoi l'historique du dépôt d'état désiré fait foi lors d'un audit.

2. Hardening as Code des Machines

• Référentiels : CIS Benchmarks (niveaux 1 et 2), guide ANSSI BP-028, lien avec la PSSI.
• Ansible : Idempotence, --check --diff comme détection de dérive, ansible-lint.
• Gestion des écarts : Dérogations justifiées, tracées et compensées (cas de net.ipv4.ip_forward avec Docker et Kubernetes).
• Pièges réels : Ports publiés par Docker qui contournent UFW, chaîne DOCKER-USER.
• Audit : Indice de durcissement Lynis, OpenSCAP et ComplianceAsCode, limites d'un score.

3. Hardening de l'Orchestrateur & Conformité

• Pod Security Admission : Standards privileged, baseline et restricted, modes enforce, audit et warn.
• securityContext : Non-root, élévation de privilèges, capabilities, seccomp, système de fichiers en lecture seule.
• NetworkPolicies : Patron default deny en entrée et en sortie, réouverture explicite du DNS.
• Policy as Code : Kyverno vs OPA Gatekeeper, ValidatingPolicy et ImageValidatingPolicy (Kyverno 1.19), actions Audit et Deny.
• Secrets : Pourquoi le base64 n'est pas un chiffrement, Sealed Secrets et SOPS.
• Audit de conformité : kube-bench, Kubescape, matrice de conformité PSSI.

4. Observabilité Orientée SLO

• SLI, SLO, SLA : Savoir les distinguer sur un exemple concret.
• Error budget : Calcul du temps d'indisponibilité autorisé pour un objectif donné.
• Alerting par burn rate : Signification d'un burn rate, intérêt des fenêtres multiples, alertes sur symptômes plutôt que sur causes.
• Méthodes RED et USE : Signaux d'un service vs signaux d'une ressource.
• Probes : Rôles respectifs de liveness, readiness et startup.

5. Robustness Testing - Stress & Surcharge

• Types de tests : Charge nominale, stress, pic, endurance, et ce que chacun révèle.
• Thresholds k6 : Traduction des SLO en critères de réussite, code de retour en CI, abortOnFail.
• Ressources Kubernetes : Throttling CPU vs OOMKill, classes QoS et ordre d'éviction.
• Élasticité : Fonctionnement et délais du HPA, dépendance aux requests.
• PodDisruptionBudget : Ce qu'il protège (interruptions volontaires) et ce qu'il ne protège pas.

6. Chaos Engineering

• Principes : Hypothèse d'état stable, rayon d'impact, conditions d'arrêt, GameDay.
• Chaos Mesh : Choisir le bon type d'expérience (PodChaos, NetworkChaos, StressChaos, HTTPChaos).
• Perte de nœud : Tolérances not-ready et unreachable par défaut, répartition des réplicas.
• SPOF : Identifier un point de défaillance unique, le corriger et rejouer l'expérience.

7. Auto-remédiation & Causes Racines

• Couches de self-healing : Contrôleurs Kubernetes, selfHeal d'ArgoCD, rollback automatique par Argo Rollouts et AnalysisTemplate.
• Identification de la cause : Métriques kube-state-metrics (raison de terminaison, état d'attente), alertes portant component, cause et runbook_url.
• Garde-fous : Moindre privilège du remédiateur, actions bornées et journalisées, humain dans la boucle.

8. Knowledge Management & Audit Croisé

• Documentation d'exploitation : Runbooks, ADR, postmortems blameless, docs-as-code.
• Audit croisé : Règles d'engagement, constats prouvés, sévérité et recommandation.
• Preuves certifiantes : Ce qu'il faut fournir pour valider la B5C3 dans le Dossier écrit du Bloc 5 (MSPR 4.1).

2. Projet Certifiant & Soutenance Orale (50%)¶

Contexte Métier & Enjeux¶

Un an après l'industrialisation de sa pipeline CI/CD, SecurePay Solutions migre son API de paiement vers une plateforme conteneurisée. Le comité de direction a gelé la mise en production après une série d'incidents :

• Black Friday : deux heures d'indisponibilité sur saturation CPU, sans aucun mécanisme d'autoscaling.
• Perte d'un serveur : l'unique instance de l'API tournait sur le nœud tombé ; la reprise a été manuelle.
• Release défectueuse : une version renvoyant des erreurs 500 est restée 40 minutes en production, faute de rollback automatique.
• Diagnostic à l'aveugle : une heure d'investigation pour comprendre qu'un dépassement mémoire (OOMKill) était à l'origine de redémarrages en boucle.
• Audit PSSI défavorable : serveurs accessibles en SSH root par mot de passe, conteneurs exécutés en root, aucune politique d'admission, secrets en clair dans les manifests.

Votre Mission¶

En tant qu'équipe Platform & SRE, vous devez livrer une plateforme de production sécurisée par construction, durcie selon les standards de l'industrie, et dont la résistance aux pannes est démontrée par des preuves. Le comité ne lèvera le gel qu'au vu de ces preuves.

Chaque trinôme importe les deux dépôts de départ dans son groupe GitLab : le code applicatif d'une part, le squelette de la plateforme (bootstrap, structure GitOps, modèles de documentation) d'autre part :

git clone https://github.com/Momotoculteur/securepay-api.git
git clone https://github.com/Momotoculteur/securepay-platform.git

Architecture Cible¶

flowchart LR
    DEV["Merge Request"] --> CI["Pipeline securepay-api\nGitleaks · Tests · SAST · Build\nTrivy · SBOM · DAST · Cosign"]
    CI -->|"MR de promotion\n(digest signé)"| GITOPS["securepay-platform\n(état désiré)"]
    GITOPS -->|"pull"| ARGO["ArgoCD"]
    subgraph VM["VM securepay-prod (Ubuntu 24.04 durcie par Ansible)"]
        subgraph K3D["Cluster k3d"]
            ARGO --> KYV{"Admission\nPSA + Kyverno"}
            KYV -->|"conforme et signé"| API["API SecurePay\nRollout + HPA + PDB"]
            KYV -.->|"refusé"| REJ["Pod root, image non signée,\ntag latest"]
            MON["Prometheus · Alertmanager · Grafana"] --> API
            CHAOS["Chaos Mesh"] -.->|"pannes injectées"| API
        end
    end
    K6["k6"] -->|"charge"| API
    MON -->|"alerte composant + cause"| NOTIF["Notification\n+ diagnostic + runbook"]

Spécifications Techniques Attendues¶

1. Usine Logicielle Sécurisée & Contrôle des Changements (Compétence B5C1)

• Registre des risques (docs/risques.md) : au moins 8 risques STRIDE, chacun relié à un contrôle et à une preuve. Chaque Quality Gate de la pipeline doit être justifiée par un risque du registre.
• Pipeline securepay-api : détection de secrets bloquante, tests avec rapport JUnit et couverture, SAST avec Quality Gate bloquante, build multi-stage non-root avec BuildKit, scan trivy image bloquant sur CRITICAL avec une image Trivy épinglée, SBOM CycloneDX, DAST ZAP sur l'API lancée en service CI.
• Anomalies du dépôt de départ corrigées (eval(), secret Stripe en dur et révoqué, dépendances vulnérables, en-têtes HTTP de sécurité).
• Signature Cosign de l'image par son digest (keyless via OIDC GitLab, ou paire de clés dont la clé privée est stockée en variable Masked et Protected) et attestation du SBOM.
• Promotion GitOps : la pipeline ouvre une Merge Request sur securepay-platform avec le nouveau digest ; aucune mise en production ne passe par kubectl.
• Branches main protégées sur les deux dépôts : push direct interdit, merge par MR uniquement, pipeline au vert obligatoire.

2. Hardening as Code des Machines (Compétence B5C4)

• VM securepay-prod provisionnée par cloud-init et durcie par un playbook Ansible versionné (ansible/), aligné sur le CIS Benchmark Ubuntu 24.04 niveau 1 et le guide ANSSI BP-028 : SSH, comptes et sudo, pare-feu, sysctl, auditd, mises à jour de sécurité automatiques, AppArmor, services inutiles désactivés.
• Idempotence démontrée (deuxième exécution à changed=0) et contrôle de dérive par --check --diff.
• ansible-lint exécuté dans la pipeline de securepay-platform.
• Audit Lynis avant/après avec indice de durcissement. Chaque recommandation non appliquée fait l'objet d'une dérogation justifiée (ex : net.ipv4.ip_forward requis par Docker et Kubernetes) avec sa mesure compensatoire.

3. Hardening de l'Orchestrateur & Conformité PSSI (Compétence B5C4)

• Namespace applicatif en Pod Security Admission restricted (enforce) et securityContext complet sur l'API.
• NetworkPolicies en refus par défaut (entrée et sortie), avec des ouvertures explicites et justifiées.
• Kyverno déployé par ArgoCD, politiques bloquantes (action Deny) : interdiction de root et du mode privilégié, requests/limits et probes obligatoires, tag latest interdit, vérification de la signature des images. Politiques testées en CI (kyverno apply sur les manifests rendus).
• Aucun secret en clair dans Git (Sealed Secrets ou SOPS), y compris l'imagePullSecret du registre.
• Audits kube-bench et Kubescape (ou trivy k8s --compliance) avant/après.
• Matrice de conformité PSSI (docs/conformite.md) : exigence → contrôle → outil → preuve → statut.

4. Observabilité Orientée SLO (prérequis de la Compétence B5C3)

• API instrumentée (prom-client) : débit, erreurs et latence par route et par code HTTP.
• Probes liveness, readiness et startup, et arrêt propre sur SIGTERM.
• SLO formalisés et alertés : disponibilité 99,5 % et p95 < 300 ms sur les routes de paiement, alertes burn rate multi-fenêtres.
• Dashboard Grafana RED + error budget ; Alertmanager branché sur au moins un canal de notification.

5. Robustness Testing - Stress & Surcharge (Compétence B5C3)

• Scénarios k6 versionnés (tests/robustness/) : charge nominale, stress par paliers jusqu'à la rupture, pic, endurance. Thresholds dérivés des SLO.
• HPA (2 à 6 réplicas) et PDB : scale-out et retour à l'état nominal prouvés.
• Surcharge CPU et mémoire de la machine (stress-ng) et d'un pod (limite mémoire trop basse puis redimensionnée).
• Point de rupture mesuré : débit maximal tenu sous SLO, et goulot d'étranglement identifié.

6. Chaos Engineering - Injection de Pannes (Compétence B5C3)

• Chaos Mesh déployé par ArgoCD, ciblage restreint au namespace applicatif.
• Au moins 5 expériences versionnées (chaos/) et jouées sous charge, couvrant obligatoirement : la perte de pods, la perte d'un nœud, la coupure d'un service critique, une dégradation réseau (latence ou perte) et un stress de ressources.
• Pour chaque expérience : hypothèse d'état stable, condition d'arrêt, résultat mesuré, impact sur le SLO, preuve et action corrective.
• SPOF identifiés et corrigés (réplicas, répartition sur les nœuds, tolerationSeconds).

7. Auto-remédiation & Causes Racines (critère RNCP : « L'automatisation identifie les composants défaillants et établit la cause principale de la défaillance »)

• Alertes qualifiant la cause (OOMKilled, CrashLoopBackOff, ImagePullBackOff, réplicas indisponibles, nœud NotReady, HPA au maximum, burn rate) et portant les labels component et cause ainsi qu'une annotation runbook_url.
• Rollback automatique d'une release défectueuse (Argo Rollouts canary avec AnalysisTemplate Prometheus).
• Réconciliation GitOps active (selfHeal, prune) et dérive manuelle corrigée.
• Diagnostic automatique joint à la notification (événements, derniers logs, k8sgpt analyze).
• Chaîne complète démontrée : panne → détection → cause identifiée → remédiation → retour au SLO, avec temps de rétablissement mesuré.

8. Documentation d'Exploitation (Knowledge Management)

• README.md d'exploitation : architecture, prérequis, bootstrap de bout en bout depuis un poste vierge.
• Un runbook par alerte (docs/runbooks/), exécutable par une personne extérieure à l'équipe.
• Au moins un ADR (docs/adr/) pour un choix structurant (ex : Kyverno vs Gatekeeper, Sealed Secrets vs SOPS).
• Un postmortem blameless d'un incident simulé pendant le GameDay.
• Dossier de preuves (docs/preuves/) : chaque preuve est nommée AAAA-MM-JJ_HHMM_<scenario>.<ext> et indexée dans docs/preuves/README.md (exigence, scénario, preuve, résultat).

Organisation des Dépôts Attendue¶

Le dépôt de départ securepay-platform fournit cette structure, un bootstrap fonctionnel et des marqueurs TODO [Jx] indiquant le travail attendu à chaque jalon.

securepay-platform/
├── README.md                  # Guide d'exploitation et bootstrap
├── bootstrap/                 # cloud-init, création du cluster k3d, installation d'ArgoCD
├── ansible/                   # Inventaire, rôles et playbook de durcissement
├── apps/                      # Applications ArgoCD (app-of-apps)
├── charts/securepay-api/      # Chart Helm de l'API (Rollout, HPA, PDB, NetworkPolicies)
├── policies/                  # Politiques Kyverno et tests associés
├── observability/             # Valeurs de la stack, PrometheusRules, dashboards
├── chaos/                     # Expériences et Workflow Chaos Mesh
├── tests/robustness/          # Scénarios k6
└── docs/
    ├── risques.md             # Registre des risques
    ├── conformite.md          # Matrice de conformité PSSI
    ├── resilience.md          # Rapport de résilience (stress, surcharge, chaos)
    ├── runbooks/
    ├── adr/
    ├── postmortems/
    ├── audit/                 # Rapport d'audit croisé reçu
    └── preuves/               # Dossier de preuves horodatées

Jalons du Projet¶

Livrables Attendus¶

Chaque trinôme doit fournir :

1. Avant le jour 5 à 09h00 : les deux dépôts gelés au tag v1.0.0-audit, accessibles en lecture à l'intervenant et au trinôme auditeur.
2. Avant le jour 5 à 13h30 :
   • Les dépôts finaux au tag v1.0.0 : code, pipelines, Ansible, chart, politiques, expériences, scénarios k6 et documentation décrits ci-dessus.
   • Le dossier de preuves complet et indexé.
   • Le rapport d'audit croisé rédigé sur la plateforme auditée, déposé par MR dans le dépôt de l'équipe auditée.
   • La synthèse technique individuelle (3 à 5 pages PDF, une par étudiant) « Mise en œuvre d'une plateforme sécurisée », directement exploitable pour le Dossier écrit individuel du Bloc 5 (MSPR 4.1) : architecture, contrôles alignés sur les risques, stratégie de durcissement, preuves de robustesse (B5C3) et analyse des causes racines.
   • Le support de soutenance : 8 à 10 slides synthétiques.

Audit Croisé Peer-to-Peer (Jour 5 - Matin)¶

Chaque trinôme audite la plateforme d'un autre trinôme (attribution circulaire communiquée en fin de jour 4), sur les dépôts gelés et en direct sur le poste de l'équipe auditée.

Règles d'engagement :

• Les actions se limitent au namespace applicatif et aux contrôles listés dans la grille ; aucune destruction de données, de VM ou de dépôt.
• L'équipe auditée est présente, et chaque action est annoncée puis tracée.
• Un constat sans preuve reproductible (commande, sortie, capture horodatée) n'est pas recevable.

Grille d'audit :

Chaque constat est consigné avec sa sévérité (critique, majeure, mineure), sa preuve et une recommandation. L'équipe auditée remédie les constats critiques et majeurs avant 13h30, ou documente une dérogation argumentée.

Modalités de la Soutenance Orale (Jour 5 - Après-midi)¶

• Durée totale : 25 minutes par trinôme.
  • 15 minutes de présentation et Démonstration Live :
    • Présentation synthétique de l'architecture, des risques et des contrôles associés (5 min).
    • Démonstration en direct (10 min) :
      • 1. Passage d'une modification de bout en bout : MR, pipeline, promotion, synchronisation ArgoCD.
      • 1. Scénario de panne sous charge : l'intervenant choisit une expérience dans le catalogue du trinôme et la déclenche pendant un test k6. Le trinôme doit prouver en direct que le SLO tient (ou se dégrade de façon maîtrisée), que l'alerte identifie le composant et la cause, et que la remédiation s'exécute.
  • 10 minutes d'échanges techniques :
    • Questions individuelles de l'intervenant sur les choix d'implémentation, les dérogations, les résultats de l'audit croisé et la conformité RNCP.

Grille d'Évaluation & Barème (/20)¶

Modulation individuelle : la note de groupe est modulée de ± 2 points par étudiant selon ses réponses aux questions individuelles, sa contribution visible dans l'historique Git et la qualité de sa synthèse technique individuelle.

Bonus (plafonnés à + 2 points, note finale plafonnée à 20)¶