Host de alta disponibilidade Bastion - Práticas recomendadas, ELB, EIP?

Question

Atualmente, estou tentando descobrir uma boa configuração para tornar um host Bastion altamente disponível. Eu quero atingir os seguintes objetivos:

1. O (s) host (s) de bastião precisam suportar uma falha na zona de disponibilidade e uma falha na instância ec2. Um pequeno tempo de inatividade (alguns minutos) pode ser aceitável.
2. O (s) host (s) de bastião precisam ser acessados por meio de uma entrada de DNS permanente.
3. Nenhuma intervenção manual necessária

Minha configuração atual é a seguinte: Bastion host no Auto Scaling Group em duas zonas de disponibilidade, ELB na frente do Auto Scaling Group.

Esta configuração tem algumas vantagens:

• Fácil de configurar usando o CloudFormation
• Grupos de escalonamento automático em dois AZs podem ser usados para garantir a disponibilidade
• O não conta para o limite de EIP das contas

Também tem algumas desvantagens:

• Com dois ou mais hosts de bastiões atrás do ELB, os avisos de chave de host SSH são comuns e não quero que nossos usuários se acostumem a ignorar os avisos de SSH.
• O ELB custa dinheiro, ao contrário do EIP. Tanto quanto o host bastião, na verdade. Isso não é realmente uma grande preocupação, eu adicionei este ponto apenas por uma questão de completude.

A outra solução óbvia é usar um ElasticIP, que tem - como eu vejo - algumas desvantagens:

• Eu posso (obviamente) não anexar um EIP a um Grupo de Auto Scaling diretamente
• Quando não estiver usando grupos do Auto Scaling, preciso colocar algo em funcionamento que inicie novos hosts de bastiões do EC2 se os antigos falharem, por exemplo, usando o AWS Lambda. Isso adiciona complexidade adicional.
• Quando o EIP é anexado a um grupo do Auto Scaling manualmente, na falha da zona de disponibilidade, o EIP será desatacado e não será reconectado a uma nova instância. Novamente, isso pode ser resolvido executando um programa (na instância ou no AWS Lambda) que reconecta o EIP a uma instância. Novamente, isso adiciona complexidade adicional.

Quais são as práticas recomendadas para instâncias SSH de alta disponibilidade, ou seja, hosts de bastiões?

    

Answer 1

Parece que o requisito é fornecer funcionalidade bastion a um custo razoável mais baixo com um RTO de, digamos, 5 minutos. Nenhum RPO é aplicável, pois é efetivamente um proxy sem estado que pode ser facilmente reconstruído.

Eu teria um host bastion, definido como um script AMI ou CloudFormation (AMI é mais rápido), dentro de um grupo de escalonamento automático com min / max / target definido como 1. Eu não teria um balanceador de carga porque não há preciso disso até onde eu possa ver. Essa instância seria registrada no Route53 com um nome de domínio público, portanto, mesmo que a instância seja alterada, você poderá acessá-la e isso deverá eliminar os avisos de SSH. Eu poderia começar com uma instância em cada sub-rede, mas provavelmente desligaria uma delas se elas fossem confiáveis o suficiente - elas deveriam ser.

Uma implantação do CloudFormation de hosts bastion é descrita pela Amazon aqui . A Amazon tem um guia de práticas recomendadas aqui . Você não deve abordar recursos internos usando o Elastic IP, pois eles são IPs públicos e o tráfego para eles é cobrado , enquanto o tráfego IP privado não é cobrado. Nomes de domínio são mais baratos. Isso pode envolver alguns ajustes de script do CloudFormation.