Welke invloed heeft containerisolatie op de toegang tot bronnen van Home Assistant?

Eva Wong

IceWhale author

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

How Does Container Isolation Affect Home Assistant Resource Access?

Containerisolatie beperkt de toegang van Home Assistant tot resources doordat expliciete mounts, device-mappings, netwerkpaden, gebruikers en capabilities over de grens van de host nodig zijn.

Een container kan een pad met de naam /config zien en toch niets weten van andere hostmappen. Ook kan de container gewone IP-apparaten bereiken, maar multicastservices niet ontdekken. USB-radio’s, Bluetooth-adapters, seriële poorten, poorten met lage nummers en bestanden die eigendom zijn van de host brengen afzonderlijke toestemmingscontroles met zich mee. Isolatie verbetert de afscherming dus, maar elke vereiste resource moet een bewust geconfigureerde grens passeren.

Mounts bepalen welke persistente bestanden binnen de container bestaan

Een container krijgt zijn eigen bestandssysteemweergave. Bind mounts en benoemde volumes stellen geselecteerde hostgegevens beschikbaar, waardoor een ogenschijnlijk geldig containerpad naar een leeg volume, een alleen-lezenmount of een andere hostmap kan verwijzen dan de beheerder verwacht.

Een analyse van Docker-implementaties koppelt de opslagindeling aan het back-upontwerp, waardoor opslagtoewijzing van de container het eerste toegangscontract is dat moet worden gecontroleerd voordat je het gedrag van de Home Assistant-configuratie of database onderzoekt.

Persistentie hangt af van de gemounte bron, niet van de schrijfbare schijn van de containerlaag. Het opnieuw aanmaken van een container kan niet-gemounte wijzigingen verwijderen, zelfs wanneer ze tijdens de vorige uitvoering werkten.

Gebruikers-ID’s en modusbits blijven van toepassing over de mount heen

De hostkernel beoordeelt eigendom en rechten voor gemounte bestanden. Een numerieke containergebruiker kan verschillen van de accountnaam op de host, wat kan leiden tot leesfouten, vervangende bestanden die eigendom zijn van root of een database die in de ene image wel opent en in een andere niet.

Een analyse van eigenaarschap verklaart waarom overeenkomende namen niet voldoende zijn en waarom toewijzing van numerieke UID’s en GID’s afhankelijk is van numerieke UID- en GID-waarden die aan beide kanten van de grens worden gedeeld.

Uitvoeren met verhoogde rechten kan de mismatch verbergen, maar breidt de bevoegdheden veel verder uit dan alleen het bestand. De veiligere oplossing is het eigenaarschap op elkaar af te stemmen en alleen de mappen en bewerkingen toe te staan die Home Assistant daadwerkelijk nodig heeft.

De netwerkmodus bepaalt ontdekking en bereikbaarheid

Bridgenetwerken geven de container een geïsoleerde interface en vertaalde poorten. Hostnetwerken delen de netwerkstack van de host, wat multicastontdekking, broadcastprotocollen en callbacks kan vereenvoudigen, maar de netwerkscheiding vermindert en poortconflicten kan veroorzaken.

Een bespreking van Home Assistant over het vermijden van de hostmodus laat zien dat de ontdekkingsgrens van de container in sommige omgevingen kan worden herbouwd met expliciete routering of relays, hoewel niet elk ontdekkingsprotocol zich hetzelfde gedraagt.

Als directe IP-besturing werkt maar automatische ontdekking faalt, zijn multicast- of broadcastgrenzen waarschijnlijk de oorzaak. Als beide falen, zijn routering, firewall, DNS of adresselectie waarschijnlijker dan alleen een probleem met ontdekking.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

Apparaten en kernelfuncties vereisen expliciete delegatie

USB-seriële radio’s, Bluetooth, GPIO, hardwareversnelling en netwerkbewerkingen op laag niveau zijn afhankelijk van hostapparaatknooppunten, kernelstuurprogramma’s, groepen en capabilities. Een apparaatpad toewijzen is noodzakelijk, maar mogelijk niet voldoende wanneer rechten of cgroup-beleid de toegang weigeren.

Een verslag over een Kubernetes-implementatie laat zien hoe orkestratie extra beperkingen voor opslag, netwerken en apparaten introduceert. Dit illustreert dat beperkingen door gelaagde isolatie toenemen met elke isolatielaag.

Dit mechanisme stopt bij hardware- en stuurprogrammafouten. Als de host de radio of het apparaat zelf niet kan gebruiken, verhult het wijzigen van containerrechten alleen de oorspronkelijke fout; controleer de toegang op de host voordat je de bevoegdheden van de container uitbreidt.

Controleer de toegang van host tot proces

Noteer elk vereist pad, elke poort, elk multicastdomein, elk apparaat, elke UID, elke GID, elke capability en elke afhankelijkheid. Test voor elk onderdeel eerst de toegang op de host, controleer daarna de containertoewijzing en test vervolgens met de identiteit van het daadwerkelijke containerproces.

De afweging tussen host en bridge vergelijkt host- en bridgenetwerken voor Home Assistant en biedt het afwegingskader voor het netwerkgedeelte van de audit.

Houd de kleinst mogelijke set rechten aan die de tests voor configuratie lezen en schrijven, databasepersistentie, lokale apparaatbesturing, ontdekking, herstarten en back-upherstel doorstaat. Voeg pas een mount, apparaat, groep of capability toe wanneer de voorgaande test aantoont dat dit de ontbrekende grens is.