Prérequis
Avant de commencer, assurez-vous que votre environnement satisfait aux exigences ci-dessous. Nous recommandons de passer en revue cette liste de contrôle avec votre représentant DuoKey durant la phase de planification.
Plateforme
| Exigence | Recommandé |
|---|---|
| OpenShift | Une version 4.x actuellement prise en charge (équivalent OKD pris en charge) |
| Topologie du cluster | 3 nœuds de plan de contrôle + ≥ 3 nœuds de travail répartis sur ≥ 3 domaines de défaillance |
| Runtime de conteneurs | CRI-O (par défaut dans OpenShift) |
| Stockage | OpenShift Data Foundation (ODF) ou un pilote CSI fournissant des volumes de blocs ReadWriteOnce et la prise en charge des instantanés |
| Ingress | OpenShift Ingress Router (intégré) avec un DNS wildcard + certificat TLS |
| Stockage objet | Bucket compatible S3 pour les sauvegardes (ODF NooBaa, MinIO ou externe) |
Dimensionnement de calcul (point de départ)
Voici les chiffres de référence pour un déploiement HA en production. Le dimensionnement final dépend du nombre de clés, de clients et du volume de requêtes.
Nœuds de travail OpenShift
| Profil | vCPU | RAM | Notes |
|---|---|---|---|
| Par nœud de travail (min 3) | 8 | 32 Go | Héberge les pods frontend, backend, observabilité |
Niveau VM dédié
| VM | Nombre | vCPU | RAM | Disque |
|---|---|---|---|---|
| OpenBao | 3 (HA / Raft) | 2 | 4 Go | 50 Go SSD |
| PostgreSQL | 3 (1 primaire + 2 réplicas) | 4 | 16 Go | 200 Go SSD |
| GitLab | 1 | 4 | 8 Go | 100 Go |
Le niveau VM peut être virtualisé sur votre hyperviseur existant (VMware, Proxmox, KVM/OpenStack). Maintenez OpenBao et PostgreSQL sur des hôtes physiques distincts lorsque c'est possible afin d'éviter un point de défaillance unique.
Dimensionnement DKE sur site
Pour les déploiements de Double Key Encryption (DKE), la charge de travail dominante est constituée des requêtes de wrap/unwrap de clé, qui sont légères mais en rafales — elles augmentent lorsque les utilisateurs ouvrent ou enregistrent des documents protégés. Dimensionnez pour la concurrence de pointe, et pas seulement pour le nombre total d'utilisateurs.
Ressources par composant (référence HA)
Voici les tailles de requête par réplica pour les composants DuoKey, avec le nombre minimal de réplicas pour un déploiement hautement disponible. Les images proviennent du registre Harbor.
| Composant | vCPU / réplica | RAM / réplica | Stockage | Réplicas min. (HA) |
|---|---|---|---|---|
| Cockpit (frontend) | 2 | 4 Go | 20 Go | 2 |
| API Cockpit (backend) | 4 | 8 Go | 20 Go | 3 |
| API KMS (point de terminaison de clé DKE) | 2 | 4 Go | 20 Go | 2 |
| Nœud MPC / TSM | 4 | 8 Go | 20 Go | 3 |
| PostgreSQL (MPC + Cockpit) | 4 | 16 Go | 100 Go | 3 |
| Cache Redis | 4 | 8 Go | 50 Go | 3 |
| Broker de messages (RabbitMQ/Kafka) | 4 | 8 Go | 50 Go | 3 |
| OpenBao (niveau VM) | 2 | 4 Go | 50 Go | 3 |
| Pile de surveillance | 8 | 16 Go | 200 Go | 1 |
| Pile de journalisation | 8 | 16 Go | 600–1000 Go | 1 |
Paliers de dimensionnement par nombre d'utilisateurs
Les ressources par composant ci-dessus sont dérivées du dimensionnement de référence de DuoKey. Les paliers par nombre d'utilisateurs ci-dessous sont des points de départ indicatifs destinés à faciliter la planification — ce n'est pas un mappage contractuel. Le dimensionnement réel dépend de l'activité documentaire et de la concurrence de pointe et est validé avec DuoKey pour votre déploiement.
Le tableau ci-dessous dimensionne les nœuds de travail applicatifs OpenShift (les pods ci-dessus). Il exclut les 3 nœuds de plan de contrôle et le niveau données/VM dédié (PostgreSQL, OpenBao), qui évoluent selon le tableau par composant ci-dessus.
| Palier | Utilisateurs | Nœuds de travail applicatifs | Par nœud | Notes |
|---|---|---|---|---|
| Pilote / PoC | ≤ 1 000 | 3 | 8 vCPU / 32 Go | HA minimale, réplicas réduits |
| Standard | ≤ 10 000 | 3–4 | 8 vCPU / 32 Go | Architecture HA de référence |
| Large | ≤ 50 000 | 6 | 16 vCPU / 64 Go | Réplicas mis à l'échelle + HPA |
| Entreprise | 100 000+ | 8+ | 16 vCPU / 64 Go | Personnalisé ; généralement multi-site |
- Les nœuds MPC sont limités par le CPU pendant les opérations de clé — mettez-les à l'échelle en premier sous forte charge DKE.
- PostgreSQL est utilisé comme simple magasin de données (pas de requêtes lourdes), il est donc limité par la RAM/l'IO plus que par le CPU.
- Redis et le broker sont en pass-through/mise en cache — CPU modeste.
- Activez le HorizontalPodAutoscaler sur l'API Cockpit et les nœuds MPC pour absorber les pics de requêtes.
Ces chiffres constituent un point de départ sûr. Votre représentant DuoKey les affinera en fonction de votre population réelle d'utilisateurs, de l'activité documentaire, de la concurrence de pointe et des cibles de disponibilité (site unique vs multi-datacenter).
Logiciels et opérateurs
Installez les opérateurs OpenShift suivants (via OperatorHub) avant le déploiement :
- OpenShift GitOps (ArgoCD)
- External Secrets Operator (ESO)
- Un opérateur PostgreSQL — CloudNativePG ou Patroni (si vous exécutez PostgreSQL in-cluster plutôt que sur des VM)
- OpenShift Data Foundation (si vous utilisez ODF pour le stockage)
- Velero / OADP (OpenShift API for Data Protection) pour la sauvegarde
Logiciels externes :
- OpenBao ≥ dernière version stable, configuré avec le stockage intégré Raft
- GitLab (auto-hébergé) ou accès à GitLab SaaS
- Redis ≥ 7 (cluster shardé) — StatefulSet in-cluster ou sur VM
Réseau
| Flux | Source | Destination | Port |
|---|---|---|---|
| Utilisateur → app | Clients | Ingress Router | 443/TCP |
| App → secrets | Nœuds de travail | VM OpenBao | 8200/TCP |
| App → base de données | Nœuds de travail | Primaire/réplicas PostgreSQL | 5432/TCP |
| GitOps → source | ArgoCD | GitLab | 443/TCP, 22/TCP |
| Sauvegarde | Cluster / Velero | Stockage objet | 443/TCP |
| OpenBao → HSM (optionnel) | VM OpenBao | HSM | selon le fournisseur HSM |
Exigences :
- Enregistrement DNS wildcard (p. ex.
*.duokey.example.local) pointant vers le VIP de l'Ingress Router. - Certificats TLS pour le ou les noms d'hôte de l'application — une AC interne convient pour les sites en air-gap.
- Segmentation réseau recommandée : VLAN séparés pour le trafic applicatif, sécurisé (HSM) et backend/stockage.
- Pour les installations en air-gap : un registre miroir (p. ex. Quay / mirror.registry) pour les images de version et d'opérateur OpenShift.
Garde des clés : DuoKey MPC et/ou HSM
La racine de confiance principale de DuoKey est son propre calcul multipartite (MPC) : le matériel de clé est divisé en parts de sorte qu'aucun nœud ni administrateur ne détient jamais une clé complète — aucun matériel HSM dédié requis.
Pour les déploiements qui nécessitent également une racine de confiance matérielle, DuoKey s'intègre avec le HSM Securosys (PKCS#11 / KMIP). Fournissez :
- L'accessibilité réseau depuis les VM OpenBao vers le HSM Securosys (ou le point de terminaison Securosys Cloud HSM / CloudsJMS), idéalement sur un VLAN dédié et renforcé.
- Les identifiants client HSM / la partition configurés pour OpenBao.
Accès et compétences
- Accès cluster-admin au cluster OpenShift.
- Accès administratif à l'hyperviseur des VM et au DNS.
- Familiarité avec
oc/kubectl, les concepts GitOps et les opérations OpenBao.
Une fois ces éléments en place, passez à Installation.