Linux LXC vs FreeBSD jail (Português)

Há alguma diferença notável entre LXC (contêineres Linux) e FreeBSD “prisões em termos de segurança, estabilidade & desempenho?

Primeiro olha, as duas abordagens são muito semelhantes.

Comentários

  • LXC é uma tecnologia bastante nova, então eu esperaria melhor segurança e estabilidade com prisões. até mesmo um palpite sobre o desempenho. Existem alguns problemas de segurança conhecidos com o LXC que podem ser atenuados usando selinux, por exemplo. No entanto, eu pessoalmente gosto do LXC.
  • @ PavelŠimerda Acabei de ouvir falar do LXC hoje, mas estava surpreso ao descobrir que o Heroku e provavelmente o Google App Engine já usam o LXC.
  • Se você ' esbarrou no LXC, deve dar uma olhada no Docker, que usa LXC sob o capô: docker.io/the_whole_story
  • Docker não não usa mais lxc.
  • @nwildner não ' não usa mais liblxc, mas usa exatamente os mesmos conceitos: namespaces do kernel.

Resposta

Não importa o nome extravagante usado aqui, ambos são soluções para um problema específico: Uma solução de segregação melhor do que o Unix chroot . Virtualização no nível do sistema operacional, contêineres, zonas ou mesmo “chroot com esteróides” são nomes ou títulos comerciais que definem o mesmo conceito de separação do espaço do usuário, mas com recursos diferentes.

O chroot foi introduzido em 18 de março de 1982 , meses antes do lançamento do 4.2 BSD , como uma ferramenta para testar seu sistema de instalação e construção, mas hoje ainda tem suas falhas. Como o primeiro objetivo do chroot era apenas fornecer um caminho newroot , outros aspectos do sistema que precisavam ser isolados ou controlados foram descobertos (rede, visualização do processo, throughput de E / S). É aqui que os primeiros containers (virtualização de nível de usuário) apareceram.

Ambas as tecnologias (FreeBSD Jails e LXC) fazem uso do isolamento do espaço do usuário para fornecer outra camada de segurança. Esta compartimentalização irá garantir que um determinado processo se comunique apenas com outros processos no mesmo contêiner no mesmo host, e se usar algum recurso de rede para alcançar a comunicação do “mundo externo”, todos serão encaminhados para a interface / canal atribuído a este contêiner possui.

Recursos

Prisões FreeBSD:

  • Tecnologia considerada estável, já que é um recurso dentro do FreeBSD desde 4.0;
  • Leva o melhor do sistema de arquivos ZFS no ponto onde você pode clonar jaulas e criar modelos de jaulas para implementar facilmente mais jaulas. Um pouco mais da loucura do ZFS ;
  • Bem documentado e em evolução ;
  • Prisões hierárquicas permitem que você crie prisões dentro de uma prisão (precisamos ir mais fundo!). Combine com allow.mount.zfs para obter mais poder, e outras variáveis como children.max definem o número máximo de prisões infantis.
  • rctl (8) irá lidar com os limites de recursos das cadeias (memória, CPU, disco, …);
  • Prisões FreeBSD lidam com Linux espaço do usuário ;
  • Isolamento de rede com vnet, permitindo que cada prisão tenha sua própria pilha de rede, interfaces, tabelas de endereçamento e roteamento;
  • nullfs para ajudar a vincular pastas às que estão localizadas no servidor real para dentro de uma prisão;
  • utilitário ezjail para ajudar a implantações em massa e gerenciamento de prisões;
  • Muitos ajustáveis do kernel (sysctl ) security.jail.allow.* parâmetros limitarão as ações do usuário root daquela prisão.
  • Talvez, as cadeias do FreeBSD estenderão alguns dos recursos do projeto VPS como migração ao vivo em um futuro próximo.
  • Há algum esforço de integração do ZFS e Docker correndo. Ainda experimental.
  • FreeBSD 12 oferece suporte a bhyve dentro de uma prisão e pf dentro de uma prisão, criando mais isolamento para essas ferramentas
  • Muitas ferramentas interessantes foram desenvolvidas nos últimos anos. Alguns deles estão indexados nesta postagem do blog .
  • Alternativas: Projeto VPS do FreeBSD

Contêineres Linux (LXC):

  • Nova tecnologia “no kernel”, mas sendo endossada por grandes (especialmente Canonical);
  • Contêineres sem privilégios a partir de LXC 1.0, dá um grande passo para a segurança dentro dos contêineres;
  • mapeamento UID e GID dentro dos contêineres;
  • namespaces do kernel, para fazer a separação de IPC, montagem, pid, rede e usuários. Esses namespaces podem ser tratados de forma independente, onde um processo que usa um namespace de rede diferente não será necessariamente isolado em outros aspectos, como armazenamento;
  • Grupos de controle (cgroups) para gerenciar recursos e agrupá-los. CGManager é o cara para conseguir isso.
  • Perfis Apparmor / SELinux e recursos do Kernel para melhor reforçar os recursos do Kernel acessíveis por contêineres. Seccomp também está disponível em contêineres lxc para filtrar chamadas de sistema. Outros aspectos de segurança aqui .
  • Funcionalidade de migração ao vivo em desenvolvimento. É realmente difícil dizer quando estará pronto para uso em produção, já que docker / lxc terá que lidar com a pausa do processo do usuário, instantâneo, migração e consolidação – ref1 , ref2 . A migração ao vivo está funcionando com contêineres básicos (sem passagem de dispositivo nem serviços de rede complexos ou configurações de armazenamento especiais).
  • Ligações de APIs para habilitar o desenvolvimento em python3 e 2, lua, Go, Ruby e Haskell
  • Área centralizada “O que há de novo”. Muito útil sempre que você precisa verificar se algum bug foi corrigido ou um novo recurso foi confirmado. Aqui .
  • Uma alternativa interessante poderia ser lxd , que nos bastidores funciona com lxc, mas tem alguns recursos interessantes como API REST, integração com OpenStack, etc.
  • Outro interessante coisa é que o Ubuntu parece estar enviando zfs como o sistema de arquivos padrão para contêineres em 16,04 . Para manter os projetos alinhados, o lxd lançou sua versão 2.0 e alguns dos recursos são relacionados ao zfs .
  • Alternativas : OpenVZ , Docker
  • Docker . Observe aqui que o Docker usa namespaces, cgroups criando isolamento “por aplicativo” / “por software” . Principais diferenças aqui . Enquanto o LXC cria contêineres com vários processos, o Docker reduz um contêiner tanto quanto possível a um único processo e, em seguida, gerencia isso por meio do Docker.
  • Esforço para integrar o Docker ao SELinux e reduzir os recursos dentro de um contêiner para torná-lo mais seguro – Docker e SELinux, Dan Walsh
  • Qual é a diferença entre Docker, LXD e LXC

O Docker não usa mais lxc. Eles agora têm um lib específica chamada runc que lida com a integração com o namespace do Kernel de baixo nível e recursos de cgroups diretamente.

Nenhuma das tecnologias é uma panaceia de segurança, mas ambas são boas maneiras de isolar um ambiente que não requer virtualização total devido à infraestrutura de sistemas operacionais mistos. A segurança virá depois de muita leitura de documentação e implementação de ajustáveis de kernel, MAC e isolamentos que essas virt de nível de sistema operacional oferecem a você.

Veja também:

Comentários

  • Vale a pena mencionar que, fora da caixa, não há nenhum esforço da lxc para fornecer o isolamento adequado dos hóspedes. lxd , no entanto, tenta fornecer isolamento como prisões BSD ou zonas Solaris.
  • lxd é uma " melhor experiência " do LXC, adicionando outros recursos. No entanto, parece bom citar esse carinha aqui
  • @allquixotic, você quer dizer se estiver usando uma configuração inalterada criada a partir de modelos? Verdadeiro, mas contêineres sem privilégios (habilitados para userns) estavam disponíveis com LXC 1.x e podiam até ser iniciados automaticamente na inicialização do sistema, desde que fossem de propriedade de root (e, portanto, localizados na localização de todo o sistema para contêineres).

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *