NET_ADMIN u VPN kontejneru: što može promijeniti i gdje

Ova mogućnost dozvoljava promjene interfejsa, ruta i firewall-a unutar jednog mrežnog imenskog prostora. Uz host mrežu, taj prostor je vlastiti stek hosta.

NET_ADMIN je Linux mogućnost koja procesu omogućava obavljanje mrežne administracije, a u kontejneru radi upravo to unutar onog mrežnog imenskog prostora u kojem proces radi. To nije licenca za otvaranje socketa i nije zamjena za uređaj ili rutu. Zanimljivo pitanje nikada nije da li je mogućnost dodijeljena, nego koji imenski prostor prima promjenu.

Šta mogućnost pokriva

Unutar svog imenskog prostora proces koji drži NET_ADMIN može podizati i spuštati interfejse, dodjeljivati adrese, dodavati i uklanjati rute i pisati firewall pravila, što je grupa operacija koje capabilities(7) skuplja pod ovom mogućnošću. Može i podešavati postavke na nivou interfejsa koje kontrolišu kako jezgro stavlja saobraćaj u red i filtrira ga. VPN klijent obično treba nekoliko njih pri pokretanju i ništa drugo poslije. Zato većina image-a traži veći doseg nego što koristi.

Operacije izvan tog imenskog prostora nisu pokrivene, a susjedne privilegije su odvojene. Čitanje i pisanje sirovih paketa pripada NET_RAW, a pravljenje tun uređaja traži i mogućnost i pristup čvoru uređaja. Proces bez uređaja dobija grešku dozvole koja izgleda kao mrežni problem, a nije.

Imenski prostor određuje radijus štete

Kontejner na vlastitoj bridge mreži doseže svoj loopback, svoje interfejse i svoju routing tabelu. Dodjela NET_ADMIN tamo omogućava VPN klijentu da izgradi tunel bez diranja routing odluka hosta, što je raspored koji većina kontejnerskih image-a pretpostavlja.

Prebacite taj kontejner na host mrežu i ista dozvola sada mijenja rute hosta i firewall hosta, jer nije ostao odvojen imenski prostor. Klijent koji je trebao upravljati jednim tunelom tada može preusmjeriti saobraćaj cijele mašine, a greška u njegovoj teardown skripti ostavlja hostu pravila koja niko nije napisao. Ništa se u samoj mogućnosti nije promijenilo; promijenio se kontekst. Zato se isti compose fajl ponaša drugačije na dva hosta.

Tri preduslova koji se stapaju u jedan

Greške pri pokretanju VPN kontejnera obično uključuju jednu od tri odvojene stvari: mogućnost, tunel uređaj i podršku jezgra za protokol. Dodjela sva tri odjednom radi, i isto tako čini sljedeću grešku nemogućom za pripisivanje. Minimalni compose fragment dodjeljuje mogućnost i eksplicitno prosljeđuje čvor uređaja:

services:
  vpn:
    image: example/vpn-client:latest
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun
    sysctls:
      - net.ipv4.conf.all.src_valid_mark=1

Pročitajte vlastitu dokumentaciju image-a o tome koji su sysctl potrebni, jer sysctl u kontejneru može zahtijevati dodatnu privilegiju ili postavku na nivou hosta. Gdje image podržava režim samo u korisničkom prostoru, uređaj uopšte nije potreban i lista mogućnosti se shodno smanjuje.

Dodijelite usku operaciju, ne režim

Privilegovani režim predaje svaku mogućnost i istovremeno širi pristup uređajima, pa skriva koji je od tri preduslova nedostajao. On takođe čini načine kvara kontejnera nerazlučivim od promjena hosta. Radije koristite eksplicitnu listu čak i kad je duže pisati.

Rootless i korisnički imenski prostori mijenjaju šta mogućnost znači u praksi, jer je proces može držati samo unutar mapiranog imenskog prostora. Kopiranje liste mogućnosti iz rootful primjera u rootless runtime i očekivanje istog dosega čest je način da izgubite poslijepodne.

Tajne pripadaju odvojenoj odluci. Držanje NET_ADMIN ne govori ništa o tome koji identitet partnera klijent predstavlja, koje akreditive učitava niti kako se rotiraju. Mrežna administracija ne daje povjerenje.

Provjerite promjenu i zapišite zašto dozvola postoji

Potvrdite šta je kontejner zaista dobio prije nego što debagujete tunel. Inspekcija ispod navodi dodane mogućnosti i mrežni režim, a zatim pokazuje kako lista interfejsa izgleda iznutra:

docker inspect --format '{{.HostConfig.CapAdd}} {{.HostConfig.NetworkMode}} {{.HostConfig.Privileged}}' vpn
docker exec vpn sh -c 'grep CapEff /proc/self/status'
docker exec vpn ip -br addr
docker exec vpn ip route

Ako je mogućnost prisutna, a lista interfejsa je i dalje prazna, klijent je pao prije nego što je mogao išta stvoriti, a sljedeće mjesto za gledanje su logovi kontejnera. Ako tunel postoji ali saobraćaj ne teče, routing tabela unutar kontejnera odgovara na sljedeće pitanje.

Testirajte i put teardown-a, jer klijent koji piše firewall pravila može ih ostaviti za sobom. Zaustavite kontejner i ponovo provjerite skup pravila hosta ako se koristi host mreža. Dozvola potrebna samo dvije sekunde pri pokretanju ne bi trebala biti opisana u compose fajlu kao trajni zahtjev bez napomene koja to objašnjava.

Zapišite razlog pored svake mogućnosti: koja operacija ju je tražila i šta bez nje ne radi. Ta napomena preživljava ažuriranja image-a i ona je razlika između pregledane liste privilegija i one koja je narasla kopiranjem i lijepljenjem.

Povezani članci