0% ont trouvé ce document utile (0 vote)
134 vues18 pages

Dev Sec Ops

is a DevSecOps

Transféré par

Khiari Aymen
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd
0% ont trouvé ce document utile (0 vote)
134 vues18 pages

Dev Sec Ops

is a DevSecOps

Transféré par

Khiari Aymen
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd

TEK-UP University

Rapport

Déploiement d’une application sur


Cloud avec une approche DevSecOps

Élèves : Encadrant :
Skander OURIMI Sahar Ben YAALA
Table des matières

Table des matières


Introduction Générale 2

1 Cadre générale 2
1.1 Concept DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Concept DevSecOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Notion du conteneur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.1 DOCKER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.2 KUBERNETES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Problématique du Projet 5
2.1 Contexte académique et technique . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Pourquoi DevSecOps pour ce projet ? . . . . . . . . . . . . . . . . . . . . . 5
2.3 Objectifs attendus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Contraintes et limites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Étapes de Réalisation du Projet 7


3.1 Architecture Cible sur AWS . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Déploiement de la Chaîne CI/CD . . . . . . . . . . . . . . . . . . . . . . . 7
3.3 Sécurisation de la Chaîne DevOps . . . . . . . . . . . . . . . . . . . . . . . 8
3.4 Mise en Place du Cluster Kubernetes . . . . . . . . . . . . . . . . . . . . . 9
3.5 Surveillance avec Prometheus et Grafana . . . . . . . . . . . . . . . . . . . 9
3.6 Tests et Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Conclusion Générale 13

Annexes 13

Bibliographie 17

1
1 Cadre générale

Introduction générale
Dans un contexte où les cycles de développement logiciel deviennent de plus en plus
rapides et complexes, les entreprises et les institutions académiques cherchent à automati-
ser, sécuriser et surveiller l’ensemble du cycle de vie de leurs applications. Le mouvement
DevOps, qui vise à fusionner les équipes de développement et d’exploitation, s’est pro-
gressivement enrichi pour donner naissance au DevSecOps, qui intègre dès le départ les
préoccupations de sécurité.
C’est dans cette dynamique que s’inscrit mon projet réalisé au sein de TEK-UP Uni-
versity, sous la supervision de Madame Sahar Ben Yaala. Il s’agit d’une mise en œuvre
complète d’une chaîne DevSecOps, depuis l’intégration continue jusqu’à la surveillance de
l’infrastructure, en passant par le déploiement automatisé sur un cluster Kubernetes.
Le projet a été mené par moi même Skander Ourimi. Mon objectif principal est de
construire une infrastructure sécurisée, automatisée et résiliente à l’aide d’instances EC2
sur AWS, en exploitant des outils standards de l’industrie comme Jenkins, SonarQube,
Kubernetes, Prometheus et Grafana.
À travers ce rapport, je vais présenter les étapes de conception et de déploiement de
mon infrastructure DevSecOps, les choix technologiques que j’ avais fait, les difficultés
rencontrées, ainsi que les résultats obtenus.

1 Cadre générale
1.1 Concept DevOps
Le terme DevOps résulte de la contraction de « Development » et « Operations ».
Il s’agit d’un ensemble de pratiques qui visent à réduire le temps de développement des
logiciels tout en assurant une livraison continue, stable et de qualité. Le but principal du
DevOps est de briser les silos traditionnels entre les développeurs (Dev) et les adminis-
trateurs systèmes (Ops) pour favoriser une meilleure collaboration tout au long du cycle
de vie des applications.
Cette méthodologie repose sur plusieurs piliers :
— L’intégration continue (CI) : qui consiste à automatiser la fusion du code dans
un référentiel partagé.
— La livraison continue (CD) : qui automatise le déploiement du code dans dif-
férents environnements.
— L’automatisation des tests : pour assurer la qualité du code à chaque étape.
— L’observabilité et la surveillance continue : pour anticiper les problèmes et
garantir la stabilité des services.

2
1 Cadre générale

1.2 Concept DevSecOps


Le DevSecOps est une extension naturelle du DevOps. Il intègre la sécurité dès les
premières étapes du développement logiciel. Plutôt que de traiter la sécurité comme une
étape à part en fin de cycle, le DevSecOps adopte une approche de « sécurité dès le départ
» (Security by Design).

Les objectifs principaux du DevSecOps sont :


— Intégrer des outils d’analyse de sécurité comme SonarQube dans la chaîne CI/CD.
— Garantir la conformité et la résilience des déploiements via des audits automatisés.
— Impliquer tous les acteurs (développeurs, administrateurs, sécurité) dans une dé-
marche collaborative et proactive.
Dans ce projet, j’ai mis en œuvre ces principes à travers une infrastructure basée sur
AWS, combinant Jenkins, SonarQube, Kubernetes, Prometheus et Grafana.

1.3 Notion du conteneur


1.3.1 DOCKER
Docker est une plateforme permettant de créer, déployer et exécuter des applications
dans des conteneurs. Un conteneur est une unité légère et portable qui contient tout ce
dont une application a besoin pour fonctionner : code, dépendances, bibliothèques, et
fichiers de configuration.
L’objectif principal de Docker est de garantir que l’application fonctionne de manière
identique, quel que soit l’environnement dans lequel elle est déployée (développement,
test, production).

Les avantages de Docker sont nombreux :


— Isolation des applications dans des conteneurs indépendants.
— Réduction des conflits entre les environnements.
— Démarrage rapide des applications.
— Meilleure portabilité et facilité de déploiement.

3
1 Cadre générale

1.3.2 KUBERNETES
Kubernetes, souvent abrégé K8s, est une plateforme d’orchestration de conteneurs
open-source développée initialement par Google. Il permet de gérer automatiquement le
déploiement, le dimensionnement, le réseau et la disponibilité des conteneurs.

Parmi les fonctionnalités clés de Kubernetes :


— Déploiement automatisé et mise à l’échelle des applications.
— Répartition de charge entre les conteneurs.
— Tolérance aux pannes et redémarrage automatique des conteneurs défaillants.
— Gestion centralisée des configurations et secrets.

Dans le cadre de notre projet, Kubernetes a été utilisé pour gérer le cycle de vie de
notre application conteneurisée, déployée sur un cluster de machines virtuelles sur AWS.
Le nœud master contrôle l’état global du cluster, tandis que le nœud worker héberge
les applications.

Figure 1 – Instance EC2 utilisée comme nœud Master du cluster Kubernetes

4
2 Problématique du Projet

2 Problématique du Projet
2.1 Contexte académique et technique
Ce projet s’inscrit dans le cadre de ma formation à TEK-UP University, sous la
supervision de Mme Sahar Ben YAALA. Il vise à mettre en pratique les compétences
acquises en ingénierie informatique et cybersécurité, à travers la conception et la mise
en œuvre d’une chaîne DevSecOps complète. D’un point de vue technique, j’ai évolué
dans un contexte où les entreprises recherchent des solutions à la fois agiles, automa-
tisées et sécurisées. Le projet adopte une démarche DevSecOps, en intégrant les outils
standards de l’industrie : Jenkins pour l’intégration continue, SonarQube pour l’analyse
de code, Kubernetes pour l’orchestration de conteneurs, et Prometheus/Grafana pour la
surveillance.

2.2 Pourquoi DevSecOps pour ce projet ?


Le choix du DevSecOps s’impose naturellement face aux exigences modernes de livrai-
son logicielle. Ce paradigme permet d’assurer à la fois la rapidité, la qualité, la sécurité et
la traçabilité du cycle de vie des applications. Il favorise l’automatisation des tâches répé-
titives, renforce la sécurité à chaque étape du développement, et permet un déploiement
fiable et rapide sur des environnements cloud comme AWS.

2.3 Objectifs attendus


L’objectif principal de ce projet est la conception et le déploiement d’une chaîne CI/CD
complète, sécurisée et monitorée dans un environnement cloud. Pour cela, j’ai mis en
œuvre les éléments suivants :
1. Installation d’un serveur Jenkins sur une instance EC2.
2. Intégration de SonarQube à Jenkins pour l’analyse de la qualité du code.
3. Automatisation du processus de build, de test et de déploiement.
4. Déploiement d’un cluster Kubernetes comprenant un nœud master et un nœud
worker.
5. Mise en place d’une solution de supervision avec Prometheus et Grafana.

5
2 Problématique du Projet

Figure 2 – Architecture globale de la chaîne DevSecOps déployée sur AWS

2.4 Contraintes et limites


Durant la réalisation du projet, plusieurs contraintes ont été rencontrées :
— Limitations de ressources matérielles et logicielles dans le cloud (quotas AWS,
performances EC2).
— Configuration manuelle et initialisation complexe de certains outils (ex : Jenkins,
SonarQube).
— Besoin d’assurer la cohérence et la sécurité de l’ensemble de la chaîne, malgré un
environnement distribué.
— Temps d’exécution parfois longs liés à la compilation, au déploiement, ou à la
collecte des métriques de monitoring.
Malgré ces défis, l’objectif du projet a été atteint grâce à une démarche itérative et une
bonne coordination entre les membres du groupe.

6
3 Étapes de Réalisation du Projet

3 Étapes de Réalisation du Projet


3.1 Architecture Cible sur AWS
Pour répondre aux exigences du projet, j’ai conçu une architecture distribuée sur
Amazon Web Services (AWS), composée de :
— Une instance EC2 hébergeant Jenkins et SonarQube.
— Deux instances EC2 pour le cluster Kubernetes (un nœud master et un nœud
worker).
— Une instance EC2 dédiée à la supervision avec Prometheus et Grafana.
Ces instances EC2 jouent le rôle de machines locales, me permettant de réaliser toutes
les étapes du projet comme si l’infrastructure était déployée en local. Cela simule un
environnement on-premise tout en tirant parti des ressources et de la scalabilité du cloud
AWS.

Figure 3 – Architecture cible sur AWS

3.2 Déploiement de la Chaîne CI/CD


J’ai commencé par installer Jenkins sur une instance EC2. Après configuration :
— SonarQube a été installé et intégré à Jenkins pour l’analyse de la qualité du code.
— Une pipeline CI/CD a été développée pour automatiser le processus de build, test,
analyse statique et déploiement.
— Plusieurs essais ont permis de stabiliser la pipeline et d’assurer son bon fonction-
nement.

Figure 4 – Interface Jenkins

7
3 Étapes de Réalisation du Projet

3.3 Sécurisation de la Chaîne DevOps


La sécurité a été intégrée dès le début du processus :
— Analyse de vulnérabilités dans le code avec SonarQube.
— Sécurisation des accès Jenkins (utilisateurs, mots de passe, ports, etc.).
— Règles de pare-feu strictes au niveau des groupes de sécurité AWS.

Figure 5 – Exemple de mesures de sécurité dans Jenkins et SonarQube

Figure 6 – Exemple de mesures de sécurité dans Jenkins et SonarQube

8
3 Étapes de Réalisation du Projet

3.4 Mise en Place du Cluster Kubernetes


Après la configuration de Jenkins, j’ai mis en place un cluster Kubernetes :
— Initialisation du nœud master avec kubeadm.
— Ajout du nœud worker.
— Mise en place du réseau de pods avec flannel.
Le cluster a été connecté à Jenkins via un plugin pour que les déploiements automatisés
puissent y être exécutés.

Figure 7 – Connexion entre le nœud master et le nœud worker

3.5 Surveillance avec Prometheus et Grafana


Pour assurer un suivi continu, une instance EC2 supplémentaire a été configurée pour
la supervision :
— Prometheus collecte les métriques du cluster.
— Grafana permet leur visualisation sous forme de tableaux de bord.
Cette infrastructure aide à détecter rapidement les anomalies et à optimiser les perfor-
mances.

Figure 8 – Surveillance des services avec Grafana

9
3 Étapes de Réalisation du Projet

3.6 Tests et Validation


Une fois toutes les composantes de l’infrastructure mises en place, plusieurs séries de
tests ont été effectuées pour valider la chaîne DevSecOps dans son ensemble. Ces tests
visaient à s’assurer de la stabilité, de la sécurité et de la bonne intégration des différents
outils entre eux.
— Validation de la pipeline CI/CD complète : Après avoir configuré Jenkins et
SonarQube, une pipeline a été créée afin d’automatiser les étapes de compilation,
d’analyse de code, de test et de déploiement. Plusieurs essais ont été nécessaires
pour corriger les erreurs de configuration initiales. Une fois stable, la pipeline s’exé-
cutait automatiquement à chaque push sur le dépôt GitHub.

Figure 9 – Pipeline Jenkins exécutée avec succès

10
3 Étapes de Réalisation du Projet

— Déploiement réussi sur Kubernetes : L’application a été empaquetée dans


une image Docker puis déployée sur le cluster Kubernetes via la pipeline. Des Pods
ont été créés automatiquement sur le nœud worker, et le service a été exposé avec
succès. Après plusieurs itérations, le processus de déploiement s’est avéré fiable et
reproductible.

Figure 10 – Vue des Pods déployés dans Kubernetes

— Surveillance et collecte des métriques : Grâce à Prometheus et Grafana, des


dashboards ont été mis en place pour visualiser en temps réel les performances
de l’application et du cluster. Les logs système, les métriques réseau, l’utilisation
CPU/mémoire des Pods, ainsi que l’état général du cluster étaient accessibles,
permettant une supervision continue.

Figure 11 – Dashboard Grafana affichant les métriques système

11
3 Étapes de Réalisation du Projet

Figure 12 – Dashboard Grafana affichant les métriques système

— Tests fonctionnels et techniques : Des tests manuels ont été réalisés pour
vérifier le bon fonctionnement de l’application déployée. Parallèlement, des tests
automatisés ont été intégrés dans la pipeline pour garantir la qualité logicielle à
chaque livraison.

Figure 13 – Exécution des tests fonctionnels et résultats

Ces étapes de validation ont permis de confirmer que l’architecture DevSecOps déployée
est fonctionnelle, résiliente et conforme aux attentes définies dans les objectifs initiaux du
projet.

12
3 Étapes de Réalisation du Projet

Conclusion Générale
Ce projet s’est inscrit dans une démarche pédagogique et technique visant à mettre en
œuvre une infrastructure DevSecOps complète, sécurisée et automatisée, déployée sur un
environnement cloud (AWS). À travers cette réalisation, j’ai consolidé mes connaissances
en ingénierie informatique, tout en développant des compétences concrètes en adminis-
tration système, orchestration de conteneurs, intégration continue, sécurité applicative et
supervision des services.
Grâce à une organisation progressive en plusieurs étapes, j’ai :
— Mis en place une chaîne CI/CD avec Jenkins et SonarQube, permettant d’assurer
une livraison continue de code de qualité.
— Déployé une application conteneurisée sur un cluster Kubernetes, garantissant la
portabilité, l’évolutivité et la résilience du service.
— Sécurisé les différentes étapes du pipeline de développement.
— Implémenté une infrastructure de surveillance avec Prometheus et Grafana, offrant
une visibilité en temps réel sur l’état du système.
Ce projet m’a permis de comprendre l’importance d’une approche DevSecOps dans le
monde professionnel actuel, où les cycles de développement doivent être rapides, fiables,
sécurisés et traçables.
Perspectives : des améliorations peuvent encore être envisagées, telles que :
— L’intégration d’alertes automatiques via des outils comme Alertmanager.
— L’extension du cluster Kubernetes pour prendre en charge davantage de charges
de travail.
— La mise en œuvre de tests de sécurité avancés (type DAST/SAST automatisés).
— L’ajout de GitOps pour automatiser le déploiement à partir de l’état défini dans
un dépôt Git.
En somme, cette expérience fut à la fois enrichissante et formatrice, me préparant
efficacement aux exigences du monde professionnel dans les domaines de la cybersécurité,
de l’automatisation et de l’architecture cloud.

Annexes
Pipeline CI/CD
La pipeline CI/CD automatisée est orchestrée avec Jenkins et comprend les étapes
suivantes : récupération du code source, analyse de la qualité avec SonarQube, scan de
sécurité avec OWASP Dependency Check et Trivy, construction et push de l’image Docker,
puis déploiement sur Kubernetes.
Cette pipeline garantit une intégration continue fiable et un déploiement sécurisé,
assurant ainsi la qualité et la robustesse de l’application. Voilà le jenkinsfile complet de
la pipeline CI/CD

13
3 Étapes de Réalisation du Projet

Jenkinsfile complet

14
3 Étapes de Réalisation du Projet

15
3 Étapes de Réalisation du Projet

16
Références

Bibliographie
Références
[1] Jenkins Documentation. Pipeline Syntax. Disponible sur : https://www.jenkins.
io/doc/book/pipeline/syntax/
[2] Docker. Docker Documentation. Disponible sur : https://docs.docker.com/
[3] Kubernetes. Official Documentation. Disponible sur : https://kubernetes.io/
docs/home/
[4] Prometheus. Monitoring System Documentation. Disponible sur : https://
prometheus.io/docs/introduction/overview/
[5] Grafana Labs. Grafana Documentation. Disponible sur : https://grafana.com/
docs/
[6]
[7] Amazon Web Services. AWS Documentation. Disponible sur : https://docs.aws.
amazon.com/ [Consulté le 20 mai 2025].

17

Vous aimerez peut-être aussi