Kodėl privilegijuotas režimas platesnis, nei VPN reikia

Konteineris nenorėjo atidaryti savo tunelio, todėl buvo įdėta privilegijuota vėliavėlė, ir dabar tai veikia. Ši seka įrodė tik tai, kad trūko bent vieno leidimo, ir nieko nesako apie tai, kurio. Privilegijuotas režimas suteikia galimybių rinkinį ir prieigą prie įrenginių, daug platesnį, nei reikia tunelio sąsajai.

Ką vėliavėlė iš tikrųjų keičia

Privilegijuotas konteineris gauna plačias galimybes ir prieigą prie pagrindinio kompiuterio įrenginių, o tai yra daug didesnis leidimas, nei reikalauja tinklo kelias. Tikslų rinkinį dokumentuoja vykdymo aplinka, o ne nustato padavimas, ir Docker dokumentacija apie konteinerių paleidimą aprašo galimas privilegijų parinktis. Vieno perskaitymo pakanka pamatyti, kad tunelis yra maža visumos dalis.

Du siauresni reikalavimai apima daugumą VPN konteinerių. Sąsajos konfigūravimui reikia tinklo administravimo galimybės, o tunelio įrenginio atidarymui reikia prieigos prie būtent to įrenginio mazgo. Tai atskiri leidimai, ir net abu kartu yra siauresni už bendrą parinktį. Likusi privilegijuoto rinkinio dalis neturi nieko bendra su tuneliu. Jis egzistuoja darbo krūviams, kuriems tikrai reikia prieigos pagrindinio kompiuterio lygmeniu, ir VPN konteineris paprastai nėra vienas iš jų.

Suskirkite kiekvieną klaidą vienai prielaidai

Klaidos pranešimas pasako, kurios prielaidos trūksta, jei perskaitysite jį prieš jį nuslopindami. Pranešimas apie įrenginio mazgą įvardija įrenginį, pranešimas apie neleidžiamą operaciją įvardija galimybę, o pranešimas apie modulį ar sysctl įvardija branduolio palaikymą. Kiekvienas jų turi skirtingą sprendimą, ir tik vienas jų yra galimybė.

Trūkstamas konfigūracijos failas lieka trūkstamas suteikus visas galimybes, todėl privilegijuotas režimas kartais nekeičia visiškai nieko. Konteineris paleidžiamas, tunelis vis tiek nepavyksta, o tikroji klaida niekada nebuvo apie leidimus. Branduolio palaikymas yra trečiasis atvejis ir lengviausiai neteisingai perskaitomas. Modulis, neįkeltas pagrindiniame kompiuteryje, negali būti įkeltas neprivilegijuoto konteinerio viduje, o daugiau galimybių suteikimas konteinerio viduje nekeičia pagrindinio kompiuterio būsenos.

Tikrinkite reikalavimą, o ne simptomą

Pradėkite nuo minimalaus iškvietimo, kurį dokumentuoja atvaizdas, paleiskite jį ir išsaugokite tikslų gedimo tekstą. Tada pridėkite po vieną leidimą ir pažymėkite, kuris papildymas pakeitė rezultatą.

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

Konteineris, kuris mato įrenginį ir turi galimybę, bet vis tiek nepavyksta, sako, kad problema yra kitur. Tai naudingas rezultatas, ir privilegijuotas režimas būtų jį paslėpęs.

Patikrinkite ir įrenginio leidimus pagrindiniame kompiuteryje, nes teisingai suteiktas įrenginio mazgas su neteisinga grupės nuosavybe sukelia tą pačią klaidą kaip trūkstamas leidimas.

Užrašykite siauriausią veikiantį leidimą

Užrašykite kiekvieną įrenginį ir galimybę, kurių reikia diegimui, kartu su klaida, kuri juos pateisino. Būtent šis įrašas leidžia kitam žmogui saugiai ką nors pašalinti, ir būtent jo paprašys auditorius, kai konteineris bus praneštas kaip privilegijuotas.

Peržiūrėkite ir aplinkinį kontekstą, nes pagrindinio kompiuterio tinklas, prijungimai ir vykdymo aplinkos parinktys kiekvienas gali išplėsti leidimo poveikį. Izoliuotas laboratorijos iškvietimas, kuris sujungia juos visus, nėra produkcinė konfigūracija, kad ir kaip gerai jis veiktų. Išbandykite programą, jos DNS elgseną ir tunelio gedimą prieš paskelbdami diegimą baigtu. Leidimas sukurti sąsają nėra išėjimo politika, ir konteineris, kuris puikiai tuneliuoja, vis tiek maršrutizuoja viską, ką siunčia programa.