Free Press

El objetivo de este documento es recomendar prácticas de implementación de Vault de HashiCorp. Esta arquitectura de referencia transmite una arquitectura general que debe ser adaptada para acomodar las necesidades específicas de cada implementación.

En esta guía se tratan los siguientes temas:

• Resumen de diseño
  • Conectividad de red
  • Tolerancia a fallos
• Arquitectura recomendada
  • Despliegue en una sola región (empresa)
  • Despliegue en múltiples regiones Despliegue (Empresa)
• Arquitectura del mejor caso
  • Despliegue de Vault en una zona de disponibilidad (todas)
  • Despliegue de Vault en dos zonas de disponibilidad (OSS)
  • Despliegue de Vault en dos zonas de disponibilidad (Enterprise)
  • Despliegue de Vault en tres zonas de disponibilidad (OSS)
• Replicación de Vault (sólo Enterprise)
• Requisitos del sistema de despliegue
  • Hardware Consideraciones
• Equilibrio de carga
• Referencias adicionales

«Glosario

«Cluster de Vault

Un cluster de Vault es un conjunto de procesos de Vault que juntos ejecutan un servicio de Vault.Estos procesos de Vault pueden ejecutarse en servidores físicos o virtuales, o en contenedores.

«Clúster de backend de almacenamiento Consul

HashiCorp recomienda y apoya el uso de Consul como backend de almacenamiento paraVault. Un clúster de Consul es un conjunto de procesos de servidor de Consul que juntos ejecutan un servicio deConsul. Estos procesos de Consul pueden ejecutarse en servidores físicos o virtuales, o en contenedores.

«Zona de disponibilidad

Un único dominio de fallo a nivel de ubicación que aloja parte o la totalidad de un clúster deVault. La latencia entre las zonas de disponibilidad debe ser de < 8ms para un viaje de ida y vuelta. Un único clúster de Vault puede estar repartido en varias zonas de disponibilidad.

Ejemplos de una zona de disponibilidad en este contexto son:

• Un centro de datos aislado
• Una jaula aislada en un centro de datos si está aislada de otras jaulas por todos los demás medios (energía, red, etc)
• Una zona de disponibilidad en AWS, Azure o GCP

«Región

Una colección geográficamente separada de una o más zonas de disponibilidad. Una región podría albergar uno o más clústeres de Vault. No hay un requisito de latencia máxima definido entre regiones en la arquitectura de Vault. Un único clúster de Vault no se repartiría entre varias regiones.

«Resumen del diseño

Este diseño es la arquitectura recomendada para los entornos de producción, ya que proporciona flexibilidad y resistencia.

Una de las principales recomendaciones de la arquitectura es que los servidores de Consul estén separados de los servidores de Vault y que el clúster de Consul sólo se utilice como extremo de almacenamiento para Vault y no para otras funcionalidades centradas en Consul (por ejemplo, segmentación de servicios y descubrimiento de servicios), que pueden introducir una utilización impredecible de los recursos. Separar Vault y Consul permite que cada uno de ellos tenga un sistema que puede ser dimensionado adecuadamente en términos de CPU, memoria y disco. Consul es una aplicación que hace un uso intensivo de la memoria, por lo que separarla de sus propios recursos es ventajoso para evitar la contención de recursos o la inanición. Dedicar un clúster de Consul como backend de almacenamiento de Vault también es ventajoso, ya que esto permite que el clúster de Consul se actualice sólo cuando sea necesario para mejorar la funcionalidad del backend de almacenamiento de Vault, lo que probablemente será mucho menos frecuente que un clúster de Consul que también se utilice para el descubrimiento de servicios y la segmentación de servicios.

La conectividad del backend de Vault con Consul se realiza a través de HTTP y debe asegurarse con TLS, así como con un token de Consul para proporcionar el cifrado de todo el tráfico. Consulte la Guía de implementación de Vault para obtener más información. Dado que el clúster de Consul para el almacenamiento de Vault puede utilizarse además y por separado de un clúster de Consul para el descubrimiento de servicios, se recomienda que el proceso de Consul para el almacenamiento se ejecute en puertos no predeterminados para que no entre en conflicto con otra funcionalidad de Consul. Esto se consigue configurando el clúster de almacenamiento de Consul para que se ejecute en los puertos 7xxx y utilizándolo como puerto de almacenamiento en la configuración de Vault. También se recomienda que Consul se ejecute utilizando TLS.

«Detalles de conectividad de red

La siguiente tabla describe los requisitos de tráfico de red para los clusternodes de Vault.

«Configuraciones de Red Alternativas

Vault puede configurarse de varias maneras distintas para las comunicaciones entre los Clusters deVault y Consul:

• Usando direcciones IP de host o nombres de host que son resolubles a través del subsistema de nombres estándar
• Usando direcciones IP del equilibrador de carga o nombres de host que son resolubles viastandard named subsystem
• Usando el cluster Consul adjunto DNS como descubrimiento de servicios para resolver los puntos finales de Vault
• Usando un cluster separado de descubrimiento de servicios de Consul DNS como descubrimiento de servicios para resolver los puntos finales de Vault

Todas estas opciones se exploran más en la Guía de Implementación de Vault.

«Tolerancia a fallos

Vault está diseñado para manejar diferentes escenarios de fallos que tienen diferentesprobabilidades. Al desplegar un clúster de Vault, se debe considerar y diseñar la tolerancia a fallos que se requiere. En OSS Vault el número recomendado de instancias es de 3 en un clúster, ya que más tendría un valor limitado. En Vault Enterprise el número recomendado es también de 3 en un clúster, pero se pueden utilizar más si se trata de pruebas de rendimiento para ayudar con la carga de trabajo de sólo lectura. El clúster Consul es de una a siete instancias. Este debe ser un número impar para permitir que las elecciones de liderazgo se resuelvan siempre. Se recomienda que el clúster Consul tenga al menos cinco instancias que se dediquen a realizar funciones de almacenamiento backend para el clúster Vault únicamente.

«Nodo

El software del clúster Vault y Consul permite un dominio de fallos a nivel de nodo al tener replicación dentro del clúster. En un único clúster de HA de Vault, todos los nodos comparten el mismo backend de almacenamiento subyacente y, por tanto, los datos. Vault lo consigue mediante la obtención de un bloqueo en el almacén de datos por parte de uno de los servidores de Vault para convertirse en el nodo activo de Vault, que tiene acceso de escritura. Si en algún momento se pierde el líder, otro nodo Vault ocupará su lugar sin problemas. Para conseguir una redundancia n-2 (en la que se puede tolerar la pérdida de 2 objetos dentro del dominio de fallo), el tamaño ideal de un clúster Vault sería de 3. Consul consigue la replicación y el liderazgo mediante el uso de sus protocolos consensus ygossip. En estos protocolos, se elige un líder por consenso, por lo que siempre debe existir un quórum de servidores activos. Para lograr una redundancia n-2, el tamaño ideal de un clúster de Consul es de 5. Véase ConsulInternals para obtener más detalles.

«Zona de disponibilidad

La distribución típica en un entorno de nube es distribuir los nodos de Consul/Vault en zonas de disponibilidad (AZ) separadas dentro de una red de gran ancho de banda y baja latencia, como una región de AWS; sin embargo, esto puede no ser posible en una instalación de centro de datos donde sólo hay un DC dentro del nivel de latencia requerido.

Es importante entender un cambio en los requisitos o en las mejores prácticas que ha surgido como resultado del movimiento hacia una mayor utilización de sistemas altamente distribuidos como Consul. Cuando se operan entornos compuestos por sistemas distribuidos, se requiere un cambio en el coeficiente de redundancia de los componentes subyacentes. Consul se basa en la negociación por consenso para organizar y replicar la información, por lo que el entorno debe proporcionar 3 rutas de resistencia únicas para proporcionar una fiabilidad significativa. Esencialmente, un sistema de consenso requiere que una mayoría simple de nodos esté disponible en cualquier momento. En el ejemplo de 3 nodos, debe haber 2 disponibles. Si esos 3 nodos se colocan en dos dominios de fallo, hay un 50% de posibilidades de que la pérdida de un solo dominio de fallo provoque una interrupción completa.

«Región

Para protegerse contra un fallo a nivel de región, así como para proporcionar capacidades adicionales de escalado geográfico, Vault Enterprise ofrece:

• Replicación de recuperación de desastres
• Replicación de rendimiento

Por favor, consulte los Patrones recomendados sobre Replicación de Vault para obtener una descripción completa de estas opciones.

Debido a las restricciones enumeradas anteriormente, la arquitectura recomendada es con Vault y Consul Enterprise distribuidos en tres zonas de disponibilidad dentro de un clúster y para que los clústeres se repliquen en las regiones utilizando la replicación de DR y de rendimiento. También hay varias arquitecturas «Best Case», soluciones para una y dos zonas de disponibilidad y también para Consul OSS. Estas no son la arquitectura recomendada, pero son las mejores soluciones si su despliegue está restringido por la versión de Consul o el número de zonas de disponibilidad.

«Arquitectura recomendada

La arquitectura que se muestra a continuación es el mejor enfoque recomendado para el despliegue de Vault y debería ser la arquitectura objetivo para cualquier instalación. Se divide en dos partes:

• Clúster de bóvedas – Esta es la arquitectura recomendada para un clúster de bóvedas como entidad única, pero también debe utilizar la replicación según el segundo diagrama
• Replicación de bóvedas – Esta es la arquitectura recomendada para múltiples clústeres de bóvedas para permitir la recuperación regional, de rendimiento y de desastres.

«Implementación de una sola región (empresa)

En este escenario, los nodos de Vault y su clúster de Consul asociado se alojan entre tres zonas de disponibilidad. Esta solución tiene un n-2 a nivel de nodos para Vault y un n-3 a nivel de nodos para Consul. En el nivel de la zona de disponibilidad, Vault está en n-2 y Consul en n-1. Esto difiere del diseño de OSS en que el cluster Consul tiene seis nodos con tres de ellos como miembros no votantes. El clúster Consul está configurado utilizando zonas de redundancia, de modo que si algún nodo fallara, un miembro sin derecho a voto sería promovido por Autopilot para convertirse en miembro de pleno derecho y mantener así el quórum.

«Despliegue de múltiples regiones (empresa)

«Diagrama de referencia Resiliencia contra el fallo de una región

En este escenario, los clústeres están replicados para protegerse contra el fallo de una región completa. Hay tres clusters Performance Replica Vault (clusters A, B, C)cada uno con su propio cluster DR (clusters D, E, F) en una Región diferente. Cada clúster tiene su clúster Consul asociado para el backend de almacenamiento.

Esta arquitectura permite n-2 a nivel de región siempre que todos los secretos y motores de secretos se repliquen en todos los clústeres. El fallo de la Región1 completa requeriría que el clúster F de DR fuera promovido. Una vez hecho esto, la solución de bóveda sería totalmente funcional con cierta pérdida de redundancia hasta que se restableciera la Región1. Las aplicaciones no tendrían que volver a autenticarse, ya que el clúster DR de cada clúster que fallara contendría todos los contratos de arrendamiento y tokens.

«Diagrama de referencia Resiliencia contra el fallo del clúster

Esta solución tiene una resiliencia total a nivel de clúster, pero no protege contra el fallo de la región, ya que los clústeres DR para las réplicas de rendimiento están en la misma región. Hay ciertos casos de uso en los que este es el método preferido cuando los datos no pueden replicarse en otras regiones debido a restricciones de gobernanza como el GDPR. Además, algunos marcos de infraestructura pueden no tener la capacidad de enrutar el tráfico de la aplicación a diferentes regiones.

«Best Case Architecture

En algunos despliegues puede haber restricciones insuperables que significan que la arquitectura recomendada no es posible. Esto puede deberse a la falta de zonas de disponibilidad o al uso de Vault OSS. En estos casos, las siguientes arquitecturas detallan las mejores opciones disponibles.

Nótese que en estas arquitecturas siguientes el líder de Consul puede ser cualquiera de los cinco nodos de servidor de Consul y el nodo activo de Vault puede ser cualquiera de los tres nodos de Vault

«Despliegue de Vault en una zona de disponibilidad (todos)

En este escenario, todos los nodos de Vault y su cluster de Consul asociado se alojan en una zona de disponibilidad. Esta solución tiene un único punto de fallo a nivel de zona de disponibilidad, pero un n-2 a nivel de nodo tanto para Consul como para Vault. Esta no es la arquitectura recomendada por Hashicorp para los sistemas de producción, ya que no hay redundancia en el nivel de la zona de disponibilidad. Tampoco hay capacidad de DR, por lo que, como mínimo, debería tener una réplica de DR en una región separada.

«Despliegue de Vault en dos zonas de disponibilidad (OSS)

En este escenario, los nodos de Vault y su clúster asociado de Consul están alojados entre dos zonas de disponibilidad. Esta solución tiene un n-2 a nivel de nodos para Vault y Consul y un n-1 para Vault a nivel de Zona de Disponibilidad, pero la adición de una Zona de Disponibilidad no aumenta significativamente la disponibilidad del cluster Consul. Esto se debe a que el protocolo Raft requiere un quórum de (n/2)+1 y si la Zona B fallara en el diagrama anterior, el clúster no tendría quórum y también fallaría. Esta no es la arquitectura recomendada por Hashicor para los sistemas de producción, ya que sólo hay redundancia parcial en el nivel de la zona de disponibilidad y un fallo de la zona de disponibilidad mayor puede no dar lugar a una interrupción.

«Implementación de Vault en dos zonas de disponibilidad (Enterprise)

Debido a la necesidad de mantener el quórum en el clúster de Consul, tener sólo 2 zonas de disponibilidad no es ideal. No hay forma de repartir un clúster Consul entre dos zonas de disponibilidad con alguna garantía de resiliencia adicional. La mejor solución enVault Enterprise es tratar las dos AZ como regiones y tener clústeres de Vault separados en cada una.

El cluster secundario de Vault puede ser una Réplica de Rendimiento o una Réplica de DR, cada una con sus propias ventajas:

• PR secundario: Si la dirección de Vault es gestionada por Consul o por un equilibrador de cargaentonces un fallo de cualquiera de los clusters resultará en que el tráfico sea dirigido al otro cluster sin interrupción, siempre que haya lógica en su aplicación o en el agente de Vault para gestionar la re-petición de tokens que no son replicados entre los clusters.
• DR secundario: En este caso, el fallo del clúster primario dará lugar a la necesidad de la intervención del operador para promover el DR al primario, pero como todas las liberaciones y tokens se replican, no habría necesidad de ninguna lógica adicional en la aplicación para manejar esto.

«Despliegue de Vault en tres Zonas de Disponibilidad (OSS)

En este escenario, los nodos de Vault y el cluster asociado de Consul están alojados entre tres Zonas de Disponibilidad. Esta solución tiene un n-2 a nivel de nodos para Vault y Consul y un n-2 para Vault a nivel de Zona de Disponibilidad.Esto también tiene un n-1 a nivel de Zona de Disponibilidad para Consul y como tal se considera la más resistente de todas las arquitecturas para un único clúster de Vault con un backend de almacenamiento de Consul para el producto OSS.

«Replicación de Vault (sólo para empresas)

En estas arquitecturas, el clúster de Vault se ilustra como una sola entidad, y sería uno de los clústeres individuales detallados anteriormente en función de su número de zonas de disponibilidad. Los clústeres de bóveda múltiples que actúan como una única solución de bóveda y que se replican entre ellos sólo están disponibles en Enterprise Vault. OSSVault puede configurarse en varios clústeres, pero cada uno de ellos sería una solución de Vault individual y no admitiría la replicación entre clústeres.

La documentación de Vault proporciona información más detallada sobre las capacidades de replicación dentro de VaultEnterprise.

«Replicación de rendimiento

La replicación de rendimiento de Vault permite la gestión de secretos en muchos sitios.Los secretos estáticos, los métodos de autenticación y las políticas de autorización se replican para que estén activos y disponibles en varias ubicaciones; sin embargo, los secretos dinámicos y los leasestokens no lo están.

«Replicación de recuperación de desastres

La replicación de recuperación de desastres de Vault garantiza que un clúster de Vault en espera esté sincronizado con un clúster de Vault activo. Este modo de replicación incluye datos como tokens de autenticación efímera, información de tokens basada en el tiempo, así como datos de uso de tokens. Esto proporciona un objetivo de punto de recuperación agresivo en entornos en los que la prevención de la pérdida de datos operativos efímeros es la mayor preocupación. En cualquier solución empresarial, las réplicas de recuperación de desastres se consideran esenciales.

«Recuperación de desastres por corrupción o sabotaje

Otro escenario común contra el que protegerse, más frecuente en entornos de nube que proporcionan niveles muy altos de resistencia intrínseca, podría ser la corrupción intencionada o accidental de los datos y la configuración, y/o una pérdida de control de la cuenta de la nube. La Replicación de DR de Vault está diseñada para replicar datos en vivo, lo que propagaría la corrupción o eliminación de datos intencional o accidental. Para protegerse de estas posibilidades, debe hacer una copia de seguridad del backend de almacenamiento de Vault, lo que se consigue con la función ConsulSnapshot, que puede automatizarse para realizar copias de seguridad de archivo periódicas. Un sitio frío o una nueva infraestructura pueden rehacerse a partir de una instantánea de Consul.

«Notas sobre la replicación

No hay un límite establecido para el número de clusters dentro de un conjunto de replicación. Los despliegues más grandes hoy en día están en el rango de más de 30 clusters. Un clúster de Réplica de Rendimiento puede tener un clúster de Recuperación de Desastres asociado a él y también puede replicar a múltiples clústeres de Recuperación de Desastres.

Mientras que un clúster de Vault puede poseer un rol (o roles) de replicación, no hay consideraciones especiales requeridas en términos de infraestructura, y los clústeres pueden asumir (o ser promovidos o degradados) a otro rol. Circunstancias especiales relacionadas con los filtros de montaje y el uso del módulo de seguridad de hardware (HSM) pueden limitar la asignación de roles, pero éstas se basan en configuraciones específicas de la organización.

«Consideraciones relacionadas con la integración del HSM

El uso de la replicación con clusters de Vault integrados con el módulo de seguridad de hardware (HSM) o los dispositivos de desprecintado automático en la nube para operaciones de desprecintado automatizadas tiene algunos detalles que deben entenderse durante la fase de planificación.

• Si un clúster primario de rendimiento utiliza un HSM, todos los demás clústeres dentro de ese conjunto de replicación deben utilizar también un HSM.
• Si un cluster primario de rendimiento NO utiliza un HSM (utiliza el método Shamir de compartición de secretos), los clusters dentro de ese conjunto de replicación pueden ser mixtos, de tal manera que algunos pueden utilizar un HSM, otros pueden utilizar Shamir.

Este comportamiento es por diseño. Un clúster Shamir aguas abajo presenta un vector de ataque potencial en el grupo de replicación, ya que un umbral de titulares de claves podría recrear la clave maestra; por lo tanto, eludir la protección de claves HSM aguas arriba.

«Requisitos del sistema de implementación

La siguiente tabla proporciona directrices para el tamaño del servidor. Cabe destacar la firme recomendación de evitar las CPU de rendimiento no fijo, o BurstableCPU en términos de AWS, como las instancias de la serie T.

«Dimensionamiento de servidores Vault

«Dimensionamiento de los servidores Consul

«Consideraciones sobre el hardware

La categoría de tamaño pequeño sería apropiada para la mayoría de los despliegues iniciales de producción, o para entornos de desarrollo/prueba.

El tamaño grande es para entornos de producción en los que hay una carga de trabajo elevada y constante. Puede tratarse de un gran número de transacciones, un gran número de secretos o una combinación de ambos.

En general, los requisitos de procesamiento dependerán de la carga de trabajo de cifrado y de la carga de trabajo de mensajería (operaciones por segundo y tipos de operaciones). Los requisitos de memoria dependerán del tamaño total de los secretos/claves almacenados en la memoria y deberán ser dimensionados de acuerdo con esos datos (al igual que el almacenamiento del disco duro). El propio Vault tiene unos requisitos de almacenamiento mínimos, pero el backend de almacenamiento subyacente debe tener un subsistema de disco duro de relativamente alto rendimiento. Si se generan/rotan muchos secretos con frecuencia, esta información tendrá que ser vaciada en el disco a menudo y puede afectar al rendimiento si se utilizan discos duros más lentos.

La función de los servidores Consul en este despliegue es servir como backend de almacenamiento para el Vault. Esto significa que todo el contenido almacenado para la persistencia en Vault es encriptado por Vault, y escrito en el backend de almacenamiento en reposo. Estos datos se escriben en la sección del almacén de valores clave del catálogo de servicios de Consul, que debe almacenarse en su totalidad en memoria en cada servidor de Consul. Esto significa que la memoria puede ser una limitación a la hora de escalar a medida que más clientes se autentican en Vault, más secretos se almacenan de forma persistente en Vault y más secretos temporales se alquilan desde Vault. Esto también tiene el efecto de requerir un escalado vertical en la memoria del servidor de Consul si se requiere espacio adicional, ya que todo el catálogo de servicios se almacena en la memoria de cada servidor de Consul.

Además, el rendimiento de la red es una consideración común para Vault y Consulservers. Dado que ambos sistemas se basan en la API HTTPS, todas las solicitudes entrantes, las comunicaciones entre Vault y Consul, la comunicación de chismes subyacente entre los miembros del clúster de Consul, las comunicaciones con los sistemas externos (por configuración de autenticación o de motor de secreto, y algunas configuraciones de registro de auditoría) y las respuestas consumen el ancho de banda de la red.

Debido a las consideraciones de rendimiento de la red en las operaciones del clúster de Consul, la replicación de los conjuntos de datos de Vault a través de los límites de la red debe lograrse a través de la Replicación de Rendimiento o DR, en lugar de extender el clúster de Consul a través de los límites de la red y físicos. Si un único clúster de Consul se extiende a través de segmentos de red distantes o interregionales, esto puede causar problemas de sincronización dentro del clúster o cargos adicionales por transferencia de datos en algunos proveedores de la nube.

«Otras consideraciones

Recomendaciones de endurecimiento de producción de Vaultproporciona orientación sobre las mejores prácticas para una implementación endurecida de producción de Vault.

«Equilibrio de carga

«Equilibrio de carga mediante la interfaz de Consul

Consul puede proporcionar capacidades de equilibrio de carga a través del descubrimiento de servicios, pero requiere que cualquier cliente de Vault sea consciente de Consul. Esto significa que un cliente puede utilizar las interfaces DNS o API de Consul para resolver el nodo activo de Vault. Un cliente puede acceder a Vault a través de una URL como la siguiente:http://active.vault.service.consul:8200

Esto se basa en el sistema de resolución DNS del sistema operativo, y la solicitud puede ser reenviada a Consul para obtener la respuesta de la dirección IP real. La operación puede ser completamente transparente para las aplicaciones heredadas y funcionaría como una operación de resolución DNS atípica. Consulte el reenvío de DNS de Consul para obtener más información

«Equilibrio de carga utilizando un equilibrador de carga externo

Se admiten equilibradores de carga externos como punto de entrada a un clúster de Vault. El equilibrador de carga externo debe sondear el punto final de sistema/salud para detectar el nodo activo y enrutar el tráfico en consecuencia. El equilibrador de carga debe configurarse para realizar una solicitud HTTP para la siguiente URL a cada nodo del clúster a: http://<Vault Node URL>:8200/v1/sys/health

El nodo activo de Vault responderá con un 200 mientras que los nodos en espera devolverán una respuesta 4xx.

El siguiente es un bloque de configuración de ejemplo de HAProxy para ilustrar:

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

Note que el bloque anterior podría ser generado por Consul (con consul-template)cuando se utiliza un equilibrador de carga de software. Este podría ser el caso cuando el balanceador de carga es software como Nginx, HAProxy, o Apache.

Ejemplo de plantilla de consulta para el bloque HAProxy anterior:

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}}

«Manejo de la dirección IP del cliente

Hay dos métodos admitidos para manejar la dirección IP del cliente detrás de un proxy o equilibrador de carga; X-Forwarded-ForHeadersy PROXYv1.Ambos requieren un equilibrador de carga de confianza y una dirección IP para ser listada como direcciones permitidas para adherirse a las mejores prácticas de seguridad.

«Referencias adicionales

• La documentación de la arquitectura de Vault explica cada componente de Vault
• Para integrar Vault con un servidor LDAP existente, consulte la documentación del método de autenticación de LDAP
• Recurra al tutorial AppRole PullAuthentication para generar mediante programación un token para una máquina o aplicación
• Consul es una parte integral de la ejecución de un clúster resistente de Vault, independientemente de su ubicación. Consulte la documentación en línea de Consul para obtener más información.

«Próximos pasos

• Lea Production Hardening para conocer las mejores prácticas para una implementación de producción de Vault.
• Lea Deployment Guide para conocer los pasos necesarios para instalar y configurar un único cluster de HashiCorp Vault.