Documentation technique -

Plateforme DevSecOps

Opérationnalisation de la loi 55.19

Implémentation du module de Consentement
Citoyen

Octobre 2022
Table des matières
1. Avant-propos ------------------------------------------------------------------------------------------------------------- 2
2. Principe de la solution-------------------------------------------------------------------------------------------------- 3
3. Architecture technique------------------------------------------------------------------------------------------------- 7
4. Architecture technique------------------------------------------------------------------------------------------------- 9
5. Architecture logicielle------------------------------------------------------------------------------------------------- 12
6. Code source-------------------------------------------------------------------------------------------------------------- 13
7. Load Balancer----------------------------------------------------------------------------------------------------------- 14
8. Plateforme de déploiement Rancher ----------------------------------------------------------------------------16
9. Installation---------------------------------------------------------------------------------------------------------------- 17
10. Usine de développement--------------------------------------------------------------------------------------------- 25
11. Hors Prod & Prod ------------------------------------------------------------------------------------------------------ 28
12. Pipeline de CI------------------------------------------------------------------------------------------------------------ 35
13. CD--------------------------------------------------------------------------------------------------------------------------- 41
14. Migration du code source------------------------------------------------------------------------------------------- 43

1
1. Avant-propos
Ce manuel décrit l’architecture technique et logicielle de la plateforme DevSecOps Marsa avec la procedure d’installation de
ces composants

2
2. Principe de la solution
DevSecOps
Adopter une implémentation GitOps pour supporter les principes DevSecOps

La chaine CI (Continuous Intégration) est supporté par la solution CI de Gitlab (Gitlab-CI)

La chaine CD (Continuous Deployment) est supporté par la solution GitOps intégré en natif dans Rqncher (Rancher-Fleet)

La sécurité sera intégré aux différents etapes de la chaine CI-CD

· Build avec un contrôle de code et des dépendances

· Push des artifacts par la scan des images après build par le registre des images Harbor

· Runtime des Pods avec l’opérateur Neuvector intégré à Rancher

GitOps
· Le développeur commit les développements et crée un Merge Request de configuration

· la chaîne CI build, valide,exécute les tests auto, package et publie les artifacts et le configs

· le DevOps valide le Merge Request et commit les configurations

· l’opérateur CD synchronise les artifacts (Images Docker) et les configuration entre le Git et le cluster de
déploiement Kubernetes

Figure1 : principe GitOps

3
IaC (Infrastructue As Code)

La plateforme sera provisionné avec des scripts Ansible pour automatiser et fiabiliser les installations

Gestion de configuration avec Ansible

Les installations des environnements Prod et Hors Prod seront automatisés avec des scripts Ansible qui définit les rôles
nécessaires pour installer les composants de Rancher (RKE2 local, RKE2 Downstream et Rancher) et les composants de
la software Factory (Gitlab, Runner, Harbor, Sonar, etc...)

Les scripts Ansible utilise des inventaires spécifiques à chaque environnements pour réutiliser les mêmes rôles pour les
installations des différents environnements.

Figure2 : gestion de configuration avec Ansible

Log
La plateforme sera provisionné avec des scripts Ansible pour automatiser et fiabiliser les installations

Monitoring
Le monitoring de l’environnement de Prod sera implémenté avec le stack de monitoring Prometheus, Garafana et
AlertManager

Stockage
Le stockage des composants statefull sera de type block avec l’operateur native à rancher Longhorm

4
Cluster management
La solution Rancher sera mise en place pour le cluster Management des containers

Figure3 : architecture de Rancher

Figure4 : fonctions de Rancher

Distribution Rancher
Rancher supporte en natif deux distributions Kubernetes RKE2 qui est basée sur containerd et RKE basée sur le daemon
dockerd. étant donné que Redhat8 ne supporte pas dockerd, notre choix est porté sur RKE2 qui est compatible avec
Redhat8 à travers son daemon containerd

Clusters
· Mise en place d’un cluster pour le Hors Prod (Dev et Recette)
· Mise en place d’un cluster pour la Prod
· Mise en place d’un cluster pour les outils de Software Factory
· Mise en place d’un cluster pour Rancher Management

5
Organisation des projets
Sous Rancher il est possible de gérer plusieurs projets dans le même cluster ou chaque projet peut inclure plusieurs
applications organisés en des « Namespaces », pour chaque projet est associé des droits d’accès et un Quota en terme de
ressource (CPU, mémoire) qui lui sont spécifiques, ce qui garantit un séparation logique entre les projets ([Link], les
ressources dédiés à l’UDD seront contrôlés par le Quota définit pour ce projet et les personnes autorisés seront définit selon
les règles d’accès définis pour ce projet).

6
3. Architecture technique
Principe

Figure3 : Architecture rancher

Organisation des clusters

· La plateforme est composé de 4 clusters: cluster Prod , cluster Hors Prod (Dev, Recette), cluster pour le rancher
Management et cluster UDD

· Chaque cluster applicatif Prod, Dev et Recette aura son propore

o gestionnaire de persistence (longhorm),

o operateur CD (Fleet),

o operateur de sécurité (Neuvector),

o stack de log

o stack de monitoring

· Les outils CI sont intégrés dans le cluster UDD

· Les nodes sont des Vms avec du Redhat8

7
Figure4 : Clusters Rancher

8
4. Architecture technique
Le cluster Rancher intégré le contrôleur et le worker dans chaque node du cluster.

Figure5 : Clusters Rancher

Ressource VM :
Cluster machine VM CPU Mem Storage OS

Rancher NOD_RCH_1 4 8 50 RHEL 8.6

NOD_RCH_2 4 8 50 RHEL 8.6

NOD_RCH_3 4 8 50 RHEL 8.6

Prod NOD_CTRL_PRD_1 4 8 50 RHEL 8.6

NOD_CTRL_PRD_2 4 8 50 RHEL 8.6

NOD_CTRL_PRD_3 4 8 50 RHEL 8.6

NOD_WRK_PRD_1 8 16 250 RHEL 8.6

NOD_WRK_PRD_2 8 16 250 RHEL 8.6

NOD_WRK_PRD_3 8 16 250 RHEL 8.6

9
 NOD_WRK_PRD_4 8 16 250 RHEL 8.6

NOD_WRK_PRD_5 8 16 250 RHEL 8.6

Hors Prod NOD_CTRL_HorsPRD_1 4 8 50 RHEL 8.6

NOD_WRK_HorsPRD_1 8 16 200 RHEL 8.6

NOD_WRK_HorsPRD_2 8 16 200 RHEL 8.6

NOD_WRK_HorsPRD_3 8 16 200 RHEL 8.6

UDD NOD_CTRL_UDD_1 4 8 50 RHEL 8.6

NOD_WRK_UDD_1 12 16 350 RHEL 8.6

NOD_WRK_UDD_2 12 16 350 RHEL 8.6

NOD_WRK_UDD_3 12 16 350 RHEL 8.6

machine VM_JUMP 2 2 40 Linux + GUI

Jump mode

Load DG-DEVSECOPS-NLB1 4 8 50 RHEL 8.6

Balancer

DG-DEVSECOPS-NLB1 4 8 50 RHEL 8.6

Load balancing

10
Figure5 : Load Balancing avec HA-Proxy

11
5. Architecture logicielle
Cartographie applicative
fonction Role tools Cluster

source code mgt gestion des sources Gitlab UDD

build build des artifcats jar et image docker Gitlab-CI UDD
maven,
gradle,
docker
cluster gestionnaire des clusters kubernetes (local) Rancher/ Rancher
management RKE2
cluster K8s cluster kubernetes (downstream) RKE2 Prod, hors Prod et
UDD
orchestrator CI orchestrateur de CI Gitlab-CI UDD
Operateur CD gesiotionnaire de CD Rancher Prod, hors Prod
Fleet
quality control analyse de code et dashboarding de qualité SonarQube UDD
container analyse des containers docker à l’intérieur de neuvector Prod, hors Prod
security cluster
monitoring supervision des Nodes, Pods et VM, dashboard et Prometheus Prod, hors Prod
gestion des alertrs Grafana
Alert
Manager
stockage persistance des statefull Set Longhorm Prod, hors Prod et
UDD
container registre des images docker Harbor UDD
registry
artifact registry registre des artifacts autre que les images docker Nexus UDD
central Logging log centralisés des Nodes et Pods EFK Prod, hors Prod

Version logicielle
tools version

Redhat 8.6
Gitlab/Gitlab-CI 15.6
Maven 3.8
Gradle 7.6
Docker 19
Rancher 2.6
RKE2 1.24
Rancher Fleet 0.5
SonarQube 9.7
Neuvector 5.0
prometheus 2.4
Grafana 9.3
AlertManager 0.24
Longhorn 1.2
Harbor 1.10
Nexus 3.43
ElastickSearch 8.5
FluentD 8.5
Kibana 8.5

12
6. Code source
les scripts sont sous le projet GIT :

– [Link]

13
7. Load Balancer
L’accès à la plateforme utilise un Load Balaner HA-Proxy déployé en mode Cluster en mode VIP

VMs

DG-DEVSECOPS-NLB1 = [Link]
DG-DEVSECOPS-NLB2 = [Link]
VIP (Virtual IP) = [Link]

Installation
yum install haproxy

Configuration

fichier de configuration haproxy : /etc/haproxy/haproxy/conf

14
configuration des workers de la hors prod :

configuration des workers de l’UDD :

configuration des workers de la prod

15
8. Plateforme de déploiement Rancher
Organisation par projet
Pour nous faciliter la gestion des droits d’accès et des ressources (CPU & RAM) d’une application, Rancher propose de
regrouper plusieurs Namespaces au sein d’un Project. un cluster regroupe plusieurs projets et chaque projet est composé
de plusieurs namespace.

Cette abstraction supplémentaire permet, en autres, d’affecter des droits qui s’appliqueront pour l’ensemble des
Namespaces du Project.

Il est également possible de positionner des contraintes de ressources (CPU & RAM) sur les Projects afin de limiter, par
exemple, le nombre de Namespaces au sein d’un Project.

Figure : script Ansible

16
9. Installation
l’installation de Rancher et RKE2 est géré avec un script Ansible

Cluster de management - Rancher

installation de cluster
ansible-playbook [Link] -i inventory/production/management_cluster.yml

installation de Rancher
ansible-playbook [Link] -i inventory/production/management_cluster.yml

Cluster machine VM CPU Mem Storage OS IP

Rancher NOD_RCH_1 4 8 50 RHEL 8.6

NOD_RCH_2 4 8 50 RHEL 8.6

NOD_RCH_3 4 8 50 RHEL 8.6

17
Inventory file :

18
Cluster de l’UDD

installation de cluster
ansible-playbook [Link] -i inventory/production/workload_cluster_UDD.yml

Cluster machine VM CPU Mem Storage OS IP

UDD NOD_CTRL_UDD_1 4 8 50 RHEL 8.6

NOD_WRK_UDD_1 12 16 350 RHEL 8.6

NOD_WRK_UDD_2 12 16 350 RHEL 8.6

NOD_WRK_UDD_3 12 16 350 RHEL 8.6

Inventory file :

19
Cluster de Hors Prod

20
installation de cluster
ansible-playbook [Link] -i inventory/production/workload_cluster_horsProd.yml

Cluster machine VM CPU Mem Storage OS IP

Hors Prod NOD_CTRL_HorsPRD_1 4 8 50 RHEL 8.6

NOD_WRK_HorsPRD_1 8 16 200 RHEL 8.6

NOD_WRK_HorsPRD_2 8 16 200 RHEL 8.6

NOD_WRK_HorsPRD_3 8 16 200 RHEL 8.6

Inventory file :

21
22
Cluster de la Prod

installation de cluster
ansible-playbook [Link] -i inventory/production/workload_cluster_Prod.yml

Cluster machine VM CPU Mem Storage OS IP

Prod NOD_CTRL_PRD_1 4 8 50 RHEL 8.6

NOD_CTRL_PRD_2 4 8 50 RHEL 8.6

NOD_CTRL_PRD_3 4 8 50 RHEL 8.6

NOD_WRK_PRD_1 8 16 250 RHEL 8.6

NOD_WRK_PRD_2 8 16 250 RHEL 8.6

NOD_WRK_PRD_3 8 16 250 RHEL 8.6

NOD_WRK_PRD_4 8 16 250 RHEL 8.6

NOD_WRK_PRD_5 8 16 250 RHEL 8.6

inventory file :

23
24
10. Usine de développement
créer storage class : cd devops ; kubectl create -f [Link]

Gitlab & Gitlab-CI

· créer namespace : create namespace git

· sous le répertoire gitlab, cd devops

· créer le secretMap marsamaroc-tls-ca :

o cd gitlab ; kubectl create -f [Link]

· créer le secretMap marsamaroc-tls :

o kubectl create -f [Link]

· exécuter la commande :

o ansible-playbook [Link] -i inventory/production/workload_cluster.yml

SonarQube
· créer namespace : kubectl create namespace sonarqube

· sous le répertoire, cd devops

· exécuter la commande :

o ansible-playbook [Link] -i inventory/production/workload_cluster.yml

Nexus
· créer namespace : kubectl create namespace nexus

· sous le répertoire, cd devops

· exécuter la commande :

o ansible-playbook [Link] -i inventory/production/workload_cluster.yml

Harbor
· créer namespace : kubectl create namespace nexus

· sous le répertoire, cd devops

· exécuter la commande :

o ansible-playbook [Link] -i inventory/production/workload_cluster.yml

25
Fleet CD
sous Rancher, sur le cluster UDD, configurer le Continuous Delivery

pour le déploiement Hors Prod, le CD est configuré pour suivre les modifications sous le répertoire « dev »

pour le déploiement Prod, le CD est configuré pour suivre les modifications sous le répertoire « prod »

26
27
11. Hors Prod & Prod
créer storage class : cd devops ; kubectl create -f [Link]

Supervision - Prometheus/Garafana
La supervision est supporté par l’outil Prometheus avec un dashboard Garafana

Installation

depuis le marketplace, selectionner le chart « monitoring »

choisir le pvc templte pour la persistance des dashboards grafana,
lancer l’installation

Logging
le log est géré avec l’operator de logging Banzai Cloud qui déploie des fluentBit pour le streaming des logs vers la base
elasticSearch et qui sera exploité via l outil dashboard kibana.

28
figure :

Installation
Install logging rancher operator from marketplace

choisir le chart de « logging »

Install elasticsearch form marketplace

choisir le chart elasticSearch depuis le marketplace

29
Configure cluster output and clusterFlow

– créer le clusterOuput qui pointe sur ElasticSearch

– créer le clusterFlow qui utilise le clusterOuput créé ci-dessous et log des applications avec un label « app=appli »

30
Install kibana from marketplace
choisir le chart kibana depuis le marketplace

add ingress for kibana.

create ingress for kibana service

kubectl create -f [Link]

Persistance - Longhorn
La persistance est supporté par l’outil longhorn avec un dashboard Garafana

Installation
· créer namespace : kubectl create namespace longhor-system

31
 · créer le storage class : cd devops ; kubectl create -f [Link]

· exécuter les commandes :

o kubectl create -f [Link]

· activer iscsi au niveau des workers :

o sous chaque VM des workers Node, executer la commande :

§ sudo systemctl start iscsid && sudo systemctl enable iscsid & sudo systemctl status iscsid

· sous le marketplace , choisir la chart longhorn

· check installation :

o depuis la console de Rancher, accéder au lien de Longhorn

Sécurité des container - neuvector

Installation

· créer namespace neuvector

32
 · depuis le marketplace de Rancher lancer l’installation de chart neuvector,
o pour le choix de runtime contanier utiliser k3s

· configurer le,persistence : choisir le storageclass « longhorn1repliat »

· créer un ingress pour neuvector

Keycloak

Installation
· créer namespace : kubectl create namespace keycloak

· sous le répertoire, cd devops

· exécuter les commandes :

o kubectl create -f [Link]

o kubectl create -f [Link]

o ansible-playbook [Link] -i inventory/production/workload_cluster.yml

33
.

34
12. Pipeline de CI
Il y a deux pipelines qui sont mise en place :

· pipeline pour les applications Java basé sur Maven avec un déploiement d’un container sur Kubernetes/Rancher

· pipeline pour les applications Angular basé sur npm avec un déploiement d’un container sur Kubernetes/Rancher

Variable globaux :

configuré sous GitLab Instance # <project name> # CI/CD Settings

Pipeline projet Java/Maven

exemple :
[Link]

Configuration
variable valeur description

35
PROJECT poc_project

COMPONENT bad-blc-generateur-api

ENV DEV

VERSION 08062023

SONAR_PROJECT_KE sqp_35322d9588231b570efadb77a060bf34d078467
Y 2

REPO "[Link]/gitlab-instance-fcec25da/
[Link]"

BRANCH "main"

Stages

36
37
Pipeline projet Angular

Exemple :
[Link]

Configuration
variable valeur description

PROJECT poc_project

COMPONENT bad-front
ENV DEV

VERSION 10

SONAR_PROJECT_KEY sqp_35322d9588231b570efadb77a060bf34d07846
72

38
SONAR_EXCLUSIONS_DI 'node-modules/*'
R:
OUTPUT_DIR target

NODE_OPTIONS : --max_old_space_size=3584

Stages

39
stratégie de branche
le déploiement est basé sur les branches : le déploiement est déclenche par commit sur la branche associée à un
environnement de déploiement, pour la version actuelle deux branches sont définie

40
13. CD
Sous GIT pour chaque chaque projet les fichiers de déploiement sont crées sous le projet
[Link]
exemple du projet dev, les fichiers de déploiement kubernets sont crées sous le repertoire dev

pour le déploiement d’un microservice y a 3 fichies : deployment, service et ingress

41
42
14. Migration du code source
Le code source actuelle est en partie sous SVN et l’autre partie sous GIT

La migration doit garantir les exigences suivants

· la récupération de l’historique des commits

· La correspondance entre les utilisateurs entre l’ancien et le nouveau gestionnaire des sources

· La récupération des tags

· La récupération les branches

création des comptes GIT

compte adressre mail

Achraf <[Link]@[Link]>

Arraf ARRAF@[Link]

A_caidi k_caidi@[Link]

elgarnaoui !!

mahjoubi A_MAHJOUBI@[Link]

MAHJOUBI A_MAHJOUBI@[Link]

Ouabderazak l_ouabderazak@[Link]

razik [Link]@[Link] (a bloqué)

sakina TASTAOUI Sakina SOFRECOM [Link]@[Link]

Souhail a bloqué

Yassine [Link]@[Link] (a
bloqué)

Migration du code SVN

ci-dessous un exemple de migration d’un projet SVN pour migrer un projet SVN sous
svn://[Link]/MarsaCoteneur/branches/marsaConteneur ver le nouveau projet Git
[Link]

1- récupérer les comptes ayant commité sur le repos SVN

1. Sous une machine Windows installer l’outil tortoiseSVN, n oubliez pas de cocher l’option “command line client
tools
2. lister le contenu

43
svn ls "svn://MarsaCoteneur/branches/marsaConteneur"

3. checkout repos =
svn co "svn:///MarsaCoteneur/branches/marsaConteneur"

4. Lister les utilisateurs ayant commité sur le repos SVN pour récupérer les noms des comptes ayant commité sur ce
projet afin de reconstruire l’historique SVN sous GIT
svn log

5. initialiser le fichier [Link], avec le résultat de la commande 4, pour chaque compte SVN associer un compte
Git, ci-dessous un exemple, le format de fichier <compte SVN> = nom prenom <adresse mail > git
exemple [Link]
mahjoubi = A MAHJOUB <A_MAHJOUBI@[Link]>
caidi = k caidi <k_caidi@[Link]>
Ouabderazak = l ouabderazak <l_ouabderazak@[Link]>
youssef = k caidi <k_caidi@[Link]>
ouabderazak = l ouabderazak <l_ouabderazak@[Link]>

2- push du code dans le nouveau GIT

6. créer un nouveau répertoire pour le projet Git, exemple worwspaceGit,
md worwspaceGit

7. initialiser le repertoire Git :

cd worwspaceGit
git svn init "svn:/ /MarsaCoteneur/branches/marsaConteneur" --no-metadata

8. configure les comptes GIT avec le mapping des comptes SVN et GIT:
git config [Link] C:\Users\admin\migrationSVN\tmp\[Link]

9. récupérer le code source du projet SVN :

git svn fetch

10. créer un nouveau projet GIT sous gitlab : ex my261223/[Link]

11. configurer le répertoire Git locale pour le faire pointer sur le projet Git remote créé lors de l’étape 10 :
git remote add origin [Link]

12. push le code source GIT :

git push --set-upstream --all origin

Migration du code GIT

migration depuis un GIT existant vers le GIT cible

1. Create gitlab token

a. Click your avatar at the top right corner, select Edit profile
b. On the left panel, select Access Tokens
c. Input the Token name and Expiration date (if any)
d. Check the read_repository checkbox
e. Click Create personal access token

2. clone GIT project

a. git clone --mirror [Link]

3. Create projet with same name within a new gitlab

44
4. Execute command
a. git remote set-url origin [Link]
b. git push --no-verify --mirror origin

45