Kāpēc priviliģētais režīms ir plašāks, nekā VPN nepieciešams

Konteiners negribēja atvērt savu tuneli, tāpēc tika pievienots priviliģētais karodziņš, un tagad tas darbojas. Šī secība pierādīja tikai to, ka trūka vismaz vienas atļaujas, un neko nepasaka par to, kuras. Priviliģētais režīms piešķir iespēju kopumu un piekļuvi ierīcēm, kas ir daudz plašāka, nekā nepieciešams tuneļa saskarnei.

Ko karodziņš patiešām maina

Priviliģēts konteiners saņem plašas iespējas un piekļuvi resursdatora ierīcēm, kas ir daudz lielāka atļauja, nekā prasa tīkla ceļš. Precīzo kopumu dokumentē izpildes vide, nevis nosaka mutvārdu tradīcija, un Docker dokumentācija par konteineru palaišanu apraksta pieejamās priviliģēto tiesību opcijas. Viena lasīšanas reize ir pietiekama, lai redzētu, ka tunelis ir maza kopuma daļa.

Divas šaurākas prasības aptver lielāko daļu VPN konteineru. Saskarnes konfigurēšanai nepieciešama tīkla administrēšanas iespēja, un tuneļa ierīces atvēršanai nepieciešama piekļuve tieši tam ierīces mezglam. Tās ir atsevišķas atļaujas, un pat abas kopā ir šaurākas par vispārējo opciju. Pārējai priviliģētā kopuma daļai nav nekāda sakara ar tuneli. Tas pastāv darba slodzēm, kurām patiešām nepieciešama piekļuve resursdatora līmenī, un VPN konteiners parasti nav viens no tiem.

Saskaņojiet katru kļūdu ar vienu priekšnoteikumu

Kļūdas ziņojums pasaka, kura priekšnoteikuma trūkst, ja to izlasāt pirms apspiešanas. Ziņojums par ierīces mezglu nosauc ierīci, ziņojums par neatļautu darbību nosauc iespēju, un ziņojums par moduli vai sysctl nosauc kodola atbalstu. Katram no tiem ir cits labojums, un tikai viens no tiem ir iespēja.

Trūkstošais konfigurācijas fails paliek trūkstošs pēc visu iespēju piešķiršanas, tāpēc priviliģētais režīms dažreiz nemaina pilnīgi neko. Konteiners startē, tunelis joprojām neizdodas, un īstā kļūda nekad nav bijusi par atļaujām. Kodola atbalsts ir trešais gadījums un visvieglāk pārlasāmais. Moduli, kas nav ielādēts resursdatorā, nevar ielādēt no nepriviliģēta konteinera iekšienes, un vairāk iespēju piešķiršana konteinera iekšienē nemaina resursdatora stāvokli.

Pārbaudiet prasību, nevis simptomu

Sāciet ar minimālo izsaukumu, ko dokumentē attēls, izpildiet to un saglabājiet precīzo kļūmes tekstu. Pēc tam pievienojiet pa vienai atļaujai un atzīmējiet, kura papildinājums mainīja rezultātu.

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

Konteiners, kas redz ierīci un kuram ir iespēja, bet joprojām neizdodas, pasaka, ka problēma ir citur. Tas ir noderīgs rezultāts, un priviliģētais režīms to būtu paslēpis.

Pārbaudiet arī ierīces atļaujas resursdatorā, jo pareizi piešķirts ierīces mezgls ar nepareizu grupas īpašumtiesībām rada tādu pašu kļūdu kā trūkstoša atļauja.

Pierakstiet šaurāko strādājošo atļauju

Pierakstiet katru ierīci un iespēju, kas nepieciešama izvietošanai, kopā ar kļūdu, kas to attaisnoja. Tieši šis ieraksts ļauj nākamajam cilvēkam droši kaut ko noņemt, un tieši to auditors prasīs, kad konteiners tiks ziņots kā priviliģēts.

Pārskatiet arī apkārtējo kontekstu, jo resursdatora tīkls, resursdatora montāžas un izpildes vides opcijas katra var paplašināt atļaujas ietekmi. Izolēts laboratorijas izsaukums, kas apvieno tos visus, nav ražošanas konfigurācija, lai cik labi tas arī strādātu. Pārbaudiet lietotni, tās DNS uzvedību un tuneļa kļūmi pirms izvietošanas pasludināšanas par pabeigtu. Atļauja izveidot saskarni nav izejas politika, un konteiners, kas spēj perfekti tunelēt, joprojām maršrutē visu, ko lietotne sūta.