Zašto je privilegovani režim širi nego što VPN-u treba

Kontejner nije htio otvoriti svoj tunel, pa je dodana privilegovana zastavica i sada radi. Taj slijed je utvrdio samo da je nedostajalo barem jedno dopuštenje i ništa ne govori o tome koje. Privilegovani režim daje skup mogućnosti i pristup uređajima mnogo širi nego što je potrebno mrežnom interfejsu tunela.

Šta zastavica zapravo mijenja

Privilegovani kontejner dobija široke mogućnosti i pristup uređajima domaćina, što je mnogo veće dopuštenje nego što zahtijeva mrežni put. Tačan skup dokumentuje vrijeme izvršavanja, a ne određuje predanje, i Docker dokumentacija o pokretanju kontejnera opisuje dostupne opcije privilegija. Jedno čitanje je dovoljno da se vidi da je tuneliranje mali dio ukupnog.

Dva uža zahtjeva pokrivaju većinu VPN kontejnera. Konfigurisanje interfejsa zahtijeva mogućnost administracije mreže, a otvaranje tunelskog uređaja zahtijeva pristup tom konkretnom čvoru uređaja. To su odvojena dopuštenja, a i oba zajedno su uža od sveobuhvatne opcije. Ostatak privilegovanog skupa nema nikakve veze s tunelom. On postoji za radna opterećenja koja zaista trebaju pristup na nivou domaćina, a VPN kontejner obično nije jedno od njih.

Uparite svaku grešku s jednim preduslovom

Poruka o grešci vam kaže koji preduslov nedostaje ako je pročitate prije nego što je ugušite. Poruka o čvoru uređaja imenuje uređaj, poruka o operaciji koja nije dopuštena imenuje mogućnost, a poruka o modulu ili sysctl imenuje podršku jezgra. Svaka od njih ima drugačije rješenje, a samo je jedna od njih mogućnost.

Nedostajuća konfiguracijska datoteka ostaje nedostajuća nakon što se dodijele sve mogućnosti, zbog čega privilegovani režim ponekad ne mijenja baš ništa. Kontejner se pokreće, tunel i dalje ne uspijeva, a prava greška nikada nije bila o dopuštenjima. Podrška jezgra je treći slučaj i najlakše se pogrešno pročita. Modul koji nije učitan na domaćinu ne može se učitati iz neprivilegovanog kontejnera, a davanje više mogućnosti unutar kontejnera ne mijenja stanje domaćina.

Provjerite zahtjev, a ne simptom

Počnite od minimalnog poziva koji slika dokumentuje, pokrenite ga i sačuvajte tačan tekst greške. Zatim dodajte jedno dopuštenje po jedno i zabilježite koje je dodavanje promijenilo 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

Kontejner koji vidi uređaj i ima mogućnost, ali ipak ne uspijeva, govori vam da je problem negdje drugdje. To je koristan rezultat, a privilegovani režim bi ga sakrio.

Provjerite i dopuštenja uređaja na domaćinu, jer ispravno dodijeljen čvor uređaja s pogrešnim vlasništvom grupe daje istu grešku kao nedostajuće dopuštenje.

Zabilježite najuže dopuštenje koje radi

Zapišite svaki uređaj i mogućnost koji su potrebni za postavljanje, uz grešku koja ih je opravdala. Taj zapis omogućava sljedećoj osobi da nešto sigurno ukloni, i to je ono što će revizor tražiti kada se kontejner prijavi kao privilegovan.

Pregledajte i okolni kontekst, jer mreža domaćina, montaže domaćina i opcije vremena izvršavanja mogu svaki proširiti učinak dodijeljenog dopuštenja. Izolirani laboratorijski poziv koji sve to kombinuje nije proizvodna konfiguracija, koliko god dobro radio. Testirajte aplikaciju, njeno ponašanje u DNS-u i neuspjeh tunela prije nego što postavljanje proglasite završenim. Dopuštenje za stvaranje interfejsa nije politika izlaza, a kontejner koji savršeno tunelira i dalje usmjerava sve što aplikacija pošalje.