Comment réussir le déploiement d’une solution open‑source de gestion d’entreprise tout en respectenant les exigences légales et réglementaires.
1. Introduction
Dolibarr est une suite d’ERP/PGI (Enterprise Resource Planning / Gestion de Production et d’Gestion) très appréciée pour sa simplicité d’usage, son architecture modulaire et la richesse de son écosystème d’extensions. Dockeriser puis orchestrer Dolibarr avec Kubernetes apparaît comme une démarche naturelle pour les équipes qui souhaitent :
- Scalabilité : répondre à des pics de charge (commandes, factures, rapports) sans interruption.
- Résilience : garantir une disponibilité 99,9 % même en cas de panne d’un nœud.
- Ops‑automation : CI/CD, health‑checks, roll‑outs progressifs, et auto‑scaling.
Cependant, Dolibarr manipule des données sensibles (clients, fournisseurs, factures, pièces comptables). Le passage à un environnement k8s introduit donc un nouveau cadrage de conformité (RGPD, ISO 27001, PCI‑DSS, etc.).
Cet article recueille les leçons apprises lors de plusieurs projets d’intégration de Dolibarr dans un cluster Kubernetes, spécifiquement avec un focus conformité. Nous partagerons les bonnes pratiques, les pièges rencontrés et les solutions mises en œuvre pour concilier performance, agilité et exigences légales.
2. Pourquoi Kubernetes pour Dolibarr ?
| Besoin métier | Apport de Kubernetes |
|---|---|
| Scalabilité horizontale | Pods réplicables (Horizontal Pod Autoscaler) qui réagissent aux variations de trafic (ex. pic de facturation à la fin du mois). |
| Disponibilité | Liveness/Readiness probes, auto‑restart, rolling updates. |
| Gestion des stateful services | StatefulSet pour persister les bases de données PostgreSQL/MySQL, volumes persistants (PVC) et sauvegardes planifiées. |
| Sécurité du runtime | PodSecurityPolicy/PodSecurity Standards, seccomp/AppArmor, limites de privilèges. |
| Déploiement automatisé | Helm charts, Kustomize, GitOps (ArgoCD/Flux) pour versionner les manifests. |
| Observabilité | Prometheus, Grafana, Jaeger, Loki pour tracer les échanges API, logs ERP, métriques DB. |
En résumé, Kubernetes apporte l’agilité opérationnelle nécessaire aux environnements réglementés tout en offrant des leviers natifs de conformité (network policy, secrets management, audit logging).
3. Cadrage de conformité : quelles exigences ?
-
Protection des données personnelles (RGPD)
- Chiffrement au repos et en transit.
- Conservation minimale des données (policy TTL).
- Droit à l’effacement (right‑to‑be‑forgotten) via requêtes de suppression ou d’anonymisation.
-
Intégrité et traçabilité (ISO 27001 / 27017)
- Journalisation détaillée des accès à la base de données.
- Contrôle d’accès basé sur les rôles (RBAC) sur les manifests Kubernetes.
-
Disponibilité et continuité d’activité (BCP)
- Désastre recovery (DR) avec réplication inter‑zone de la base de données.
- Tests de restauration périodiques.
-
Segregation des environnements
- Cluster dédié ou namespace isolé (dev, test, pré‑prod, prod) avec NetworkPolicies et RBAC pour empêcher les fuites de données.
- Gestion des secrets
- Utilisation de sealed‑secrets ou HashiCorp Vault plutôt que de stocker les mots de passe en clair dans les manifests.
4. Architecture recommandée
4.1 Schéma haut‑niveau « `
| +——————-+ +—————–+ +——————-+ | Ingress (L7) | https -> | Service (Svc) | 1:1 -> | Pod Dolibarr | +——————-+ +—————–+ +——————-+ ^ |
+— Service (DB) (StatefulSet) |
|---|
+---------+-----------+
| PostgreSQL/MySQL |
| StatefulSet + PVC |
+-----------------------++——————-+ NetworkPolicy (allow only DB ↔ Dolibarr) +——————-+
| Monitoring | (Prometheus, Grafana, Loki) | Logging (Loki) |
+——————-+ +——————-+
### 4.2 Composants essentiels
| Composant | Mode de déploiement | Rôle juridique |
|-----------|--------------------|----------------|
| **Dolibarr** | Deployment (scale‑out) avec `readinessProbe` sur `/` | Exposition via Ingress TLS‑terminated (cert‑manager). |
| **Database** | StatefulSet PostgreSQL (ou MySQL) avec **PVC** chiffrés (via LUKS/Ceph‑FS) | Stockage des données personnelles → journal de conformité. |
| **Cache** | Redis (optionnel) en Deployment, utilisable uniquement via `NetworkPolicy`. | Réduction latence, pas de donnée sensible. |
| **Registry d’images** | Docker Hub secured ou registre interne avec **image signing** et **trivy scans**. | Traçabilité des artefacts. |
| **Secrets** | `sealed‑secrets` ou **Vault Agent Injector** pour injecter les variables d’environnement au runtime. | Évite de persister les mots de passe en clair. |
| **RBAC / PSP** | `PodSecurityPolicy` remplacé par **PodSecurity Standards** (Baseline). | Contrôle du niveau de privilèges. |
| **Network Policies** | `calico` ou `cilium` pour interdire le traffic inter‑namespace non autorisé. | Isolation des environnements prod/dev. |
| **Audit & Monitoring** | **Falco** pour la détection de comportements anormaux; **Prometheus** + **Grafana** pour métriques, **Loki** pour logs. | Preuve d’audit & détection d’incidents. |
---
## 5. Processus de mise en conformité étape‑par‑étape
### 5.1 1️⃣ Analyse d’impact (DPIA)
* Identifier les flux de données sensibles (client, facture, paiement).
* Définir le **Data Processing Agreements (DPA)** avec les prestataires cloud.
* Documenter les mesures de mitigation (chiffrement, pseudonymisation).
### 5.2 2️⃣ Choisir le mode de persistance
| Option | Description | Points conformité |
|--------|-------------|-------------------|
| **StorageClass chiffré** (e.g., `encrypted-ebs` sur AWS, `managed‑disk‑encryption` sur Azure) | Les volumes sont créés automatiquement chiffrés. | Répond aux exigences de chiffrement au repos. |
| **VolumeSnapshot + ObjectStore** | Sauvegardes incrémentales directement dans S3/MinIO. | Permet la rétention et la restauration dans le cadre de la BCP. |
| **Dual‑Region Replication** | Réplication asynchrone de la base vers un autre cluster ou region. | Garantit la continuité d’activité. |
### 5.3 3️⃣ Mise en place du secret management
```yaml
apiVersion: v1
kind: Secret
metadata:
name: dolibarr-db-secret
annotations:
sealedsecrets.bitnami.com/v1: "enabled"
type: Opaque
data:
POSTGRES_PASSWORD: <base64‑encrypted>- Sealed‑Secrets permet de générer un
EncryptedSecretque l’opérateur (sealed‑secrets) déchiffre uniquement dans le namespace cible. - Alternativement, Vault Agent Injector injecte les secrets au démarrage du pod, avec un TTL limité.
5.4 4️⃣ Déploiement de l’Ingress TLS « `yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: dolibarr-ingress
annotations:
cert-manager.io/cluster-issuer: letsencrypt-prod
nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
spec:
tls:
- hosts:
- erp.mondomaine.com
secretName: dolibarr-tls
rules:
- erp.mondomaine.com
- host: erp.mondomaine.com
http:
paths:- path: /
pathType: Prefix backend:
service:
name: dolibarr-svc
port:
number: 80
* Utilisation de **cert‑manager** pour obtenir des certificats Let's Encrypt ou internes.
* `force-ssl-redirect` évite le trafic non chiffré.
- path: /
5.5 5️⃣ Paramétrage des probes de santé
livenessProbe:
httpGet:
path: /index.php
port: 80
initialDelaySeconds: 30
periodSeconds: 10
readinessProbe:
httpGet:
path: /index.php
port: 80
initialDelaySeconds: 15
periodSeconds: 5- Ces probes permettent à K8s de redémarrer les pods défectueux avant que les données ne soient corrompues.
5.6 6️⃣ Application de PodSecurity Standards
apiVersion: policy/v1
kind: PodSecurityPolicymetadata:
name: ps-dolibarr-prod
spec:
privileged: false allowPrivilegeEscalation: false readOnlyRootFilesystem: true
fsGroup:
rule: MustRunAs runAsUser:
rule: MustBeNonRoot
seLinux:
rule: RunAsAny
supplementalGroups:
- 1000 # groupe d'upload de logs (non‑privileged)- En production, PSP (ou son successeur
PodSecurity) impose le runAsNonRoot et readOnlyRootFilesystem pour éviter l’escalade de privilèges.
5.7 7️⃣ Implémentation des Network Policies
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-db-to-dolibarr
namespace: prod
spec:
podSelector:
matchLabels:
app: dolibarr
ingress:
- from:
- namespaceSelector:
matchLabels:
name: db-backup
ports:
- protocol: TCP
port: 5432- Les pods Dolibarr ne peuvent communiquer que avec les pods de la base de données et les services de backup, supprimant toute exposition réseau non nécessifiée.
5.8 8️⃣ Observabilité orientée conformité
| Métrique | Objectif réglementaire |
|---|---|
etcd_audit (event logs) |
Traçabilité des actions kubectl (who‑did‑what). |
db_audit_conn (comptes d’accès PostgreSQL) |
Journalisation des connexions SQL. |
k8s_audit (API server audit) |
Conservation des logs de modification de ressources. |
prometheus_alerts (thresholds) |
Détection précoce d’anomalies (ex. volume plein, CPU > 80 %). |
6. Gestion des incidents et audit
| Phase | Action | Outils spécifiques |
|---|---|---|
| Détection | Alertes sur des changements de config non autorisés (via kube‑audit ou OPA/Gatekeeper). |
Alertmanager, Slack/PagerDuty. |
| Escamelage | Exécution de kubectl get pods -o wide --show-labels et kubectl exec sur le pod concerné (avec comptes à privilèges limités). |
Falco, kubectl-debug. |
| Contenance | Isolement du namespace via NetworkPolicy deny-all. |
Calico CNI. |
| Rétablissement | Re‑déploiement depuis image signée, restauration de PV à partir de snapshot. | Velero + Restic. |
| Post‑mortem | Rapport d’audit incluant les logs d’audit et les erreurs de configuration. | Confluence / SharePoint (zone de conformité). |
7. Pièges courants et comment les éviter
| Piège | Conséquence | Solution préventive |
|---|---|---|
Persistances en clair : stocker le mot de passe PostgreSQL dans le ConfigMap. |
Violation du chiffrement des secrets → fuite de données. | Utiliser sealed‑secrets / Vault, activer le liveness du secret (rotation auto). |
Pod non‑terminable à cause de terminationGracePeriodSeconds trop petit. |
Corruption de la base en cours de backup. | Garder gracePeriod >= 30 s pour les pods DB ; implémenter un preStop hook pour vider les connexions. |
| NetworkPolicy trop permissive (allow‑all). | Exposition de la DB à d’autres services → fuite de données. | Appliquer principle of least privilege : autoriser uniquement les flux nécessaires. |
| Absence de CI/CD de conformité (pas de scan d’image). | Images non‑certifiées transportent des vulnérabilités. | Intégrer Trivy ou Clair dans le pipeline GitLab/GitHub, bloquer les builds si CVSS > 7. |
| Sauvegarde sans encryption. | Sauvegardes stockées dans S3 en clair → non conforme au RGPD. | Activer s3:serverSideEncryption: AES256 ou TLS client‑side. |
| Logging des requêtes SQL (debug mode activé). | Exposition de données sensibles dans les logs. | Désactiver les logs d’interrogation ou masquer les champs PII via log_line_prefix. |
8. Exemple de pipeline GitOps (ArgoCD)
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: dolibarr-prod
namespace: argocd
spec:
source:
repoURL: https://github.com/entreprise/dolibarr-k8s.git
path: helm/dolibarr
targetRevision: main
helm:
parameters:
- name: imageTag
value: "1.2.0-20241103"
- name: dbPasswordSecretName
value: dolibarr-db-secret
- name: ingressEnabled value: "true"
- name: networkPolicyEnabled
value: "true"
destination:
server: https://kubernetes.default.svc
namespace: prod
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=true- ArgoCD assure la déclaration désirée versionnée dans Git, et déclenche automatiquement les changements de configuration.
- Les helm‑parameters permettent d’injecter dynamiquement les secrets et les variables d’environnement sans les hard‑coder dans les manifests.
9. Bilan des leçons apprises | Leçon | Description | Impact sur la conformité |
|——-|————-|————————–|
| Séparer strictement les environnements (namespace, RBAC) | Empêche les contaminations croisées (ex. dev → prod). | Réduit les risques d’accès non autorisé aux données de production. |
| Chiffrer chaque couche (volume, trafic Ingress, secrets) | Conformité RGPD & ISO 27001. | Validation lors des audits internes, moindre effort de justification. |
| Utiliser des opérateurs sécurisés (sealed‑secrets, Velero) | Gestion automatisée des secrets et des backups. | Traçabilité des modifications, restauration certifiée. |
| Mettre en place des policies réseau dès le départ | Évite les ré‑architectures coûteuses plus tard. | Conformité au principe du moindre privilège. |
| Intégrer les tests de conformité dès la CI (image scan, OPA/Gatekeeper) | Détection précoce de vulnérabilités et de violations de policy. | Réduction du temps de remédiation, auditabilité dès le premier déploiement. |
| Documenter chaque changement d’état (git diff, audit log) | Traceabilité complète des actions opérationnelles. | Preuve d’audit prônée lors des revues de conformité. |
| Planifier des exercices de DRR (disaster‑recovery‑restore) | Teste réel de restauration à chaud/cold. | Validation de la continuité d’activité exigée par la BCP. |
10. Checklist rapide pour un déploiement compliant
| ✅ | Étape |
|---|---|
| 1 | Réaliser une DPIA et identifier les données à protéger. |
| 2 | Choisir une StorageClass chiffrée et configurer les PVC avec storageClassName. |
| 3 | Déployer la base PostgreSQL via StatefulSet avec PVC chiffrés. |
| 4 | Stocker les secrets dans sealed‑secrets ou Vault, jamais en clair. |
| 5 | Créer un Ingress TLS avec certificat automatisé via cert‑manager. |
| 6 | Appliquer les PodSecurity Standards (Baseline). |
| 7 | Définir des NetworkPolicies restrictives (DB ↔ Dolibarr only). |
| 8 | Activer Prometheus + Grafana et configurer des alertes de volume, latency, erreurs. |
| 9 | Mettre en place des audit logs (etcd, Kubernetes API, PostgreSQL). |
| 10 | Configurer CI/CD avec Trivy scan d’image, OPA/Gatekeeper validation, et déploiement GitOps (ArgoCD). |
| 11 | Programmer des sauvegardes incrémentales (Restic + Velero) avec chiffrement. |
| 12 | Documenter et versionner toutes les modifications de configuration. |
| 13 | Réaliser un exercice de DRR tous les 90 jours. |
11. Conclusion
Allier Dolibarr et Kubernetes représente un saut qualitatif dans la gestion des ressources d’entreprise : flexibilité, résilience et automatisation. Mais lorsque l’on travaille avec des données personnelles et comptables, le périmètre de la conformité s’élargit considérablement.
En suivant la démarche ci‑dessus — analyse d’impact, chiffrement de bout en bout, policies de sécurité strictes, observabilité orientée audit, CI/CD de conformité — vous obtenez un déploiement qui :
- Scale naturellement sans sacrifier la traçabilité,
- Répond aux exigences du RGPD, ISO 27001, PCI‑DSS (ou tout autre cadre sectoriel),
- Offre une visibilité opérationnelle complète pour détecter et corriger rapidement les incidents,
- Simplifie les audits grâce à la versionnage Git et aux outils de gouvernance (OPA, Gatekeeper).
Les leçons apprises montrent que la conformité n’est pas un ajout à posteriori, mais un fil conducteur dès la conception du cluster. La mise en place de mécanismes de sécurité natifs (secrets, network policies, pod security) ainsi que d’une gouvernance automatisée (GitOps, CI) transforme le Kubernetes‑Dolibarr en une plateforme fiable, auditable et prête pour les exigences réglementaires modernes.
À retenir : dans le monde de l’ERP, la conformité ne doit jamais être un compromis de performance, mais le socle même sur lequel la performance s’appuie. Kubernetes fournit les briques ; c’est à nous, architectes et experts conformité, de les assembler de façon à ce que chaque Deploy, chaque Backup et chaque Audit soit une preuve vivante de bonnes pratiques.
Ce document synthétise les retours d’expérience d’une équipe d’intégrateurs Kubernetes et de spécialistes de la conformité sur plusieurs projets de déploiement de Dolibarr en production. Il peut servir de point de départ pour élaborer votre propre cadre de gouvernance Kubernetes‑Dolibarr, adapté à votre secteur et à vos obligations légales.