Sécurité Dolibarr : Kubernetes Playbook pour passer à l’échelle

L’adoption de Dolibarr, l’ERP/CRM open-source populaire, s’accélère dans les PME et les organisations en croissance. Lorsque l’installation initiale sur un serveur unique atteint ses limites, la容器isation avec Kubernetes (K8s) devient une solution naturelle pour assurer scalabilité, résilience et maintenance simplifiée. Cependant, cette transition ne doit pas se faire au détriment de la sécurité. Cet article propose un playbook structuré pour déployer et opérer Dolibarr sur Kubernetes en plaçant la sécurité au cœur de l’architecture.

Pourquoi Kubernetes pour Dolibarr ? Et Pourquoi un Focus Sécurité ?

Kubernetes permet d’orchestrer des conteneurs Dolibarr (web PHP) et MariaDB/MySQL (base de données) de manière dynamique. Les avantages sont nombreux :

  • Scalabilité horizontale : Ajouter des pods Dolibarr pour gérer la charge.

  • Haute disponibilité : Répartition de la charge et reprise automatique sur panne.

  • Gestion centralisée : Déploiements, mises à jour et configuration déclaratifs.

Mais cette complexité introduit de nouveaux risques :

  • Surface d’attaque étendue (pods, réseau, API K8s).

  • Gestion sensible des secrets (mots de passe DB, clés API).

  • Exposition potentielle de services internes.

  • Conformité et isolation des données (multi-tenants).

Playbook de Sécurité pour Dolibarr sur Kubernetes

Voici une feuille de route pratique, par étapes.

Étape 1 : Préparation et Fondations Sûres

  1. Cluster K8s Sécurisé :

    • Utilisez une distribution renforcée (OpenShift, Rancher, ou K8s avec des politiques de sécurité activées).

    • Activez et configurez les Network Policies par défaut pour refuser tout trafic inter-pods non explicitement autorisé.

    • Utilisez des RBAC (Role-Based Access Control) stricts. Ne donnez les droits d’administration (cluster-admin) qu’à un nombre très limité d’opérateurs. Appliquez le principe du moindre privilège.

    • Scannez vos images Docker/Container (avec Trivy, Grype) avant de les pousser dans votre registry privée.

  2. Architecture Isolée :

    • Déployez Dolibarr et sa base de données dans un namespace dédié (ex: dolibarr-prod).

    • Isolez ce namespace avec des Network Policies qui n’autorisent :

      • Le trafic entrant uniquement depuis l’équilibreur de charge (Ingress Controller) sur le port 80/443.

      • Le trafic entre les pods Dolibarr et le pod/base de données MariaDB.

      • Aucun trafic depuis d’autres namespaces non autorisés.

Étape 2 : Sécurisation des Déploiements (Deployments/StatefulSets)

  1. Gestion des Secrets (CRITIQUE) :

    • Jamais de secrets en clair dans les manifests YAML.

    • Utilisez les Secrets Kubernetes (stockés en base etcd, chiffrés au repos si possible) ou, mieux, un External Secrets Operator (comme external-secrets) qui va les récupérer depuis un vault dédié (HashiCorp Vault, AWS Secrets Manager, etc.).

    • Exemple de secret pour Dolibarr (dolibarr-secrets.yaml) : 
      apiVersion: v1
      
kind: Secret
      
metadata:
      
  name: dolibarr-db-secret
      
type: Opaque
      
stringData:
      
  DOLIBARR_DB_HOST: "mariadb.dolibarr-prod.svc.cluster.local"
      
  DOLIBARR_DB_PORT: "3306"
      
  DOLIBARR_DB_NAME: "dolibarr"
      
  DOLIBARR_DB_USER: "dolibarr_user"
      
  DOLIBARR_DB_PASSWORD: "<votre-mot-de-passe-chiffré>"

    • Montez ces secrets comme variables d’environnement ou fichiers dans les pods (never as command-line args).

  2. Durcissement des Pods :

    • Exécutez les conteneurs avec un utilisateur non-root (runAsNonRoot: true) et un UID/GID spécifique dans l’image Docker.

    • Activez le securityContext dans le Deployment : 
      securityContext:
      
  runAsNonRoot: true
      
  runAsUser: 1000
      
  runAsGroup: 1000
      
  readOnlyRootFilesystem: true  # Si votre image le permet (cache dans un volume emptyDir)
      
  allowPrivilegeEscalation: false

    • Limitez les capabilities Linux du conteneur : drop: ["ALL"] puis ajouter uniquement si nécessaire (ex: NET_BIND_SERVICE pour le port 80).

    • Définissez des requests et limits de ressources (CPU/RAM) pour éviter les abus et assurer la QOS.

  3. Sécurité de l’Application Dolibarr :

    • Forcez HTTPS : Utilisez un Ingress Controller (NGINX, Traefik) avec certificat TLS (Let’s Encrypt via cert-manager).

    • Configurez les Headers de sécurité HTTP via l’Ingress ou un sidecar :

      • Strict-Transport-Security (HSTS)

      • X-Content-Type-Options: nosniff

      • X-Frame-Options: DENY

      • Content-Security-Policy (CSP) adaptée.

    • Limitez l’exposition des endpoints : L’Ingress ne doit exposer que / (le site public) et potentiellement /admin/ (l’interface d’admin). Le reste (/backup/, /install/) doit être bloqué par NetworkPolicy ou inaccessible si l’installation est finie.

    • Maintenez Dolibarr et ses modules à jour via une CI/CD automatisée (GitLab CI, GitHub Actions). Intégrez un scan de vulnérabilités PHP (avec php-security-checker ou snyk).

Étape 3 : Sécurité du Réseau et de l’Accès

  1. Ingress Controller sécurisé :

    • Placez-le dans un namespace dédié (ex: ingress-nginx).

    • Limitez son exposition avec des Network Policies.

    • Configurez-le pour utiliser des certificats TLS modernes et forcer la redirection HTTP -> HTTPS.

  2. Policies Réseau Strictes :

    • Comme mentionné, créez une NetworkPolicy par défaut "deny all" dans le namespace dolibarr-prod.

    • Créez des politiques autorisantes spécifiques :

      • Pods dolibarr-* -> Pod mariadb-* sur le port 3306.

      • Ingress Controller -> Pods dolibarr-* sur les ports 80/443.

      • Pods dolibarr-* -> Internet (sortie) uniquement pour les mises à jour des modules (si nécessaire), sinon restreignez.

  3. Accès au Cluster :

    • Authentification via OIDC (Keycloak, Azure AD, etc.) plutôt que des fichiers kubeconfig locaux.

    • Utilisez kubectl avec des rôles limités.

    • Pour l’accès à la console Dolibarr, préférez un VPN d’entreprise ou une authentification SSO (via un reverse proxy comme OAuth2 Proxy en frontal de l’Ingress) plutôt que d’exposer l’interface d’admin publiquement.

Étape 4 : Surveillance, Audit et Backup

  1. Logging Centralisé :

    • Routez tous les logs des pods (Dolibarr, MariaDB) et les audit logs du cluster API vers un système sécurisé (ELK, Loki, Datadog).

    • Corrélez les logs des applications Dolibarr (erreurs PHP, tentatives de connexion) avec les logs réseau (NetworkPolicy denies).

  2. Monitoring et Alerting :

    • Utilisez Prometheus/Grafana.

    • Alertes clés :

      • Échecs de connexion répétés à la base de données.

      • Pic d’erreurs 5xx sur l’Ingress.

      • Pods redémarrant continuellement (OOM Kill).

      • NetworkPolicy violations (si logging activé).

      • Utilisation anormale des ressources.

  3. Backup et Restauration :

    • Base de données : Backup régulier (ex: mysqldump dans un CronJob) stocké en dehors du cluster (objet storage S3-compatible avec chiffrement côté serveur).

    • Fichiers de Dolibarr (documents uploadés, custom) : Utilisez un PersistentVolumeClaim (PVC) avec un StorageClass qui supporte les snapshots, ou synchronisez via un sidecar (Restic, Kopia) vers un stockage externe.

    • Testez régulièrement vos restaurations ! Un backup qui ne restaure pas est inutile.

Étape 5 : Opérations et Maintenance Sécurisée

  • CI/CD Pipelines Sécurisés :

    • Les pipelines doivent s’exécuter avec des secrets injectés de manière sécurisée.

    • Chaque build doit inclure : scan d’image, scan de dépendances PHP (compose audit), tests.

    • Utilisez des environnements de staging qui sont des clones sécurisés de la production pour tester les mises à jour.

  • Gestion des Images :

    • Utilisez une registry privée (Harbor, GitLab Container Registry) avec scan intégré et contrôle d’accès.

    • Évitez les tags latest. Utilisez des tags immuables (ex: 1.0.20231027-git123).

  • Mises à jour :

    • Mettez à jour les images des conteneurs (Dolibarr, MariaDB) et les charts/scripts de déploiement régulièrement.

    • Mettez à jour Kubernetes lui-même et les composants du cluster (CNI, Ingress) selon un calendrier maîtrisé.

Conclusion : Sécurité et Scalabilité, Main dans la Main

Passer Dolibarr à l’échelle avec Kubernetes n’est pas un simple exercice technique. C’est une opportunité de refonder la sécurité de votre ERP en appliquant des principes modernes : isolement par défaut, gestion centralisée des secrets, automatisation des contrôles et surveillance exhaustive.

Ce playbook fournit une feuille de route robuste. L’adaptez à votre contexte (réglementaire, taille de l’équipe, infrastructure cloud/on-premise). La clé du succès réside dans l’automatisation (IaC avec Terraform, déploiements avec Helm/ArgoCD) et la culture de la sécurité à toutes les étapes, du développement au run.

En suivant ces étapes, vous pourrez profiter pleinement de la flexibilité de Kubernetes pour votre Dolibarr, tout en dormant sur vos deux oreilles, certaines que vos données métier et celles de vos clients sont protégées, même dans un environnement dynamique et scaling.

Note finale : Ce guide est un point de départ. Une revue de sécurité approfondie par des experts, adaptée à votre déploiement spécifique, est toujours recommandée avant la mise en production.

Publications similaires