Como é que o isolamento de contentores afeta o acesso do Home Assistant aos recursos?

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

O isolamento dos contentores limita o acesso do Home Assistant aos recursos, exigindo montagens, mapeamentos de dispositivos, caminhos de rede, utilizadores e capacidades explicitamente definidos através da fronteira do anfitrião.

Um contentor pode ver um caminho denominado /config e, ainda assim, desconhecer todos os outros diretórios do anfitrião; também pode alcançar dispositivos IP comuns, mas não conseguir descobrir serviços multicast. Rádios USB, adaptadores Bluetooth, portas série, portas de numeração baixa e ficheiros pertencentes ao anfitrião acrescentam verificações de permissões distintas. Assim, o isolamento melhora a contenção, mas cada recurso necessário tem de atravessar uma fronteira configurada deliberadamente.

As montagens definem quais os ficheiros persistentes que existem no interior

Um contentor recebe a sua própria vista do sistema de ficheiros. As montagens bind e os volumes nomeados expõem dados selecionados do anfitrião, pelo que um caminho aparentemente válido no contentor pode apontar para um volume vazio, uma montagem só de leitura ou um diretório do anfitrião diferente daquele que o operador espera.

Uma análise de uma implementação Docker relaciona a organização do armazenamento com o desenho das cópias de segurança, tornando o mapeamento do armazenamento do contentor no primeiro contrato de acesso a verificar antes de diagnosticar o comportamento da configuração ou da base de dados do Home Assistant.

A persistência depende da origem montada, não do aspeto gravável da camada do contentor. Recriar um contentor pode eliminar alterações não montadas, mesmo que tenham funcionado durante a execução anterior.

Os IDs de utilizador e os bits de modo continuam a aplicar-se através da montagem

O kernel do anfitrião avalia a propriedade e as permissões dos ficheiros montados. Um utilizador numérico do contentor pode ser diferente do nome da conta no anfitrião, provocando falhas de leitura, substituições pertencentes ao root ou uma base de dados que abre numa imagem, mas não noutra.

Uma análise da propriedade explica por que razão nomes coincidentes não são suficientes e por que o mapeamento numérico de UID e GID depende de valores numéricos de UID e GID partilhados através da fronteira.

Executar com privilégios pode ocultar a incompatibilidade, mas amplia a autoridade muito para além do acesso aos ficheiros. A solução mais segura é alinhar a propriedade e conceder apenas os diretórios e as operações de que o Home Assistant realmente necessita.

O modo de rede controla a descoberta e a acessibilidade

A rede bridge atribui ao contentor uma interface isolada e portas traduzidas. A rede host partilha a pilha de rede do anfitrião, o que pode simplificar a descoberta multicast, os protocolos de difusão e os callbacks, mas reduz a separação de rede e pode criar conflitos de portas.

Uma discussão sobre o Home Assistant que aborda como evitar o modo host mostra que a fronteira de descoberta do contentor pode ser reconstruída com encaminhamento explícito ou relés em alguns ambientes, embora nem todos os protocolos de descoberta se comportem da mesma forma.

Se o controlo direto por IP funcionar, mas a descoberta automática falhar, é provável que existam fronteiras multicast ou de difusão. Se ambos falharem, o encaminhamento, a firewall, o DNS ou a seleção de endereços são candidatos mais fortes do que a descoberta por si só.

Os dispositivos e as funcionalidades do kernel precisam de delegação explícita

Rádios série USB, Bluetooth, GPIO, aceleração de hardware e operações de rede de baixo nível dependem de nós de dispositivos do anfitrião, controladores do kernel, grupos e capacidades. Mapear um caminho de dispositivo é necessário, mas pode não ser suficiente quando as permissões ou a política cgroup negam o acesso.

Um relato de uma implementação Kubernetes mostra como a orquestração introduz restrições adicionais de armazenamento, rede e dispositivos, ilustrando que as restrições de isolamento em camadas aumentam a cada camada de isolamento.

Este mecanismo termina perante uma falha de hardware ou de controlador. Se o próprio anfitrião não conseguir utilizar o rádio ou o dispositivo, alterar os privilégios do contentor apenas obscurece a falha original; verifique o acesso no anfitrião antes de ampliar a autoridade do contentor.

Audite o acesso desde o anfitrião até ao processo

Liste todos os caminhos, portas, domínios multicast, dispositivos, UID, GID, capacidades e dependências necessários. Para cada um, teste primeiro o acesso no anfitrião, depois inspecione o mapeamento no contentor e, por fim, teste como a identidade efetiva do processo do contentor.

O compromisso entre anfitrião e bridge compara a rede host e bridge para o Home Assistant, fornecendo o limite de compromisso para a componente de rede da auditoria.

Mantenha o conjunto mínimo de permissões que permita passar nos testes de leitura e escrita da configuração, persistência da base de dados, controlo de dispositivos locais, descoberta, reinício e restauro de cópias de segurança. Adicione uma montagem, um dispositivo, um grupo ou uma capacidade apenas quando o teste anterior provar que essa é a fronteira em falta.

Centro de Tecnologia e IA

Mais para Ler

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.