Gerenciando o cluster de computadores Linux por trás de firewalls

18

O produto da minha empresa é essencialmente uma caixa Linux (Ubuntu) localizada na rede de outra pessoa que está executando o nosso software. Até agora, tínhamos menos de 25 caixas em estado selvagem e usamos o TeamViewer para gerenciá-las.

Estamos prestes a enviar 1000 dessas caixas e o TeamViewer não é mais uma opção. Meu trabalho é descobrir uma maneira de acessar essas caixas e atualizar o software nelas . Esta solução deve ser capaz de perfurar firewalls e o que você tem.

Eu considerei:

1. Solução desenvolvida internamente (por exemplo, um serviço Linux) que estabelece um túnel reverso de SSH para um servidor na nuvem e outro serviço na nuvem que rastreia esses & permite que você se conecte a eles.

Isso é obviamente trabalhoso e, francamente falando, parece reinventar a roda, já que muitas outras empresas já devem ter se deparado com esse problema. Mesmo assim, não tenho certeza se faremos um ótimo trabalho.

2. Ferramentas como fantoche, chef ou OpenVPN

Eu tentei ler o máximo possível, mas parece que não consigo penetrar o suficiente através do marketing fale para entender a escolha óbvia a seguir.

Ninguém mais, exceto nós, precisa se conectar a essas caixas. Existe alguém com experiência relevante que possa me dar algumas dicas?

    
por hakura 31.07.2016 / 18:13

3 respostas

23

Puxe atualizações, não pressione

À medida que você dimensiona, torna-se inviável fazer as atualizações push para todos os seus produtos.

  • Você terá que acompanhar todos os clientes individuais, que podem ter uma configuração de firewall diferente.
  • Você terá que criar conexões recebidas por meio do firewall do cliente, o que exigiria encaminhamento de porta ou algum outro mecanismo semelhante. Este é um risco de segurança para seus clientes

Em vez disso, faça com que seus produtos "acessem" suas atualizações periodicamente e, em seguida, você pode adicionar capacidade extra ao servidor à medida que cresce.

Como?

Este problema já foi resolvido, como você sugeriu. Aqui estão várias abordagens em que posso pensar.

  • usando apt : Use o sistema apt integrado com um PPA personalizado e uma lista de fontes. Como faço para configurar um PPA?
    • Con: A menos que você use um serviço de hospedagem pública como o launchpad, a configuração do seu próprio sistema de empacotamento do apt PPA + não é para os fracos de coração.
  • usando ssh : gere uma chave pública SSH para cada produto e adicione a chave desse dispositivo aos servidores de atualização. Então, basta ter o seu software rsync / scp dos arquivos necessários.
    • Con: É preciso rastrear (e fazer backup!) todas as chaves públicas de cada produto enviado por você.
    • Pro : mais seguro que um download bruto, pois os únicos dispositivos que podem acessar as atualizações seriam aqueles com a chave pública instalada.
  • download bruto + verificação de assinatura :

    • Postar um arquivo de atualização assinado em algum lugar (Amazon S3, servidor FTP, etc.)
    • Seu produto verifica periodicamente se o arquivo de atualização é alterado e depois faz o download / verifica a assinatura.
    • Con : Dependendo de como você implanta isso, os arquivos podem ser publicamente acessíveis (o que pode tornar seu produto mais fácil de fazer engenharia reversa e hackear)
  • ansible : O Ansible é uma ótima ferramenta para gerenciar configurações do sistema. É no reino do fantoche / chef, mas é sem agente (usa python) e projetado para ser idempotente. Se a implantação de seu software exigir um script bash complicado, usaria uma ferramenta como essa para tornar menos complicado a execução de suas atualizações.

Claro, existem outras maneiras de fazer isso ... Mas isso me leva a um ponto importante.

Assine / valide suas atualizações!

Não importa o que você faça, é imperativo que você tenha um mecanismo para garantir que sua atualização não tenha sido adulterada. Um usuário mal-intencionado pode representar seu servidor de atualização em qualquer uma das configurações acima. Se você não validar sua atualização, sua caixa será muito mais fácil de invadir e entrar.

Uma boa maneira de fazer isso é assinar seus arquivos de atualização. Você terá que manter um certificado (ou pagar alguém para fazer isso), mas poderá instalar sua impressão digital em cada um de seus dispositivos antes de enviá-los para que eles possam rejeitar as atualizações que foram adulteradas.

Segurança física

É claro que, se alguém tiver acesso físico à implantação do cliente, ele poderá facilmente assumir o servidor. Mas pelo menos eles não podem atacar as outras implantações! A segurança física é provavelmente a responsabilidade do seu cliente.

If you would for a moment, imagine what would happen if you used a large OpenVPN network for updates... They could then use the compromised server to attack every instance on the VPN

Segurança

Não importa o que você faça, a segurança precisa ser incorporada desde o início. Não faça cortes aqui - Você vai se arrepender no final se você fizer isso.

A garantia completa deste sistema de atualização está fora do escopo deste post, e eu recomendo strongmente contratar um consultor se você ou alguém da sua equipe não tiver conhecimento nesta área. Vale cada centavo.

    
por 01.08.2016 / 00:13
10

Você realmente precisa acessá-los?

Ou apenas atualizá-los? Porque você pode fazer com que eles se atualizem, da mesma forma que as atualizações autônomas feitas por si só.

Se você precisar fazer o login

Por que não um daemon do OpenSSH escutando via encaminhamento de porta? Cada cliente pode ter uma chave separada para segurança e só seria conectada quando necessário.

Até seus clientes

Você precisa levar em consideração o que o cliente está disposto a aceitar também. Eles podem não se sentir confortáveis com qualquer acesso remoto à sua rede ou apenas se sentirem confortáveis com tecnologias / configurações específicas.

    
por 31.07.2016 / 18:42
9

Sugiro uma ferramenta de orquestração como Marionete ou Sal .

Sal é uma fila de mensagens e pode fazer uma conexão de saída persistente de seu appliance para um servidor mestre. Você pode usar isso para executar comandos arbitrários nos dispositivos ... como um apt-get .

A outra opção é o Puppet, onde você ainda tem um servidor mestre e os clientes fazem conexões de saída a partir de seus locais.

Eu uso ambas as ferramentas para um propósito semelhante, onde eu não posso ter o controle administrativo do firewall.

    
por 31.07.2016 / 19:17