In che modo l’isolamento dei container influisce sull’accesso alle risorse di Home Assistant?

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

How Does Container Isolation Affect Home Assistant Resource Access?

L’isolamento dei container limita l’accesso di Home Assistant alle risorse richiedendo mount, mappature dei dispositivi, percorsi di rete, utenti e capacità espliciti attraverso il confine dell’host.

Un container può vedere un percorso denominato /config senza essere a conoscenza di ogni altra directory dell’host e può raggiungere i dispositivi IP ordinari, ma non riuscire a rilevare i servizi multicast. Radio USB, adattatori Bluetooth, porte seriali, porte con numeri inferiori a 1024 e file di proprietà dell’host aggiungono controlli di autorizzazione separati. L’isolamento migliora quindi il contenimento, ma ogni risorsa necessaria deve attraversare un confine configurato deliberatamente.

I mount definiscono quali file persistenti esistono all’interno

Un container riceve una propria visualizzazione del filesystem. I bind mount e i volumi denominati espongono dati host selezionati, quindi un percorso del container apparentemente valido può puntare a un volume vuoto, a un mount di sola lettura o a una directory dell’host diversa da quella prevista dall’amministratore.

Un’analisi della distribuzione Docker collega la struttura dello storage alla progettazione dei backup, rendendo la mappatura dello storage del container il primo contratto di accesso da verificare prima di diagnosticare il comportamento della configurazione o del database di Home Assistant.

La persistenza dipende dalla sorgente montata, non dall’aspetto scrivibile del layer del container. Ricreare un container può eliminare le modifiche non montate anche se funzionavano durante l’esecuzione precedente.

Gli ID utente e i bit dei permessi si applicano ancora attraverso il mount

Il kernel dell’host valuta la proprietà e i permessi dei file montati. Un utente numerico del container può differire dal nome dell’account sull’host, causando errori di lettura, file sostitutivi di proprietà di root o un database che si apre in un’immagine ma non in un’altra.

Un’analisi della proprietà spiega perché i nomi corrispondenti non siano sufficienti e perché la mappatura numerica di UID e GID dipenda dai valori numerici di UID e GID condivisi attraverso il confine.

Eseguire il container con privilegi elevati può mascherare la discrepanza, ma amplia l’autorità ben oltre l’accesso ai file. La soluzione più sicura consiste nell’allineare la proprietà e concedere solo le directory e le operazioni effettivamente necessarie a Home Assistant.

La modalità di rete controlla rilevamento e raggiungibilità

La rete bridge assegna al container un’interfaccia isolata e porte tradotte. La rete host condivide lo stack dell’host, semplificando il rilevamento multicast, i protocolli broadcast e i callback, ma riduce la separazione di rete e può creare conflitti tra porte.

Una discussione su Home Assistant dedicata a evitare la modalità host mostra che il confine di rilevamento del container può essere ricostruito con routing o relay espliciti in alcuni ambienti, anche se non tutti i protocolli di rilevamento si comportano allo stesso modo.

Se il controllo tramite IP diretto funziona ma il rilevamento automatico non riesce, è probabile che esistano confini multicast o broadcast. Se entrambi falliscono, routing, firewall, DNS o selezione dell’indirizzo sono candidati più probabili del solo rilevamento.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

I dispositivi e le funzionalità del kernel richiedono una delega esplicita

Le radio seriali USB, il Bluetooth, il GPIO, l’accelerazione hardware e le operazioni di rete a basso livello dipendono dai nodi dei dispositivi dell’host, dai driver del kernel, dai gruppi e dalle capacità. Mappare un percorso del dispositivo è necessario, ma potrebbe non essere sufficiente quando i permessi o i criteri cgroup negano l’accesso.

Un resoconto della distribuzione Kubernetes mostra come l’orchestrazione introduca ulteriori vincoli di storage, rete e dispositivi, illustrando che i vincoli dell’isolamento a più livelli aumentano con ogni livello di isolamento.

Questo meccanismo si arresta in caso di problemi hardware o dei driver. Se l’host stesso non riesce a utilizzare la radio o il dispositivo, modificare i privilegi del container nasconde soltanto il problema originale; verifica l’accesso dall’host prima di ampliare l’autorità del container.

Verifica l’accesso dall’host al processo

Elenca ogni percorso, porta, dominio multicast, dispositivo, UID, GID, capacità e dipendenza necessari. Per ciascuno, verifica prima l’accesso dall’host, poi ispeziona la mappatura del container e infine esegui il test con l’identità effettiva del processo del container.

Il compromesso tra host e bridge confronta la rete host e bridge per Home Assistant, definendo il confine del compromesso per la parte di rete della verifica.

Mantieni il set di permessi più ridotto che superi i test di lettura-scrittura della configurazione, persistenza del database, controllo dei dispositivi locali, rilevamento, riavvio e ripristino da backup. Aggiungi un mount, un dispositivo, un gruppo o una capacità solo quando il test precedente dimostra che quello è il confine mancante.