Limites de segurança do Docker e do LXC para serviços domésticos privilegiados

O Docker é a opção predefinida mais segura quando um serviço doméstico privilegiado pode continuar a ser uma única aplicação declarada, com montagens restritas. O LXC é mais simples quando precisa realmente de um pequeno sistema Linux, mas nenhum dos dois cria um limite de kernel separado.

A questão decisiva não é qual dos nomes parece indicar mais isolamento. Ambos dependem do confinamento do kernel do anfitrião. Compare os privilégios efetivamente concedidos, os dispositivos e ficheiros expostos, a unidade que aplica patches e restaura, e as consequências de uma fuga. Se a exposição ao kernel partilhado for, por si só, inaceitável, deixe de comparar Docker e LXC e use uma VM ou um anfitrião separado.

Aceite o limite do kernel partilhado antes de comparar funcionalidades

Normalmente, o Docker 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 de convidado independente.

A investigação sobre o confinamento de contentores Linux descreve os mecanismos de espaços de nomes e políticas como um conjunto heterogéneo, cuja semântica pode ser difícil de auditar. Esse limite de confinamento do kernel partilhado aplica-se a ambos os candidatos e impede que qualquer um seja a solução quando é obrigatória a separação do kernel.

Mantenha ambos como opções apenas para cargas de trabalho fidedignas ou limitadas. Passe código exposto à Internet, imagens desconhecidas ou automatização de alto impacto para uma VM quando uma violação não puder alcançar diretamente o kernel do anfitrião.

Deixe que os privilégios necessários determinem a opção predefinida

O Docker continua a ser uma opção atraente quando o serviço precisa de algumas capacidades explícitas, configuração só de leitura e um ou dois caminhos persistentes. A respetiva definição Compose pode tornar essas exceções visíveis durante a revisão.

O LXC é adequado 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 sem privilégios preserva um mapeamento de UID útil, mas o modo privilegiado, o aninhamento e as montagens bind abrangentes reduzem essa vantagem.

Conte as exceções em vez de assinalar uma opção de privilégios. Se qualquer uma das configurações exigir rede do anfitrião, o socket de gestão de contentores, montagens de sistema com escrita, acesso a todos os dispositivos ou um perfil sem restrições, redesenhe o caminho de acesso ou saia do nível de kernel partilhado.

O acesso aos dispositivos e ao armazenamento determina o alcance de uma violação

Um coordenador USB, um nó de renderização GPU, uma interface de UPS ou um diretório de multimédia devem ser expostos da forma mais restrita que o serviço permitir. Caminhos estáveis para dispositivos, montagens só de leitura e propriedade explícita de UID/GID são medidas de contenção, além de definições convenientes.

Um relato recente de implementação do Proxmox mostra que o LXC sem privilégios pode isolar serviços baseados em Docker em unidades de restauro separadas, partilhando ainda assim o kernel e a pilha de armazenamento do anfitrião. Este padrão LXC com raio de impacto reduzido só é útil quando as exceções de aninhamento e dos controladores de armazenamento estão documentadas.

Prefira Docker quando uma aplicação precisar de um único limite de dados reduzido. Prefira LXC quando vários serviços de sistema devam funcionar em conjunto. Rejeite qualquer uma das configurações se uma única intrusão der acesso de escrita às cópias de segurança, ao controlo do hipervisor ou a dados não relacionados da família.

Featured

ZimaBoard 2 - Mini servidor doméstico para a sua grande ideia

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

Compare a unidade que corrige e restaura

A reversão no Docker significa normalmente restaurar a revisão anterior do Compose e a imagem, juntamente com dados consistentes com a aplicação. A reversão no LXC pode restaurar todo um espaço de utilizador, o que é conveniente, mas também pode reintroduzir pacotes desatualizados, credenciais e alterações manuais ocultas.

Reconstrua cada opção num anfitrião descartável. No Docker, restaure as definições, os segredos e os volumes; no LXC, recrie ou restaure o contentor e verifique os pacotes, a rede, os dispositivos e o estado dos pontos de montagem. Um teste bem-sucedido mais simples constitui uma prova mais forte do que um menor consumo de memória em repouso.

A decisão mais abrangente do ZimaSpace sobre os limites de serviço de VM, LXC e Docker é o passo seguinte quando um kernel independente continua a ser necessário.

Veredito condicional: escolha o limite mais restrito que ainda contenha a falha

Escolha Docker para uma aplicação de confiança, bem empacotada, cujos dispositivos, capacidades, segredos e caminhos persistentes possam manter-se explícitos e mínimos.

Escolha LXC para um ambiente de serviço Linux de confiança que beneficie realmente de um sistema de inicialização, pacotes, vários serviços ou redes ao nível do sistema, mantendo-o sem privilégios sempre que possível.

Não escolha nenhuma das opções quando a carga de trabalho exigir um controlo amplo do anfitrião, processar dados não fiáveis com consequências graves ou ter de resistir a uma intrusão no kernel do anfitrião. Nesse caso, uma VM ou máquina separada não é complexidade excessiva; é o limite de segurança em falta.