Existe um balanceador de carga de software de HA do Linux que atende HTTPS para vários nomes de domínio não relacionados, mas se equilibra em um único cluster de servidor da web?

Question

Eu tenho um aplicativo SaaS multi-inquilino baseado em nuvem (Amazon AWS, Rackspace, qualquer que seja) e preciso oferecer suporte a comunicações HTTPS para vários domínios de inquilino não relacionados.

Como exemplo ilustrativo, digamos que nosso SaaS esteja disponível em:

https://foo.com

Os locatários podem acessar seus pontos de extremidade da interface e do serviço específicos do inquilino por meio de:

https://tenantA.foo.com
https://tenantB.foo.com
...

Isso é fácil de suportar hoje com um certificado SSL curinga.

No entanto, com nosso SaaS, nossos locatários podem querer expor nossa interface do usuário (mas marcada para eles) diretamente a seus próprios usuários.

Isso causa um problema: digamos que John Smith seja um cliente existente de tenantA (e não tenha conhecimento de foo.com ). Se John Smith é direcionado para https://tenantA.foo.com , eles poderiam facilmente ficar confusos (por exemplo, 'quem é o foo.com? Por que estou aqui? Estou sendo hackeado? Aahhh!').

Para evitar esse problema, nossos locatários configurariam um subdomínio como:

https://foo.tenantA.com

Isso evita muita confusão do usuário final: os usuários de tenantA podem ver um URL que eles reconhecem como pertencente a tenantA e usarão o aplicativo mais prontamente. Mas tenantA quer que hospedemos tudo sobre o aplicativo, o que significa que a infraestrutura de foo.com precisa atender à conexão SSL.

Para esse fim, queremos apoiar o seguinte:

1. Um inquilino envia para nós um certificado SSL + chave para foo.tenantA.com .
2. Usamos esse certificado SSL e o instalamos dinamicamente em um cluster de Balanceamento de Carga altamente disponível (2 ou mais nós LB) que carregam solicitações de balanceamento para os nós de extremidade da Web do nosso aplicativo SaaS.
3. O locatário atualiza seu DNS para que foo.tenantA.com seja um redirecionamento CNAME para tenantA.foo.com .

Dessa forma, nosso pool do Load Balancer servirá / encerrará todas as comunicações HTTPS com foo.tenantA.com e todas as solicitações serão carregadas com balanceamento para o nosso cluster de servidor da web SaaS.

Isso significa que os certificados SSL devem poder ser adicionados e removidos do conjunto de LB em tempo de execução . As alterações não podem interromper a capacidade de atender a solicitações HTTPS existentes ou novas.

Além disso, como implantaremos em hardware virtualizado (por exemplo, EC2) com o Linux, não temos acesso ao hardware / data center. Esta deve ser uma solução baseada em software que pode ser executada no Linux. Também deve estar altamente disponível (2 ou mais nós de LB).

Alguém sabe de uma solução concreta? Por exemplo, Nginx, HAProxy ou Squid (ou qualquer outra coisa) podem ser configurados para suportar isso? Existe uma 'receita' ou solução existente documentada e adequada?

P.S. O Elastic Load Balancer da Amazon (no momento em que este artigo foi escrito) não pode satisfazer pragmaticamente essa necessidade - seria necessário um ELB da Amazon para cada domínio do locatário. Como todos os ELB precisam 'pingar' os servidores da Web, se você tivesse 500 inquilinos, teria 500 ELBs fazendo ping nos pontos de extremidade do serviço da Web SaaS - um impacto negativo insignificante no desempenho.

    

Answer 1

Atualização 2017-09-13: O SNI tornou-se predominante o suficiente nos navegadores principais para que possa ser usado para atender à solicitação, e essa resposta deve ser considerada desatualizada.

A única maneira de suportar isso é ter um IP para cada um de seus clientes. Quando você se conecta via https, a conexão é criptografada imediatamente , não há chance de o navegador dizer "Estou aqui para foo.tenantA.com". Portanto, a única maneira de o servidor saber qual certificado SSL deve ser usado para criptografar a conexão é baseada no IP em que a conexão entrou.

Agora isso ainda é possível, mas significa que você vai precisar de muitos IPs. Nós realmente fazemos essa configuração exata no meu trabalho. Temos 2 balanceadores de carga ativos / ativos, com metade dos IPs em um balanceador, a outra metade no outro balanceador (um total de cerca de 500 IPs). Então nós temos vários servidores web no back-end que levam todas as conexões. Qualquer servidor da web pode falhar e o balanceador de carga parará de enviar conexões. Ou o próprio balanceador de carga pode falhar e o outro usará todos os seus IPs.
O software de balanceamento de carga que faz isso é Pacemaker e ldirectord (ambos são projetos mainstream e qualquer distro que você execute deve tê-los em seu repositório). O próprio kernel do Linux é o que realmente faz o balanceamento de carga, o software é apenas responsável por lidar com failovers.

Observação: para balanceamento de carga, existem muitas alternativas para o directd, como keepalived e surealived . Embora para o software de failover do balanceador de carga real, o marcapasso é o que você deve usar.

Guias básicos:

• Este fornecerá instruções básicas para obter o pacemaker configurado. Você pode ignorar todas as coisas anteriores, pois a CMAN é a sua substituta. A única coisa que você precisa fazer para chegar até esse ponto no guia é instalar o marcapasso e suas dependências. Pare na seção 8.2.4. Você não precisa ir para a seção 8.3, pois isso não é relevante para o que você está fazendo.

• Quando o marcapasso estiver funcionando, isso fornecerá uma configuração bem básica para balancear a carga de um servidor http.

• Você também pode consultar este e este . É mais uma visão geral de alto nível do marcapasso, o que ele faz e como usá-lo.

Answer 2

O que dizer de apenas recomendar que seu cliente coloque um wrap fino nele? Algo parecido com isto:

1. O usuário final envia uma solicitação para https://api.tenantA.com
2. api.tenantA.com apenas encaminha a solicitação para https://tenanta.foo.com
3. A resposta é então filtrada da mesma forma.

Eu estou supondo que, desde que este seja mais um caso extremo, ele deve funcionar bem.