Limites de segurança do Docker vs LXC para serviços domésticos privilegiados
O Docker é a opção predefinida mais segura quando um serviço doméstico privilegiado pode permanecer como uma única aplicação declarada, com montagens restritas. O LXC é mais limpo quando precisa genuinamente de um pequeno sistema Linux, mas nenhum dos dois cria uma fronteira de kernel separada.
A questão decisiva não é qual dos rótulos parece mais isolado. Ambos dependem do confinamento pelo kernel do anfitrião. Compare os privilégios efetivamente concedidos, os dispositivos e ficheiros expostos, a unidade que atualiza e restaura, e as consequências de uma fuga. Se a exposição a um kernel partilhado for inaceitável, deixe de comparar Docker e LXC e use uma VM ou um anfitrião separado.
Aceite a fronteira do kernel partilhado antes de comparar funcionalidades
O Docker normalmente empacota uma aplicação e as respetivas dependências; o LXC apresenta um espaço de utilizador Linux mais completo, com init, contas, pacotes e serviços do sistema. Essa diferença operacional não dá ao LXC um kernel convidado independente.
A investigação sobre o confinamento de contentores Linux descreve os mecanismos de namespaces e políticas como um conjunto fragmentado, cuja semântica pode ser difícil de auditar. Esse limite de confinamento baseado num kernel partilhado aplica-se a ambos os candidatos e impede que qualquer um deles seja a resposta quando a separação do kernel é obrigatória.
Mantenha ambos em consideração apenas para cargas de trabalho fidedignas ou limitadas. Transfira código exposto à Internet, imagens desconhecidas ou automatização de alto impacto para uma VM quando um comprometimento não puder alcançar diretamente o kernel do anfitrião.
Deixe o privilégio necessário alterar a opção predefinida
O Docker continua a ser uma opção atrativa quando o serviço precisa de algumas capacidades explícitas, configuração só de leitura e um ou dois caminhos persistentes. A sua definição Compose pode tornar essas exceções visíveis durante a revisão.
O LXC adequa-se a serviços que esperam um sistema Linux convencional, vários daemons, um gestor de pacotes ou uma rede estável ao nível do sistema. O LXC não privilegiado preserva um mapeamento de UID útil, mas o modo privilegiado, o nesting e as montagens bind amplas reduzem essa vantagem.
Conte as exceções em vez de assinalar uma opção de privilégios. Se qualquer uma das soluções precisar de rede do anfitrião, do socket de gestão de contentores, de montagens de sistema com escrita, de todos os dispositivos ou de um perfil não confinado, redesenhe o caminho de acesso ou abandone o nível baseado num kernel partilhado.
O acesso a dispositivos e armazenamento determina o raio de impacto
Um coordenador USB, um nó de renderização GPU, uma interface de UPS ou um diretório de multimédia devem ser expostos de forma tão restrita quanto o serviço permitir. Caminhos de dispositivos estáveis, montagens só de leitura e propriedade explícita de UID/GID são controlos de confinamento, além de definições convenientes.
Um relato recente de uma implementação Proxmox mostra que o LXC não privilegiado pode isolar serviços suportados por Docker em unidades de restauro separadas, continuando a partilhar o kernel do anfitrião e a pilha de armazenamento. Esse padrão LXC de pequeno raio de impacto só é útil quando o nesting e as exceções do controlador de armazenamento permanecem documentados.
Prefira o Docker quando uma aplicação precisar de uma única fronteira de dados pequena. Prefira o LXC quando vários serviços do sistema pertencerem ao mesmo conjunto. Rejeite qualquer uma das soluções se um único comprometimento obtiver acesso de escrita a cópias de segurança, ao controlo do hipervisor ou a dados familiares não relacionados.
Compare a unidade que atualiza e restaura
Uma reversão do Docker normalmente significa restaurar a revisão anterior do Compose e a imagem, juntamente com dados consistentes com a aplicação. A reversão do LXC pode restaurar todo um espaço de utilizador, o que é conveniente, mas também pode reativar pacotes desatualizados, credenciais e alterações manuais ocultas.
Reconstrua cada candidato num anfitrião descartável. No Docker, restaure definições, segredos e volumes; no LXC, recrie ou restaure o contentor e verifique o estado dos pacotes, da rede, dos dispositivos e das montagens. Um teste bem-sucedido mais fácil é uma evidência mais forte do que um menor consumo de memória em inatividade.
A decisão mais abrangente da ZimaSpace sobre fronteiras de serviço VM, LXC e Docker é o passo seguinte quando um kernel independente continua em consideração.
Veredito condicional: escolha a fronteira mais restrita que ainda contenha a falha
Escolha o Docker para uma aplicação fidedigna, bem empacotada, cujos dispositivos, capacidades, segredos e caminhos persistentes possam permanecer explícitos e mínimos.
Escolha o LXC para um ambiente de serviços Linux fidedigno que beneficie genuinamente de init, pacotes, vários daemons ou rede ao nível do sistema, mantendo-se não privilegiado sempre que possível.
Não escolha nenhum dos dois quando a carga de trabalho precisar de um controlo amplo sobre o anfitrião, processar entradas hostis com consequências graves ou tiver de sobreviver a um comprometimento do kernel do anfitrião. Nesse ponto, uma VM ou uma máquina separada não é excesso de engenharia; é a fronteira de segurança em falta.
Produtos recomendados
Comparações de Produtos
Mais para Ler
LXC vs Docker no Proxmox para atualizações e reversões de aplicações
O Docker fornece controlo de versões ao nível da aplicação; o LXC permite reverter ao nível do convidado. A melhor opção depende da menor...
SO NAS pronto a usar vs Linux modular para quem está a construir pela primeira vez
Escolha software NAS pronto a usar para operações de armazenamento orientadas; escolha Linux modular quando a aprendizagem e o controlo explícito justificarem uma maior...
Uma interface Web de NAS reduz o trabalho de recuperação em comparação com o Linux simples?
Uma interface NAS reduz o trabalho rotineiro de recuperação apenas quando a exportação da configuração, a importação do pool e os fluxos de trabalho...
