Free Press

O objetivo deste documento é recomendar as práticas de implantação do HashiCorp Vault. Esta arquitetura de referência transmite uma arquitetura geral que deve ser adaptada para acomodar as necessidades específicas de cada implementação.

Os seguintes tópicos são abordados neste guia:

• Resumo do Design
  • Conectividade da Rede
  • Failure Tolerance
• Arquitectura Recomendada
  • Desenvolvimento de Região Única (Enterprise)
  • Multipla Região Implantação (Empresa)
• Arquitetura do Melhor Caso
  • Implantação de Cofre em uma Zona de Disponibilidade (todos)
  • Implantação de Cofre em duas Zonas de Disponibilidade (OSS)
  • Implantação de Cofre em duas Zonas de Disponibilidade (Enterprise)
  • Emprego de Cofre em três Zonas de Disponibilidade (OSS)
• Replicação de Cofre (Enterprise Only)
• Requisitos do Sistema de Implantação
  • Hardware Considerações
• Balanceamento de carga
• Referências adicionais

“Glossário

“Vault Cluster

Um Vault cluster é um conjunto de processos de Vault que juntos executam um serviço de Vault.Estes processos Vault podem ser executados em servidores físicos ou virtuais, ou incontainers.

“Consul storage backend cluster

HashiCorp recomenda e suporta que o Consul seja usado como o backend de armazenamento para o Vault. Um cluster Consul é um conjunto de processos de servidores Consul que juntos executam um serviçoConsul. Estes processos Consul podem ser executados em servidores físicos ou virtualservers, ou em containers.

“Availability Zone

A single failure domain on a location level that hosts part of, or all of aVault cluster. A latência entre as zonas de disponibilidade deve ser < 8ms para cerca de viagem. Um único Vault cluster pode estar espalhado por múltiplos disponíveis.

Exemplos de uma zona de disponibilidade neste contexto são:

• Um datacenter isolado
• Uma gaiola isolada num datacenter se estiver isolada de outras gaiolas por outros meios (energia, rede, etc)
• Uma zona de disponibilidade em AWS, Azure ou GCP

“Região

Uma recolha geograficamente separada de uma ou mais zonas de disponibilidade. Uma região hospedaria um ou mais clusters de Vault. Não existe uma latência máxima definida entre regiões na arquitetura Vault. Um único cluster Vault não seria distribuído por múltiplas regiões.

“Design Summary

Este design é a arquitetura recomendada para ambientes de produção, pois fornece flexibilidade e resiliência.

É uma recomendação importante da arquitetura que os servidores Consul são separados dos servidores Vault e que o cluster Consul é usado apenas como um storageebackend para Vault e não para outras funcionalidades focadas no Consul (por exemplo, implementação de serviços e descoberta de serviços), o que pode introduzir uma utilização imprevisível dos recursos. A separação entre o Vault e o Consul permite que cada um tenha um sistema que pode ser dimensionado apropriadamente em termos de CPU, memória e disco. O Consul é uma aplicação que requer muita memória e, portanto, separá-la de seus próprios recursos é vantajoso para evitar a contenção de recursos ou a fome. Dedicar um cluster Consul como um backend de armazenamento Vault também é vantajoso, pois permite que o cluster Consul seja atualizado apenas quando necessário para melhorar a funcionalidade do backend de armazenamento Vault. Isto provavelmente será muito menos frequente do que um cluster Consul que também é usado para descoberta de serviços e segmentação de serviços.

Conectividade Vault to Consul backend é sobre HTTP e deve ser protegida com TLS, assim como um token Consul para fornecer criptografia de todo o tráfego. Consulte o VaultDeployment Guide para obter mais informações. O cluster Asthe Consul para armazenamento Vault pode ser usado em adição e separado de um clusterConsul para descoberta de serviços, é recomendado que o processo Consul de armazenamento seja executado em portas sem defeito para que não entre em conflito com outras funcionalidadesConsul. A configuração do cluster de armazenamento do Consul para execução em 7xxxportes e a utilização desta como porta de armazenamento na configuração do Vault irá atingir este objetivo. Também é recomendado que o Consul seja executado usando TLS.

“Network Connectivity Details

A tabela a seguir descreve os requisitos de tráfego de rede para os clusternodes do Vault.

“Configurações alternativas de rede

Vault pode ser configurado de várias formas separadas para as comunicações entre oVault e os Clusters do Consul:

• Utilizar endereços IP do host ou nomes de hosts que podem ser resolvidos via sistema de nomes padrão
• Utilizar endereços IP do balanceador de carga ou nomes de hosts que podem ser resolvidos via subsistema chamado viastandard
• Utilizar o cluster do cônsul anexado DNS como descoberta de serviço para resolver Vaultendpoints
• Usando um cluster separado de descoberta de serviço do Consul DNS como descoberta de serviço para resolver Vault endpoints

Todas essas opções são exploradas mais no Guia de implantação de Vault.

“Tolerância a falhas

O Vault foi projetado para lidar com diferentes cenários de falha que têm diferentes probabilidades. Ao implantar um cluster de Vault, a tolerância a falhas que você exige deve ser considerada e projetada para isso. No OSS Vault o número recomendado de instâncias é 3 em um cluster, já que qualquer outra teria valor limitado. No InVault Enterprise o número recomendado também é 3 em um cluster, mas mais podem ser usadas se elas forem mais eficientes e mais podem ser usadas para ajudar com a carga de trabalho somente leitura. O cluster do Consul é de uma a sete instâncias. Este deve ser um número ímpar para permitir que eleições de liderança sejam sempre resolvidas. É recomendado que o cluster Consul seja pelo menos cinco instâncias que são dedicadas a executar funções de armazenamento backend para o cluster Vault somente.

“Node

O software Vault e Consul cluster permite um domínio de falha no nível do nó por ter replicação dentro do cluster. Em um único HA Vault cluster todos os nós compartilham o mesmo backend de armazenamento subjacente e, portanto, os dados. Vaultachieves isto por um dos servidores Vault obtendo um bloqueio dentro do armazenamento de dados para se tornar o nó Vault ativo e isto tem acesso de escrita. Se a qualquer momento o líder for perdido, então outro nó Vault tomará seu lugar como líder. Para alcançar a redundância n-2 (onde a perda de 2 objetos dentro do domínio falha pode ser tolerada), um tamanho ideal para um cluster de Vault seria 3.Consul consegue replicação e liderança através do uso de seus protocolos de consenso egossip. Nestes protocolos, um líder é eleito por consenso e por isso deve existir sempre um aquorum de servidores ativos. Para alcançar a redundância n-2, o tamanho ideal de um cluster Consul é 5. Veja ConsulInternals para mais detalhes.

“Availability Zone

Typical distribution in a cloud environment is to spread Consul/Vault nodes intoseparate Availability Zones (AZs) within a high bandwidth, low latency network,such as an AWS Region, however this may not be possible in a datacenterinstallation where there is only one DC within the level of latency required.

É importante compreender uma mudança nos requisitos ou nas melhores práticas que se verificaram como resultado da mudança para uma maior utilização de sistemas altamente distribuídos, como o Consul. Quando ambientes operacionais compostos por sistemas distribuídos, é necessária uma mudança no coeficiente de redundância dos componentes de financiamento. A Consul conta com a negociação consensual para organizar e replicar informações e, portanto, o ambiente deve fornecer 3 caminhos resilientes únicos, a fim de proporcionar confiabilidade significativa. Essencialmente, um sistema de consenso requer uma maioria simples de nós para estar disponível a qualquer momento. No exemplo de 3 nós, você deve ter 2 disponíveis. Se esses 3 nós forem colocados em dois domínios de falha, há 50% de chance de que a perda de um único domínio de falha resulte em uma interrupção completa.

“Região

Para proteger contra uma falha no nível da região, bem como fornecer recursos adicionais de escala geográfica, a Vault Enterprise oferece:

• Replicação de Recuperação de Desastre
• Replicação de Desempenho

Por favor, veja os Padrões Recomendados na Replicação do Vault para uma descrição completa dessas opções.

Por causa das restrições listadas acima, a arquitetura recomendada é comVault e Consul Enterprise distribuídas por três zonas de disponibilidade dentro do acluster e para que os clusters sejam replicados entre regiões usando replicação DR ePerformance. Existem também várias arquiteturas “Best Case” para uma e duas Zonas de Disponibilidade e também para o Consul OSS. Estas não são a arquitetura recomendada, mas são as melhores soluções se a sua implantação for restrita pela versão Consul ou pelo número de zonas de disponibilidade.

“Arquitetura Recomendada

A arquitetura abaixo é a melhor abordagem recomendada para a implantação de Vault e deve ser a arquitetura alvo para qualquer instalação. Isto é dividido em duas partes:

• Cluster vault – Esta é a arquitetura recomendada para um cluster vault como entidade única, mas também deve usar replicação conforme o segundo diagrama
• Replicação vault – Esta é a arquitetura recomendada para múltiplos vaultclusters para permitir a recuperação regional, de desempenho e de desastres.

“Single Region Deployment (Enterprise)

Neste cenário, os nós do Vault e o cluster do Consul associado são hospedados entre três Zonas de Disponibilidade. Esta solução tem um n-2 no nível de nó para o Vault e um n-3 no nível de nó para o Consul. No nível da Zona de Disponibilidade, o Vault está no nível n-2 e o Consul no nível n-1. Isto difere do design do OSS, pois o cluster de Consul tem seis nós com três deles como não-votingmembradores. O clusterConsul é configurado usando RedundancyZones de modo que se algum membro não votante falhar seria promovido pelo piloto automático para se tornar um membro pleno e assim manter o quorum.

“Multiple Region Deployment (Enterprise)

“Reference Diagram Resilience against Region Failure

Neste cenário, os clusters são replicados para se protegerem contra uma falha total da região. Há três clusters de Caixas Réplica de Desempenho (clusters A, B, C)cada um com seu próprio cluster DR (clusters D, E, F) em uma Região diferente. Cada cluster tem seu associado Consul cluster para backend de armazenamento.

Esta arquitetura permite n-2 ao nível da região, desde que todos os segredos e mecanismos de segurança sejam replicados em todos os clusters. A falha de toda a Região1 exigiria a promoção do cluster F de DR. Uma vez feito isso, o Vaultsolution estaria totalmente funcional com alguma perda de redundância até que a Região1 fosse restaurada. As aplicações não teriam que re-autenticar como o DRcluster para cada cluster com falha conteria todas as locações e fichas.

“Reference Diagram Resilience against Cluster Failure

Esta solução tem total resiliência em nível de cluster, mas não protege contra falhas na região, já que os clusters DR para as réplicas de Performance estão na mesma região. Existem certos casos de uso – onde este é o método preferido – em que os dados não podem ser replicados para outras regiões devido a restrições de governança, como o GDPR. Também algumas estruturas de infraestrutura podem não ter a capacidade de rotear o tráfego de aplicação para diferentes regiões.

“Best Case Architecture

Em algumas implementações pode haver restrições intransponíveis que significam que a arquitetura recomendada não é possível. Isto pode ser devido à falta de zonas de disponibilidade ou por causa da utilização do Vault OSS. Nesses casos, as arquiteturas abaixo detalham as melhores opções de casos disponíveis.

Note que nestas arquiteturas seguintes o líder do Consul poderia ser qualquer um dos cinco nós do servidor do Consul e o nó ativo do Vault poderia ser qualquer um dos três nós do Vault

“Deployment of Vault in one Availability Zone (all)

Neste cenário, todos os nós do Vault e o cluster do Consul associado são hospedados dentro de uma Availability Zone. Esta solução tem um único ponto de falha no nível da zona de disponibilidade, mas um n-2 no nível do nó tanto para o Consul como para o Vault. Esta arquitetura não é recomendada pela Hashicorp para sistemas de produção, pois não há redundância no nível da Zona de Disponibilidade. Também não há DRcapability e por isso, no mínimo, isto deve ter uma réplica de DR em uma região separada.

“Deployment of Vault in two Availability Zones (OSS)

Neste cenário, os nós do Vault e o cluster do Consul associado são hospedados entre duas Zonas de Disponibilidade. Esta solução tem um n-2 no nível de nó para Cofre e Cônsul e n-1 para Cofre no nível de Zona de Disponibilidade, mas a adição de uma Zona de Disponibilidade não aumenta significativamente a disponibilidade do cluster de Cônsul. Isto porque o protocolo da jangada requer aquorum de (n/2)+1 e se a Zona B falhar no diagrama acima, ocluster não será quorato e, portanto, também falhará. Isto não é arquitetura Hashicorrecomendada para sistemas de produção, pois há apenas uma redundância parcial no nível da Zona de Disponibilidade e uma falha na Zona de Disponibilidade pode não resultar em uma interrupção.

“Deployment of Vault in two Availability Zones (Enterprise)

Devido à necessidade de manter o quorum no cluster do Consul, ter apenas 2Availability Zones não é o ideal. Não há como espalhar um agrupamento de cônsules entre duas AZs com qualquer garantia de resiliência adicional. A melhor solução de caso no Vault Enterprise é tratar os dois AZs como regiões e ter Vaultclusters separados em cada uma.

O cluster Vault secundário pode ser uma réplica de desempenho ou uma réplica DR, cada uma tendo suas próprias vantagens:

• PR secundário: Se o endereço Vault é gerenciado pelo Consul ou por um balanceamento de carga, uma falha de qualquer um dos clusters resultará no tráfego sendo direcionado para o outro cluster sem nenhuma interrupção, desde que haja lógica em sua aplicação ou o agente Vault para gerenciar tokens de re-requisição que não são replicados entre os clusters.
• DR secundário: Neste caso a falha do cluster primário resultará na necessidade de intervenção do operador para promover o DR para o primário, mas como allleases e tokens são replicados, não haveria necessidade de nenhum addallogic na aplicação para lidar com isso.

“Implantação do Vault em três Zonas de Disponibilidade (OSS)

Neste cenário, os nós do Vault e o cluster do Consul associado são hospedados entre três Zonas de Disponibilidade. Esta solução tem um n-2 no nível de nó para Cofre e Consul e um n-2 para Cofre no nível de Zona de Disponibilidade. Esta solução também tem um n-1 no nível de Zona de Disponibilidade para Consul e como tal é considerada a mais resiliente de todas as arquiteturas para um único cluster de Cofre com um backend de armazenamento Consul para o produto OSS.

“Vault Replication (Enterprise Only)

Nestas arquiteturas o Vault Cluster é ilustrado como uma única entidade, e seria um dos clusters detalhados acima com base no número de Zonas de Disponibilidade. Múltiplos clusters de Vault atuando como um único Vaultsolution e replicando entre eles está disponível apenas no Enterprise Vault. OSSVault pode ser configurado em vários clusters, mas cada um deles seria uma soluçãoVault individual e não suportaria replicação entre clusters.

O Vaultdocumentation fornece informações mais detalhadas sobre os recursos de replicação dentro do VaultEnterprise.

“Performance Replication

Replicação de performance do Vault permite o gerenciamento de segredos em muitos sites.Segredos estáticos, métodos de autenticação e políticas de autorização foram replicados para estarem ativos e disponíveis em vários locais, porém leasestokens e segredos dinâmicos não são.

“Disaster Recovery Replication

Vault disaster recovery replication assegura que um cluster Vault em standby seja keptsynchronized com um cluster Vault ativo. Este modo de replicação inclui dados como tokens de autenticação efêmera, informações de token baseadas em tempo e dados de uso de tokens. Isso proporciona um ponto de recuperação agressivo em ambientes onde a prevenção da perda de dados operacionais efêmeros é a principal preocupação. Em qualquer solução empresarial, as réplicas de recuperação de desastres são consideradas essenciais.

“Corruption or Sabotage Disaster Recovery

Outro cenário comum para proteção contra, mais prevalente em ambientes de nuvem que fornecem níveis muito altos de resiliência intrínseca, pode ser a corrupção intencional ou acidental de dados e configuração, e/ou uma perda do controle da conta na nuvem. A replicação DR do Vault é projetada para replicar dados ao vivo, o que propagaria a corrupção ou exclusão intencional ou acidental de dados. Toprotect contra essas possibilidades, você deve fazer backup do backend de armazenamento do Vault. Isso é suportado através do recurso ConsulSnapshot, que pode ser automatizado para backups de arquivos regulares. Um site frio ou uma nova infraestrutura pode ser re-hidratada a partir de um snapshot do Consul.

“Replication Notes

Não há limite definido para o número de clusters dentro de um conjunto de replicação. As maiores implementações hoje estão na faixa de mais de 30 clusters. Um cluster de Replicação de Desempenho pode ter um cluster de Recuperação de Desastre associado a ele e também pode replicar para vários clusters de Recuperação de Desastre.

Embora um cluster Vault possa possuir uma função de replicação (ou funções), há considerações especiais necessárias em termos de infraestrutura, e os clusters podem assumir (ou ser promovidos ou rebaixados) para outra função. Circunstâncias especiais relacionadas ao uso de filtros de montagem e do Módulo de Segurança de Hardware (HSM) podem limitar a troca de funções, mas estas são baseadas em configurações específicas da organização.

“Considerações Relacionadas à Integração do HSM

Usar replicação com clusters Vault integrados ao Módulo de Segurança de Hardware (HSM) ou dispositivos de auto-inserção em nuvem para operações automatizadas de desinserção tem alguns detalhes que devem ser entendidos durante a fase de planejamento.

• Se um cluster primário de desempenho usa um HSM, todos os outros clusters dentro desse conjunto de replicação devem usar um HSM também.
• Se um cluster primário de desempenho NÃO usa um HSM (usa o método Shamir secretsharing), os clusters dentro desse conjunto de replicação podem ser misturados, de forma que alguns podem usar um HSM, outros podem usar Shamir.

Este comportamento é por projeto. Um cluster Shamir a jusante apresenta um vector de ataque potencial no grupo de replicação, uma vez que um limiar de porta-chaves poderia criar a chave-mestra; portanto, contornando a protecção da chave HSM a montante.

“Deployment System Requirements

A tabela a seguir fornece diretrizes para o dimensionamento do servidor. É de salientar a forte recomendação para evitar CPUs de desempenho não fixas, ou BurstableCPU em termos de AWS, tais como instâncias da série T.

“Sizing for Vault Servers

“Dimensionamento para Servidores Cônsules

“Hardware Considerations

A categoria de tamanho pequeno seria apropriada para a maioria das implantações iniciais de produção, ou para ambientes de desenvolvimento/teste.

A categoria de tamanho grande é para ambientes de produção onde há uma carga de trabalho elevada consistente. Isso pode ser um grande número de transações, um grande número de repetições, ou uma combinação dos dois.

Em geral, os requisitos de processamento dependerão da carga de trabalho de criptografia e da carga de trabalho de mensagens (operações por segundo, e tipos de operações). Os requisitos de memória dependerão do tamanho total dos segredos/chaves armazenados na memória e devem ser dimensionados de acordo com esses dados (assim como o drivestorage duro). Se muitos segredos estiverem sendo gerados/rotacionados com freqüência, essas informações precisarão ser descarregadas para o disco com freqüência e podem impactar o desempenho se discos rígidos mais lentos forem utilizados.

A função de servidores de consulta nesta implantação é servir como o backendfor de armazenamento do Vault. Isto significa que todo o conteúdo armazenado para persistência no Vault é criptografado pelo Vault, e escrito no backend de armazenamento em repouso. Estes dados são gravados na seção de armazenamento de valores-chave do Catálogo de Serviços do Consul, que deve ser armazenado em sua memória completa em cada servidor do Consul. Isto significa que a memória pode ser uma restrição no escalonamento à medida que mais clientes se autenticam no Vault, mais segredos são persistentemente armazenados no Vault, e mais segredos temporários são alugados do Vault. Isso também tem o efeito de requerer escalonamento vertical na memória do servidor do Consul se espaço adicional for necessário, pois todo o ServiceCatalog é armazenado em memória em cada servidor do Consul.

Outras vezes, a taxa de transferência de rede é uma consideração comum para o Vault e para os Consulservers. Como ambos os sistemas são HTTPS API, todas as solicitações de entrada, comunicações entre Vault e Consul, comunicação fofoca subjacente entre os membros do cluster Consul, comunicações com sistemas externos (por configuração auth ou secretengine, e algumas configurações de registro de auditoria) e responsesconsumem a largura de banda da rede.

Devem ser feitas considerações sobre o desempenho da rede em operações de cluster Consul, replicação de conjuntos de dados Vault através dos limites da rede deve ser obtida através de Desempenho ou Replicação DR, em vez de espalhar a rede do cluster Consul para além dos limites físicos e da rede. Se um único cluster Consul for disseminado por segmentos de rede distantes ou inter-regionais, isso pode causar problemas de sincronização dentro do cluster ou taxas adicionais de transferência de dados em alguns provedores de nuvem.

“Outras Considerações

Recomendação de Endurecimento da Produção de Vault fornece orientações sobre as melhores práticas para uma implantação endurecida da produção de Vault.

“Load Balancing

“Load Balancing Using Consul Interface

Consul pode fornecer recursos de balanceamento de carga através da descoberta de serviços, mas isso exige que qualquer cliente Vault esteja ciente do Consul. Isso significa que um cliente pode usar as interfaces DNS ou API do Consul para resolver o nó ativo do Vault. O cliente pode acessar o Vault através de uma URL como a seguinte:http://active.vault.service.consul:8200

Isso depende do sistema operacional de resolução DNS e o requestc pode ser encaminhado ao Consul para a resposta real do endereço IP. A operação pode ser completamente transparente para aplicações legadas e operaria da mesma forma que uma operação de resolução DNS atípica. Veja Consul DNSforwarding para mais informações

“Load Balancing Using External Load Balancer

External load balancers are supported as an entry point to a Vault cluster. O balanceador de carga externo deve pesquisar estes pontos finais/saúde para detectar o nó ativo e o tráfego de rota de acordo. O balanceador de carga deve ser configurado para fazer um pedido HTTP para a URL a seguir para cada nó do cluster: http://<Vault Node URL>:8200/v1/sys/health

O nó ativo do Vault responderá com 200 enquanto os nós de espera retornarão uma resposta de 4xx.

O seguinte é um exemplo de bloco de configuração do 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 o bloco acima poderia ser gerado pelo Consul (com modelo cônsul) quando um balanceador de carga de software for usado. Este poderia ser o caso quando o balanceador de carga é um software como Nginx, HAProxy, ou Apache.

Exemplo Consul Template para o bloco HAProxy acima:

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

“Client IP Address Handling

Existem dois métodos suportados para lidar com o endereço IP do cliente por trás de um balanceador de carga do proxy; X-Forwarded-ForHeaders e PROXYv1.Ambos requerem um balanceador de carga confiável e um endereço IP a ser listado como endereços permitidos para aderir às melhores práticas de segurança.

“Referências Adicionais

• A documentação da arquitetura Vault explica cada componente Vault
• Para integrar o Vault com o servidor LDAP existente, consulte a documentação do Método Auth doLDAP
• Refer ao tutorial AppRole PullAuthentication para programar um token para uma máquina ou app
• Consul é parte integrante da execução de um cluster Vault resistente, independentemente da localização. Consulte a Consuldocumentação online para aprender mais.

“Próximos passos

• Ler Endurecimento da Produção para aprender as melhores práticas para uma implantação do Endurecimento da Produção do Vault.
• Ler Guia de implantação para aprender os passos necessários para instalar e configurar um único cluster HashiCorp Vault.