Aller au contenu principal

Architecture de référence

Le déploiement sur site de DuoKey est une architecture hybride hautement disponible (HA) et de qualité production. Elle combine un cluster OpenShift pour les charges de travail applicatives conteneurisées avec une infrastructure de VM dédiée aux données centrales, à la CI/CD et à la gestion des secrets — le tout soutenu par un plan complet de sauvegarde et de restauration.

Architecture de référence OpenShift sur site de DuoKey

Conçu pour l'adaptation

L'architecture ci-dessous décrit la conception de référence recommandée. Les choix de stockage, d'entrée (ingress) et de magasin d'objets peuvent être adaptés à votre environnement (bare metal, VMware, OpenStack ou Nutanix) — votre représentant DuoKey vous aidera à l'ajuster.

Composants centraux​

1. Secrets centralisés — OpenBao externe​

  • Isolation autonome — OpenBao (le fork open source, piloté par la communauté de la Linux Foundation, de Vault) s'exécute de manière externe sur des machines virtuelles dédiées, configuré en mode HA avec un moteur de stockage à consensus Raft.
  • Établissement de liaison d'authentification sécurisé — le cluster OpenShift exécute l'External Secrets Operator (ESO). Lorsqu'un pod applicatif démarre, ESO s'authentifie auprès d'OpenBao via la méthode d'authentification Kubernetes en utilisant le jeton du ServiceAccount du pod.
  • Injection dynamique et non persistante — les identifiants, chaînes de connexion à la base de données et clés de cache sont récupérés à la demande depuis OpenBao et injectés sous forme de primitives Secret Kubernetes natives mappées vers des volumes éphémères en mémoire (tmpfs). Aucun secret brut n'est jamais écrit dans le stockage du cluster ni codé en dur dans Git.
Intégration HSM

Pour le niveau d'assurance le plus élevé, la garde des clés est ancrée soit dans le MPC propre à DuoKey (parts de clé distribuées, aucun point unique de compromission), soit dans un HSM Securosys. Voir Prérequis pour les détails.

2. Livraison continue et contrôle de source — GitLab​

  • Hub de source et de registre — les dépôts de code, les pipelines CI et les images de conteneur de base personnalisées résident sur une instance GitLab auto-hébergée s'exécutant sur une VM autonome. Cela peut être remplacé par l'offre SaaS de GitLab lorsque la politique le permet.

3. Base de données persistante — cluster PostgreSQL​

  • Haute disponibilité de la base de données — PostgreSQL s'exécute sous un opérateur de base de données cloud-natif (tel que CloudNativePG ou Patroni), maintenant un nœud principal en lecture-écriture et plusieurs répliques hot-standby.

4. Orchestration de la plateforme et des applications​

  • Plan de contrôle OpenShift — s'appuie sur les opérateurs OpenShift intégrés pour gérer automatiquement le cycle de vie, la mise en réseau, le routage et les mises à niveau de la plateforme.
  • Entrée et répartition de charge — le routeur d'entrée (Ingress Router) OpenShift intégré et hautement disponible gère le trafic de périphérie, termine le TLS et répartit la charge sur les pods frontend. Le routage interne entre le frontend et le backend de l'API Rust utilise les Services Kubernetes natifs headless et ClusterIP.
  • Topologie HA — tous les pods frontend et backend utilisent des règles explicites d'anti-affinité de pods, garantissant que les charges de travail sont réparties sur différents nœuds de travail (worker nodes) et zones de disponibilité (AZ) distinctes.
  • Réconciliation GitOps — l'opérateur OpenShift GitOps (ArgoCD) dans le cluster suit en continu les branches dans GitLab. Lorsque les manifestes d'application changent, ArgoCD détecte la dérive et pousse proprement les mises à jour vers les espaces de noms ciblés.

5. Niveau de données persistant​

  • Orchestration à état — les moteurs de base de données et de mise en cache sont déployés en tant que StatefulSets pour préserver les identités réseau et les mappages de périphériques de bloc lors des redémarrages.
  • Fournisseur de stockage — la persistance est assurée par OpenShift Data Foundation (ODF) ou par un pilote CSI approprié à votre plateforme (par exemple OpenStack Cinder, vSphere CSI).
  • Haute disponibilité du cache — Redis est configuré en cluster partitionné (sharded) multi-nœuds avec basculement automatisé maître/réplique.

6. Observabilité — VictoriaMetrics et VictoriaLogs​

  • Métriques — des instances vmagent légères récupèrent les points de terminaison de performance et les acheminent vers une pile VictoriaMetrics distribuée (vmstorage, vminsert, vmselect).
  • Journaux — les agents Vector collectent stdout/stderr et les transfèrent vers VictoriaLogs pour une recherche structurée.
  • Tableaux de bord — un Grafana intégré se connecte aux deux en tant que sources de données pour les tableaux de bord opérationnels.

Flux des requêtes et des données​

Réseau et zones de disponibilité​

  • Les pods applicatifs sont répartis sur au moins trois nœuds de travail (worker nodes) couvrant des zones de disponibilité / domaines de défaillance distincts.
  • Le niveau de VM dédié (OpenBao, PostgreSQL, GitLab) est segmenté sur des réseaux isolés, idéalement avec un VLAN séparé et renforcé pour tout HSM.
  • Tout le trafic inter-composants est chiffré en transit (TLS) ; OpenBao n'est atteint que par des canaux mutuellement authentifiés.

Voir Prérequis → Réseau pour les exigences concrètes de réseau et de pare-feu.