Miks privilegeeritud režiim on laiem kui VPN vajab

Konteiner ei tahtnud oma tunnelit avada, seega lisati privilegeeritud lipp ja nüüd see töötab. See jada tõestas vaid, et puudu oli vähemalt üks luba, ega ütle midagi selle kohta, milline. Privilegeeritud režiim annab hulga võimeid ja seadmejuurdepääsu, mis on palju laiem kui tunneli liidesel vaja.

Mida lipp tegelikult muudab

Privilegeeritud konteiner saab laiad võimed ja juurdepääsu hosti seadmetele, mis on palju suurem luba kui võrguteekond nõuab. Täpse hulga dokumenteerib käituskeskkond, mitte ei määra pärimus, ja Dockeri dokumentatsioon konteinerite käivitamise kohta kirjeldab saadaolevaid privileegivalikuid. Ühest lugemisest piisab, et näha, et tunnel on kogusumma väike osa.

Kaks kitsamat nõuet katavad enamiku VPN-konteineritest. Liidese seadistamine nõuab võrgu haldamise võimet ja tunnelseadme avamine nõuab juurdepääsu just sellele seadmesõlmele. Need on eraldi load, ja isegi mõlemad koos on kitsamad kui üldine valik. Ülejäänud privilegeeritud hulgal pole tunneliga mingit pistmist. See on mõeldud töökoormustele, mis tõesti vajavad juurdepääsu hosti tasandil, ja VPN-konteiner tavaliselt pole üks neist.

Sobitage iga viga ühe eeldusega

Veateade ütleb teile, milline eeldus puudub, kui loete seda enne selle summutamist. Seadmesõlme käsitlev teade nimetab seadme, lubamata toimingu teade nimetab võime ja mooduli või sysctli teade nimetab kerneli tuge. Igal neist on erinev parandus, ja ainult üks neist on võime.

Puuduv konfiguratsioonifail jääb puuduma pärast kõigi võimete andmist, mistõttu privilegeeritud režiim ei muuda mõnikord üldse midagi. Konteiner käivitub, tunnel ebaõnnestub endiselt ja tegelik viga ei olnud kunagi lubade kohta. Kerneli tugi on kolmas juhtum ja kõige kergemini valesti loetav. Hosti mitte laaditud moodulit ei saa laadida mitteprivilegeeritud konteineri seest, ja rohkemate võimete andmine konteineri sees ei muuda hosti olekut.

Kontrollige nõuet, mitte sümptomit

Alustage minimaalsest väljakutsest, mille kujutis dokumenteerib, käivitage see ja hoidke täpne ebaõnnestumise tekst. Seejärel lisage üks luba korraga ja märkige, milline lisandus tulemust muutis.

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

Konteiner, mis näeb seadet ja omab võimet, kuid ebaõnnestub ikkagi, ütleb teile, et probleem on mujal. See on kasulik tulemus, ja privilegeeritud režiim oleks selle peitnud.

Kontrollige ka seadme õigusi hostil, sest õigesti antud seadmesõlm vale grupiomandiga tekitab sama vea nagu puuduv luba.

Kirjutage üles kitsaim luba, mis töötab

Kirjutage üles iga seade ja võime, mida juurutus vajab, koos veaga, mis seda õigustas. Just see kirje võimaldab järgmisel inimesel midagi turvaliselt eemaldada, ja just seda küsib audiitor, kui konteinerist teatatakse kui privilegeeritud konteinerist.

Vaadake üle ka ümbritsev kontekst, sest hosti võrk, hosti kinnitused ja käituskeskkonna valikud võivad igaüks suurendada loa mõju. Isoleeritud laborikatse, mis ühendab neid kõiki, ei ole tootmiskonfiguratsioon, ükskõik kui hästi see töötas. Testige rakendust, selle DNS-käitumist ja tunneli ebaõnnestumist enne, kui nimetate juurutuse valmis. Luba liidese loomiseks ei ole väljundpoliitika, ja konteiner, mis oskab täiuslikult tunnelitada, suunab ikkagi kõik, mida rakendus saadab.