Zakaj je privilegirani način širši, kot ga VPN potrebuje

Vsebnik ni hotel odpreti svojega tunela, zato je bila dodana privilegirana zastavica, in zdaj deluje. To zaporedje je potrdilo le, da je manjkalo vsaj eno dovoljenje, in ne pove ničesar o tem, katero. Privilegirani način podeljuje nabor zmogljivosti in dostop do naprav, ki je veliko širši, kot ga potrebuje vmesnik tunela.

Kaj zastavica dejansko spremeni

Privilegirani vsebnik prejme široke zmogljivosti in dostop do naprav gostitelja, kar je veliko večja odobritev, kot jo zahteva omrežna pot. Natančen nabor dokumentira izvajalno okolje in ga ne določa izročilo, in dokumentacija Dockerja o zaganjanju vsebnikov opisuje razpoložljive možnosti privilegijev. Enkratno branje zadostuje, da vidite, da je tunel majhen del celote.

Dve ožji zahtevi pokrivata večino vsebnikov VPN. Konfiguracija vmesnika zahteva zmožnost upravljanja omrežja, odpiranje tunelske naprave pa zahteva dostop do točno tega vozlišča naprave. To so ločene odobritve, in tudi obe skupaj sta ožji od splošne možnosti. Preostanek privilegiranega nabora nima nič opraviti s tunelom. Obstaja za delovne obremenitve, ki res potrebujejo dostop na ravni gostitelja, in vsebnik VPN običajno ni eden od njih.

Vsako napako povežite z enim predpogojem

Sporočilo o napaki vam pove, kateri predpogoj manjka, če ga preberete, preden ga zadušite. Sporočilo o vozlišču naprave poimenuje napravo, sporočilo o nedovoljeni operaciji poimenuje zmogljivost, sporočilo o modulu ali sysctl pa poimenuje podporo jedra. Vsako od njih ima drugačno popravilo, in samo eno od njih je zmogljivost.

Manjkajoča konfiguracijska datoteka ostane manjkajoča po podelitvi vseh zmogljivosti, zato privilegirani način včasih ne spremeni prav ničesar. Vsebnik se zažene, tunel še vedno ne uspe, in prava napaka nikoli ni bila glede dovoljenj. Podpora jedra je tretji primer in najlažje napačno prebran. Modula, ki ni naložen na gostitelju, ni mogoče naložiti iz notranjosti neprivilegiranega vsebnika, in podelitev več zmogljivosti znotraj vsebnika ne spremeni stanja gostitelja.

Preverite zahtevo, ne simptoma

Začnite z najmanjšim klicem, ki ga dokumentira slika, ga zaženite in shranite natančno besedilo neuspeha. Nato dodajte eno odobritev naenkrat in zabeležite, kateri dodatek je spremenil 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

Vsebnik, ki napravo vidi in ima zmogljivost, a vseeno ne uspe, vam pove, da je težava drugje. To je koristen rezultat, in privilegirani način bi ga skril.

Preverite tudi dovoljenja naprave na gostitelju, ker pravilno podeljeno vozlišče naprave z napačnim lastništvom skupine povzroči enako napako kot manjkajoča odobritev.

Zapišite najožjo odobritev, ki deluje

Zapišite vsako napravo in zmogljivost, ki ju namestitev potrebuje, skupaj z napako, ki ju je upravičila. Prav ta zapis omogoča naslednji osebi, da nekaj varno odstrani, in prav tega bo zahteval revizor, ko bo vsebnik prijavljen kot privilegiran.

Preglejte tudi okoliški kontekst, ker lahko gostiteljsko omrežje, priklopi gostitelja in možnosti izvajalnega okolja vsak razširijo vpliv odobritve. Izoliran laboratorijski klic, ki vse to združuje, ni produkcijska konfiguracija, ne glede na to, kako dobro je deloval. Preizkusite aplikacijo, njeno vedenje v DNS in neuspeh tunela, preden namestitev razglasite za dokončano. Dovoljenje za ustvarjanje vmesnika ni izhodna politika, in vsebnik, ki zna popolno tunelirati, še vedno usmerja vse, kar aplikacija pošlje.