By Leave a Comment on Architecture de référence de Vault

Le but de ce document est de recommander des pratiques de déploiement de Vault HashiCorp. Cette architecture de référence véhicule une architecture généralequi doit être adaptée pour répondre aux besoins spécifiques de chaque mise en œuvre.

Les sujets suivants sont abordés dans ce guide :

  • Résumé de la conception
    • Connectivité réseau
    • Tolérance aux pannes
  • Architecture recommandée
    • Déploiement à région unique (entreprise)
    • Déploiement à régions multiples. multiples (Enterprise)
  • Architecture du meilleur cas
    • Déploiement de Vault dans une zone de disponibilité (tous)
    • Déploiement de Vault dans deux zones de disponibilité (OSS)
    • Déploiement de Vault dans deux zones de disponibilité (Enterprise)
      • Déploiement de Vault dans une zone de disponibilité (OSS)
      • Déploiement de Vault dans une zone de disponibilité (OSS)
      • . deux zones de disponibilité (Entreprise)
      • Déploiement de Vault dans trois zones de disponibilité (OSS)
    • Réplication de Vault (Entreprise uniquement)
    • Configuration du système de déploiement
      • Matériel. Considérations
    • Équilibrage de charge
    • Références supplémentaires

    « Glossaire

    « Cluster Vault

    Un cluster Vault est un ensemble de processus Vault qui exécutent ensemble un service Vault.Ces processus Vault peuvent être exécutés sur des serveurs physiques ou virtuels, ou dans des conteneurs.

    « Cluster de backend de stockage Consul

    HashiCorp recommande et supporte l’utilisation de Consul comme backend de stockage pourVault. Un cluster Consul est un ensemble de processus de serveur Consul qui, ensemble, exécutent un serviceConsul. Ces processus Consul pourraient être exécutés sur des serveurs physiques ou virtuels, ou dans des conteneurs.

    « Zone de disponibilité

    Un domaine de défaillance unique au niveau d’un emplacement qui héberge une partie ou la totalité d’un clusterVault. La latence entre les zones de disponibilité doit être < 8ms pour un aller-retour. Un seul cluster Vault peut être réparti sur plusieurs zones de disponibilité.

    Les exemples d’une zone de disponibilité dans ce contexte sont :

    • Un centre de données isolé
    • Une cage isolée dans un centre de données si elle est isolée des autres cages par tous les autres moyens (alimentation, réseau, etc)
    • Une zone de disponibilité dans AWS, Azure ou GCP

    « Région

    Un ensemble géographiquement séparé d’une ou plusieurs zones de disponibilité. Une région hébergerait un ou plusieurs clusters Vault. Il n’existe aucune exigence de latence maximale définie entre les régions dans l’architecture Vault. Un seul cluster Vault ne serait pas réparti sur plusieurs régions.

    « Résumé de la conception

    Cette conception est l’architecture recommandée pour les environnements de production, car elleprocure flexibilité et résilience.

    C’est une recommandation d’architecture majeure que les serveurs Consul soient séparés des serveurs Vault et que le cluster Consul soit uniquement utilisé comme backend de stockage pour Vault et non pour d’autres fonctionnalités centrées sur Consul (par exemple, la segmentation des services et la découverte de services) qui peuvent introduire une utilisation imprévisible des ressources. La séparation de Vault et de Consul permet à chacun de disposer d’un système qui peut être dimensionné de manière appropriée en termes de CPU, de mémoire et de disque. Consul est une application gourmande en mémoire et il est donc avantageux de la séparer de ses propres ressources pour éviter les conflits de ressources ou la famine. Dédier un cluster Consul en tant que backend de stockage Vault est également avantageux, car cela permet au cluster Consul d’être mis à niveau uniquement si nécessaire pour améliorer la fonctionnalité du backend de stockage Vault.Ceci est susceptible d’être beaucoup moins fréquent qu’un cluster Consul qui est également utilisé pour la découverte de services et la segmentation de services.

    La connectivité de Vault au backend Consul se fait via HTTP et doit être sécurisée avec TLSainsi qu’un jeton Consul pour fournir le chiffrement de tout le trafic. Consultez le guide de déploiement de Vault pour plus d’informations. Comme le cluster de stockage de Vault peut être utilisé séparément d’un cluster Consul pour la découverte de services, il est recommandé d’exécuter le processus Consul de stockage sur des ports autres que ceux par défaut afin d’éviter tout conflit avec les autres fonctionnalités de Consul. Pour ce faire, il suffit de définir le cluster de stockage Consul sur le port 7xxx et de l’utiliser comme port de stockage dans la configuration de Vault. Il est également recommandé d’exécuter Consul en utilisant TLS.

    Référez-vous à la documentation en ligne pour en savoir plus sur l’exécution de Consul en mode crypté.

    « Détails de la connectivité réseau

    Le tableau suivant présente les exigences en matière de trafic réseau pour les clustersternodes Vault.

    .

    .

    Source Destination port protocole Direction But
    Consul. clients et serveurs Consul Server 7300 TCP incoming Server RPC
    Consul clients Consul clients Consul clients 7301 TCP et UDP bidirectionnel Communications par commérage Lan
    Clientsault Serveursault 8200 TCP Incoming Vault API
    Vault servers Vault servers 8201 TCP bidirectional Vault replication traffic, transfert de demande

    Notez que le processus Consul s’exécute sur des ports non par défaut (7xxx) comme décrit dans le résumé de conception.

    « Configurations réseau alternatives

    Vault peut être configuré de plusieurs façons distinctes pour les communications entre les clustersVault et Consul :

    • Utilisation d’adresses IP d’hôtes ou de noms d’hôtes qui sont résolvables via le sous-système nommé standard
    • Utilisation d’adresses IP d’équilibreurs de charge ou de noms d’hôtes qui sont résolvables via le sous-système nommé standard
    • Utilisation du cluster Consul attaché. DNS en tant que découverte de service pour résoudre les points d’extrémité Vault
    • Utilisation d’un cluster de découverte de service Consul séparé DNS en tant que découverte de service pour résoudre les points d’extrémité Vault

    Toutes ces options sont explorées plus en détail dans le guide de déploiement Vault.

    « Tolérance aux pannes

    Vault est conçu pour gérer différents scénarios de panne qui ont différentesprobabilités. Lors du déploiement d’un cluster Vault, la tolérance de panne dont vous avez besoin doit être prise en compte et conçue. Dans OSS Vault, le nombre d’instances recommandé est de 3 dans un cluster, car un nombre supérieur aurait une valeur limitée. Dans Vault Enterprise, le nombre recommandé est également de 3 dans un cluster, mais il est possible d’en utiliser davantage s’il s’agit d’instances de test de performance pour aider à gérer la charge de travail en lecture seule. Le cluster Consul compte de une à sept instances, ce qui doit être un nombre impair pour permettre la résolution des élections de dirigeants. Il est recommandé que le cluster Consul soit d’au moins cinq instances qui sont dédiées à l’exécution des fonctions de stockage dorsales pour le cluster Vault uniquement.

    Référez-vous à la documentation en ligne pour en savoir plus sur le processus d’élection des dirigeants de Consul.

    « Node

    Le logiciel de cluster Vault et Consul permet un domaine de défaillance au niveau du nœud en ayant une réplication au sein du cluster. Dans un cluster HA Vault unique, tous les nœuds partagent le même backend de stockage sous-jacent et donc les données. Pour résoudre ce problème, l’un des serveurs Vault obtient un verrou dans le magasin de données pour devenir le nœud Vault actif, avec un accès en écriture. Si, à tout moment, le leader est perdu, un autre nœud Vault prend sa place de manière transparente. Pour obtenir une redondance n-2 (où la perte de 2 objets dans le domaine de défaillance peut être tolérée), la taille idéale d’un cluster Vault serait de 3. Consul assure la réplication et le leadership grâce à ses protocoles consensus et gossip. Dans ces protocoles, un leader est élu par consensus et un aquorum de serveurs actifs doit donc toujours exister. Pour obtenir une redondance n-2, la taille idéale d’un cluster Consul est de 5. Voir ConsulInternals pour plus de détails.

    « Zone de disponibilité

    La distribution typique dans un environnement cloud consiste à répartir les nœuds Consul/Vault dans des zones de disponibilité (AZ) séparées au sein d’un réseau à large bande passante et à faible latence,tel qu’une région AWS, mais cela peut ne pas être possible dans une installation de datacenter où il n’y a qu’un seul DC dans le niveau de latence requis.

    Il est important de comprendre un changement d’exigence ou de meilleures pratiques qui est survenu à la suite de l’évolution vers une plus grande utilisation des systèmes hautement distribués tels que Consul. Lorsque l’on exploite des environnements composés de systèmes distribués, il faut modifier le coefficient de redondance des composants sous-jacents. Consul s’appuie sur la négociation par consensus pour organiser et reproduire l’information, et l’environnement doit donc fournir trois voies de résilience uniques afin d’assurer une fiabilité significative. Essentiellement, un système consensuel exige qu’une simple majorité de nœuds soit disponible à tout moment. Dans l’exemple de 3 nœuds, 2 doivent être disponibles. Si ces 3 nœuds sont placés dans deux domaines de défaillance, il y a 50 % de chances que la perte d’un seul domaine de défaillance entraîne une panne complète.

    « Région

    Pour se protéger contre une défaillance au niveau de la région, ainsi que pour fournir des capacités d’échelonnement géographique supplémentaires, Vault Enterprise offre :

    • Réplication de reprise après sinistre
    • Réplication de performance

    Veuillez consulter les modèles recommandés sur la réplication de Vault pour une description complète de ces options.

    En raison des contraintes énumérées ci-dessus, l’architecture recommandée est avecVault et Consul Enterprise répartis sur trois zones de disponibilité au sein d’un cluster et pour les clusters à répliquer à travers les régions en utilisant la réplication DR etPerformance. Il existe également plusieurs architectures « Best Case » : des solutions pour une et deux zones de disponibilité ainsi que pour Consul OSS. Ce ne sont pas l’architecture recommandée, mais ce sont les meilleures solutions si votre déploiement est limité par la version de Consul ou le nombre de zones de disponibilité.

    « Architecture recommandée

    L’architecture ci-dessous est la meilleure approche recommandée pour le déploiement de Vault et devrait être l’architecture cible pour toute installation. Elle est divisée en deux parties :

    • Cluster de chambre forte – Il s’agit de l’architecture recommandée pour un cluster de chambre forte en tant qu’entité unique, mais il devrait également utiliser la réplication selon le deuxième diagramme
    • Réplication de chambre forte – Il s’agit de l’architecture recommandée pour plusieurs clusters de chambre forte afin de permettre une reprise régionale, de performance et de catastrophe.

    « Déploiement à région unique (entreprise)

    Dans ce scénario, les nœuds Vault et son cluster Consul associé sont hébergés entre trois zones de disponibilité. Cette solution présente un n-2 au niveau des nœuds pour Vault et un n-3 au niveau des nœuds pour Consul. Au niveau de la zone de disponibilité, Vault est à n-2 et Consul à n-1. Cette conception diffère de celle de l’OSS dans la mesure où le cluster Consul compte six nœuds, dont trois sont des membres sans droit de vote. Le clusterConsul est configuré à l’aide de zones de redondance de sorte que si un nœud devait tomber en panne, un membre sans droit de vote serait promu par Autopilot pour devenir un membre à part entière et ainsi maintenir le quorum.

    « Déploiement à régions multiples (entreprise)

    « Diagramme de référence Résilience contre une panne de région

    Dans ce scénario, les clusters sont répliqués pour se prémunir contre une panne de région complète. Il existe trois clusters Performance Replica Vault (clusters A, B, C)chacun avec son propre cluster DR (clusters D, E, F) dans une région différente. Chaque cluster a son cluster Consul associé pour le backend de stockage.

    Cette architecture permet d’avoir n-2 au niveau de la région à condition que tous les secrets et moteurs de secrets soient répliqués sur tous les clusters. Une défaillance de la région complète Region1 nécessiterait la promotion du cluster DR F. Une fois que cela a été fait, la Vaultsolution serait entièrement fonctionnelle avec une certaine perte de redondance jusqu’à ce que la Région 1 soit restaurée. Les applications n’auraient pas à se réauthentifier car le DRcluster pour chaque cluster défaillant contiendrait tous les baux et jetons.

    « Diagramme de référence Résilience contre la défaillance du cluster

    Cette solution a une résilience complète au niveau du cluster, mais ne se prémunit pas contre la défaillance de la région car les DR clusters pour les répliques de performance sont dans la même région. Dans certains cas, il s’agit de la méthode préférée lorsque les données ne peuvent pas être répliquées dans d’autres régions en raison de restrictions de gouvernance telles que le GDPR. De même, certains cadres d’infrastructure peuvent ne pas avoir la capacité de router le trafic des applications vers différentes régions.

    « Best Case Architecture

    Dans certains déploiements, il peut y avoir des restrictions insurmontables qui signifient que l’architecture recommandée n’est pas possible. Cela peut être dû à un manque de zones de disponibilité ou à l’utilisation de Vault OSS. Dans ces cas, lesarchitectures ci-dessous détaillent les meilleures options de cas disponibles.

    Notez que dans ces architectures suivantes, le leader Consul peut être l’un des cinq nœuds de serveur Consul et le nœud actif Vault peut être l’un des trois nœuds Vault

    « Déploiement de Vault dans une zone de disponibilité (tous)

    Dans ce scénario, tous les nœuds Vault et son cluster Consul associé sont hébergés dans une zone de disponibilité. Cette solution présente un point de défaillance unique au niveau de la zone de disponibilité, mais un n-2 au niveau des nœuds pour Consul etVault. Cette architecture n’est pas recommandée par Hashicorp pour les systèmes de production, car il n’y a pas de redondance au niveau de la zone de disponibilité. Il n’y a pas non plus de capacité de DR et donc au minimum cela devrait avoir une réplique DR dans une région séparée.

    « Déploiement de Vault dans deux zones de disponibilité (OSS)

    Dans ce scénario, les nœuds Vault et son cluster Consul associé sont hébergés entre deux zones de disponibilité. Cette solution présente un n-2 au niveau du nœud pour Vault et Consul et un n-1 pour Vault au niveau de la zone de disponibilité, maisl’ajout d’une zone de disponibilité n’augmente pas significativement la disponibilité du cluster Consul. En effet, le protocole Raft requiert un aquorum de (n/2)+1 et si la zone B devait tomber en panne dans le diagramme ci-dessus, le cluster ne serait pas quorum et tomberait également en panne. Ce n’est pas l’architecture Hashicorprecommandée pour les systèmes de production car il n’y a qu’une redondance partielle au niveau de la zone de disponibilité et une défaillance de la zone de disponibilité peut ne pas entraîner une panne.

    « Déploiement de Vault dans deux zones de disponibilité (Entreprise)

    En raison de la nécessité de maintenir le quorum dans le cluster Consul, avoir seulement 2Zones de disponibilité n’est pas idéal. Il n’y a aucun moyen de répartir un cluster Consul sur deux AZ avec une garantie de résilience supplémentaire. La meilleure solution dansVault Enterprise est de traiter les deux AZ comme des régions et d’avoir des clusters Vault distincts dans chacune.

    Le cluster Vault secondaire peut être soit une réplique de performance, soit une réplique DR, chacune ayant ses propres avantages :

    • PR secondaire : Si l’adresse Vault est gérée par Consul ou par un équilibreur de charge, alors une défaillance de l’un ou l’autre des clusters aura pour conséquence de diriger le trafic vers l’autre cluster sans interruption, à condition qu’il y ait une logique dans votre application ou dans l’agent Vault pour gérer la redemande de jetons qui ne sont pas répliqués entre les clusters.
    • DR secondaire : Dans ce cas, la défaillance du cluster primaire entraînera la nécessité d’une intervention de l’opérateur pour promouvoir le DR au primaire, mais comme toutes les locations et les jetons sont répliqués, il n’y aurait pas besoin d’une logique supplémentaire dans l’application pour gérer cela.

    « Déploiement de Vault dans trois zones de disponibilité (OSS)

    Dans ce scénario, les nœuds de Vault et le cluster Consul associé sont hébergés entre trois zones de disponibilité. Cette solution présente un n-2 au niveau des nœuds pour Vault et Consul et n-2 pour Vault au niveau de la zone de disponibilité.Elle présente également un n-1 au niveau de la zone de disponibilité pour Consul et, en tant que telle, est considérée comme la plus résiliente de toutes les architectures pour un seul cluster Vault avec un backend de stockage Consul pour le produit OSS.

    « Vault Replication (Enterprise Only)

    Dans ces architectures, le cluster Vault est illustré comme une seule entité, et serait l’un des clusters uniques détaillés ci-dessus en fonction de votre nombre de zones de disponibilité. Plusieurs clusters Vault agissant comme une seule Vaultsolution et répliquant entre eux est disponible dans Enterprise Vault seulement. OSSVault peut être configuré en plusieurs clusters, mais ils seraient chacun des solutions Vault individuelles et ne prendraient pas en charge la réplication entre les clusters.

    La documentation Vault fournit des informations plus détaillées sur les capacités de réplication dans VaultEnterprise.

    « Réplication des performances

    La réplication des performances Vault permet de gérer les secrets sur de nombreux sites.Les secrets statiques, les méthodes d’authentification et les politiques d’autorisation sont répliqués pour être actifs et disponibles sur plusieurs sites, mais les leasestokens et les secrets dynamiques ne le sont pas.

    NOTE : Reportez-vous au tutoriel Vault Mount Filtertutorial sur le filtrage des moteurs de secrets pour qu’ils ne soient pas répliqués sur plusieurs régions.

    « Réplication de reprise après sinistre

    La réplication de reprise après sinistre de Vault garantit qu’un cluster Vault en veille est keptsynchronisé avec un cluster Vault actif. Ce mode de réplication inclut des données telles que les jetons d’authentification éphémères, les informations sur les jetons basés sur le temps ainsi que les données d’utilisation des jetons. Cela permet d’atteindre un objectif de point de récupération agressif dans les environnements où la prévention de la perte de données opérationnelles éphémères est la plus importante. Dans toute solution d’entreprise, les répliques de reprise après sinistre sontconsidérées comme essentielles.

    NOTE : Reportez-vous au didacticiel Vault Disaster Recovery Setuptutorial pour des informations supplémentaires.

    « Corruption ou sabotage de la reprise après sinistre

    Un autre scénario courant contre lequel il faut se protéger, plus répandu dans les environnements cloud qui fournissent des niveaux très élevés de résilience intrinsèque, pourrait être la corruption intentionnelle ou accidentelle des données et de la configuration, et/ou une perte de contrôle du compte cloud. La réplication DR de Vault est conçue pour répliquer les données en direct, ce qui propagerait la corruption ou la suppression intentionnelle ou accidentelle des données. Pour vous prémunir contre ces risques, vous devez sauvegarder le back-end de stockage de Vault, grâce à la fonction ConsulSnapshot, qui peut être automatisée pour des sauvegardes d’archives régulières. Un site froid ou une nouvelle infrastructurepourrait être réhydraté à partir d’un instantané de Consul.

    NOTE : Reportez-vous à la documentation en ligne pour en savoir plus sur les instantanés de Consul

    « Notes sur la réplication

    Il n’y a pas de limite définie sur le nombre de clusters dans un ensemble de réplication. Les déploiements les plus importants aujourd’hui se situent dans la gamme des 30+ clusters. Un cluster Performance Replica peut avoir un cluster de reprise après sinistre associé et peut également répliquer vers plusieurs clusters de reprise après sinistre.

    Bien qu’un cluster Vault puisse posséder un rôle (ou des rôles) de réplication, il n’y a pas de considérations particulières requises en termes d’infrastructure, et les clusters peuvent assumer (ou être promus ou rétrogradés) un autre rôle. Des circonstances particulières liées aux filtres de montage et à l’utilisation du module de sécurité matériel (HSM) peuvent limiter le changement de rôle, mais celles-ci sont basées sur des configurations d’organisation spécifiques.

    « Considérations liées à l’intégration du HSM

    L’utilisation de la réplication avec des clusters Vault intégrés au module de sécurité matériel (HSM) ou à des dispositifs de descellement automatique dans le cloud pour des opérations de descellement automatisées présente certains détails qui doivent être compris pendant la phase de planification.

    • Si un cluster primaire de performance utilise un HSM, tous les autres clusters dans cet ensemble de réplication doivent également utiliser un HSM.
    • Si un cluster primaire de performance n’utilise PAS un HSM (utilise la méthode de partage de secrets Shamir), les clusters au sein de cet ensemble de réplication peuvent être mélangés, de sorte que certains peuvent utiliser un HSM, d’autres peuvent utiliser Shamir.

    Ce comportement est par conception. Un cluster Shamir en aval présente un vecteur d’attaque potentiel dans le groupe de réplication puisqu’un seuil de détenteurs de clés pourraitcréer la clé maîtresse ; par conséquent, contourner la protection des clés HSM en amont.

    Vault 1.3 et ultérieur : À partir de Vault 1.3, la clé maîtresse est chiffrée avec des clés partagées et stockée sur le disque de façon similaire à la façon dont une clé maîtresse est chiffrée par la clé d’autodéverrouillage et stockée sur le disque. Cela permet d’obtenir un comportement cohérent, que vous utilisiez l’algorithme de partage du secret de Shamir ou l’auto-scellement, et permet aux trois scénarios ci-dessus d’être valides. Cependant, si Vault protège des données soumises à des exigences de gouvernance et de conformité réglementaire, il estrecommandé de mettre en œuvre un HSM en aval pour l’auto-unseal.

    « Exigences du système de déploiement

    Le tableau suivant fournit des directives pour le dimensionnement des serveurs. Il convient de noter en particulier la forte recommandation d’éviter les processeurs à performance non fixe, ou BurstableCPU en termes AWS, tels que les instances de la série T.

    « Dimensionnement des serveurs Vault

    .

    Taille CPU Mémoire Disque Typical Cloud Instance Types
    Small 2 core 4-.8 GB RAM 25 GB AWS : m5.large
    Azure : Standard_D2_v3
    GCE : n1-standard-2, n1-standard-4
    Large 4-8 core 16-32 GB RAM 50 GB AWS : m5.xlarge, m5.2xlarge
    Azure : Standard_D4_v3, Standard_D8_v3
    GCE : n1-standard-8, n1-standard-16

    « Dimensionnement pour les serveurs Consul

    Taille CPU Mémoire Disk Typical Cloud Instance Types
    Small 2 core 8-.16 GB RAM 50 GB AWS : m5.large, m5.xlarge
    Azure : Standard_D2_v3, Standard_D4_v3
    GCE : n1-standard-4, n1-standard-8
    Large 4-8 core 32-64+ GB RAM 100 GB AWS : m5.2xlarge, m5.4xlarge
    Azure : Standard_D4_v3, Standard_D8_v3
    GCE : n1-standard-16, n1-standard-32

    « Considérations matérielles

    La catégorie de petite taille serait appropriée pour la plupart des déploiements initiaux de production, ou pour les environnements de développement/test.

    La grande taille est pour les environnements de production où il y a une charge de travail élevée constante. Cela peut être un grand nombre de transactions, un grand nombre de secrets, ou une combinaison des deux.

    En général, les exigences de traitement dépendront de la charge de travail de chiffrement et de la charge de travail de messagerie (opérations par seconde, et types d’opérations). Les besoins en mémoire dépendront de la taille totale des secrets/clés stockés en mémoire et devraient être dimensionnés en fonction de ces données (tout comme le stockage sur disque dur). Vault lui-même a des exigences de stockage minimales, mais le backend de stockage sous-jacent devrait avoir un sous-système de disque dur relativement performant.Si de nombreux secrets sont générés/rotés fréquemment, ces informations devront être flushées sur le disque souvent et peuvent avoir un impact sur les performances si des disques durs plus lents sont utilisés.

    La fonction des serveurs Consul dans ce déploiement est de servir de backend de stockage pour Vault. Cela signifie que tout le contenu stocké pour la persistance dans Vault est chiffré par Vault, et écrit sur le backend de stockage au repos. Ces données sont écrites dans la section key-value store du catalogue de services de Consul, qui doit être stocké dans son intégralité en mémoire sur chaque serveur Consul. Cela signifie que la mémoire peut être une contrainte dans la mise à l’échelle, car plus de clients s’authentifient à Vault, plus de secrets sont stockés de façon persistante dans Vault et plus de secrets temporaires sont loués à Vault. Cela a également pour effet de nécessiter une mise à l’échelle verticale sur la mémoire du serveurConsul si un espace supplémentaire est nécessaire, car l’ensemble du ServiceCatalog est stocké en mémoire sur chaque serveur Consul.

    En outre, le débit du réseau est une considération commune pour Vault et les serveurs Consuls. Comme les deux systèmes sont pilotés par l’API HTTPS, toutes les demandes entrantes,les communications entre Vault et Consul, les communications gossip sous-jacentes entre les membres du clusterConsul, les communications avec des systèmes externes (selon la configuration auth ou secretengine, et certaines configurations de journalisation d’audit) et les réponsesconsomment de la bande passante réseau.

    En raison des considérations de performance réseau dans les opérations du cluster Consul,la réplication des ensembles de données Vault à travers les frontières du réseau devrait être réalisée par la réplication de performance ou DR, plutôt que d’étendre le cluster Consul à travers les frontières réseau et physiques. Si un seul cluster Consul est réparti sur des segments de réseau distants ou interrégionaux, cela peut entraîner des problèmes de synchronisation au sein du cluster ou des frais de transfert de données supplémentaires chez certains fournisseurs de cloud.

    « Autres considérations

    Recommandations de durcissement de production de Vaultfournit des conseils sur les meilleures pratiques pour un déploiement durci de production de Vault.

    « Équilibrage de la charge

    « Équilibrage de la charge à l’aide de l’interface Consul

    Consul peut fournir des capacités d’équilibrage de la charge par la découverte de services, mais il exige que tout client Vault soit conscient de Consul. Cela signifie qu’un client ne peut ni utiliser les interfaces DNS ou API de Consul pour résoudre le nœud Vault actif. Un client pourrait accéder à Vault via une URL comme la suivante :http://active.vault.service.consul:8200

    Ceci repose sur le système de résolution DNS du système d’exploitation, et la requête pourrait être transmise à Consul pour la réponse de l’adresse IP réelle. Cette opération peut être totalement transparente pour les applications existantes et fonctionnerait comme une opération de résolution DNS atypique. Voir Consul DNSforwarding pour plus d’informations

    « Équilibrage de charge à l’aide d’un équilibreur de charge externe

    Les équilibreurs de charge externes sont pris en charge comme point d’entrée dans un cluster Vault. L’équilibreur de charge externe doit interroger le point de terminaison thesys/health pour détecter le nœud actif et router le trafic en conséquence. L’équilibreur de charge doit être configuré pour effectuer une requête HTTP pour l’URL suivante à chaque nœud du cluster vers : http://<Vault Node URL>:8200/v1/sys/health

    Le nœud actif de la voûte répondra par un 200 tandis que les nœuds en attente renverront une réponse 4xx.

    Voici un exemple de bloc de configuration de HAProxy pour illustrer:

    listen vault bind 0.0.0.0:80 balance roundrobin option httpchk GET /v1/sys/health server vault1 192.168.33.10:8200 check server vault2 192.168.33.11:8200 check server vault3 192.168.33.12:8200 check

    Copy

    Notez que le bloc ci-dessus pourrait être généré par Consul (avec consul-template)lorsqu’un équilibreur de charge logiciel est utilisé. Cela pourrait être le cas lorsque l’équilibreur de charge est un logiciel comme Nginx, HAProxy ou Apache.

    Exemple de modèle Consul pour le bloc HAProxy ci-dessus:

    listen vault bind 0.0.0.0:8200 balance roundrobin option httpchk GET /v1/sys/health{{range service "vault"}} server {{.Node}} {{.Address}}:{{.Port}} check{{end}}

    Copy

    « Gestion des adresses IP des clients

    Il existe deux méthodes prises en charge pour gérer l’adressage IP des clients derrière un proxyou un équilibreur de charge ; X-Forwarded-ForHeaderset PROXYv1.Les deux nécessitent un équilibreur de charge de confiance et une adresse IP à répertorier comme adresses autorisées pour adhérer aux meilleures pratiques de sécurité.

    « Références supplémentaires

    • La documentation sur l’architecture de Vault expliquechaque composant de Vault
    • Pour intégrer Vault à un serveur LDAP existant, reportez-vous à la documentation sur la méthode d’authentification LDAP
    • Référez-vous au tutoriel AppRole PullAuthentication pour générer de manière programmatique un jeton pour une machine ou une app
    • Consul fait partie intégrante de l’exécution d’un cluster Vault résilient, quel que soit son emplacement. Reportez-vous à la documentation en ligne de Consul pour en savoir plus.

    « Étapes suivantes

    • Lisez Production Hardening (durcissement de la production) pour connaître les meilleures pratiques de déploiement de Vault en production.
    • Lisez le guide de déploiement pour connaître les étapes nécessaires à l’installation et à la configuration d’un seul cluster Vault HashiCorp.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.