Waarom geprivilegieerde modus breder is dan een VPN nodig heeft

De container wilde zijn tunnel niet openen, dus ging de geprivilegieerde vlag erin, en nu werkt het. Die reeks stelde alleen vast dat er minstens één machtiging ontbrak, en zegt niets over welke. Geprivilegieerde modus verleent een reeks mogelijkheden en apparaattoegang die veel ruimer is dan een tunnelinterface nodig heeft.

Wat de vlag werkelijk verandert

Een geprivilegieerd container krijgt ruime mogelijkheden en toegang tot apparaten van de host, wat een veel grotere toekenning is dan het netwerkpad vereist. De exacte set wordt door de uitvoeringsomgeving gedocumenteerd en niet door overlevering vastgelegd, en de Docker-documentatie over het draaien van containers beschrijft de beschikbare privilegeopties. Eén keer lezen volstaat om te zien dat de tunnel een klein deel van het geheel is.

Twee smallere eisen dekken de meeste VPN-containers. Een interface configureren vereist de mogelijkheid tot netwerkbeheer, en het tunnelapparaat openen vereist toegang tot precies dat apparaatknooppunt. Dat zijn afzonderlijke toekenningen, en zelfs beide samen zijn smaller dan de algemene optie. De rest van de geprivilegieerde set heeft niets met de tunnel te maken. Die bestaat voor workloads die echt toegang op hostniveau nodig hebben, en een VPN-container is meestal niet een van hen.

Koppel elke fout aan één voorwaarde

De foutmelding vertelt u welke voorwaarde ontbreekt als u hem leest voordat u hem onderdrukt. Een melding over een apparaatknooppunt noemt het apparaat, een melding over een niet-toegestane bewerking noemt een mogelijkheid, en een melding over een module of een sysctl noemt kernelondersteuning. Elk daarvan heeft een andere oplossing, en slechts één ervan is een mogelijkheid.

Een ontbrekend configuratiebestand blijft ontbreken nadat elke mogelijkheid is verleend, waardoor de geprivilegieerde modus soms helemaal niets verandert. De container start, de tunnel faalt nog steeds, en de echte fout ging nooit over machtigingen. Kernelondersteuning is het derde geval en het gemakkelijkst verkeerd te lezen. Een module die niet op de host is geladen, kan niet van binnenuit een niet-geprivilegieerd container worden geladen, en meer mogelijkheden binnen de container geven verandert de toestand van de host niet.

Controleer de eis, niet het symptoom

Begin met de minimale aanroep die de image documenteert, voer hem uit en bewaar de exacte fouttekst. Voeg dan één toekenning per keer toe en noteer welke toevoeging het resultaat veranderde.

ls -l /dev/net/tun
docker run --rm --cap-add NET_ADMIN --device /dev/net/tun image:tag
ip -br link show type tun

Een container die het apparaat ziet en de mogelijkheid heeft maar toch faalt, vertelt u dat het probleem elders ligt. Dat is een nuttig resultaat, en de geprivilegieerde modus zou het hebben verborgen.

Controleer ook de apparaatmachtigingen op de host, want een correct toegekend apparaatknooppunt met de verkeerde groepseigendom geeft dezelfde fout als een ontbrekende toekenning.

Noteer de smalste toekenning die werkt

Noteer elk apparaat en elke mogelijkheid die de uitrol nodig heeft, samen met de fout die ze rechtvaardigde. Dat overzicht is wat de volgende persoon in staat stelt iets veilig te verwijderen, en dat is wat een auditor zal vragen wanneer een container als geprivilegieerd wordt gemeld.

Bekijk ook de omringende context, want hostnetwerken, hostmounts en uitvoeringsopties kunnen elk de impact van een toekenning vergroten. Een geïsoleerde laboratoriumaanroep die ze allemaal combineert, is geen productieconfiguratie, hoe goed hij ook werkte. Test de toepassing, het DNS-gedrag en een tunnelfout voordat u de uitrol als voltooid beschouwt. Toestemming om een interface te maken is geen uitgaand beleid, en een container die perfect kan tunnelen routeert nog steeds alles wat de toepassing stuurt.