NET_ADMIN në një kontejner VPN: çfarë dhe ku mund të ndryshojë

NET_ADMIN është aftësia e Linux që lejon një proces të kryejë administrim rrjeti, dhe në një kontejner bën pikërisht këtë brenda hapësirës së emrave të rrjetit ku ekzekutohet procesi. Nuk është licencë për të hapur një socket dhe nuk është zëvendësim për një pajisje ose një rrugë. Pyetja interesante nuk është kurrë nëse aftësia është dhënë, por cila hapësirë emrash e merr ndryshimin.

Çfarë mbulon aftësia

Brenda hapësirës së vet të emrave, një proces që mban NET_ADMIN mund të ngrejë dhe të ulë ndërfaqe, të caktojë adresa, të shtojë dhe të heqë rrugë dhe të shkruajë rregulla firewall, që është grupi i operacioneve që capabilities(7) mbledh nën këtë aftësi. Ai gjithashtu mund të rregullojë cilësime në nivel ndërfaqeje që kontrollojnë se si kerneli i vendos trafiku në radhë dhe e filtron atë. Një klient VPN zakonisht ka nevojë për disa prej tyre në nisje dhe për asgjë tjetër më pas. Prandaj shumica e imazheve kërkojnë shtrirje më të madhe sesa përdorin.

Operacionet jashtë asaj hapësire emrash nuk mbulohen, dhe privilegjet fqinje janë të ndara. Leximi dhe shkrimi i paketave të papërpunuara i takon NET_RAW, dhe krijimi i një pajisjeje tun kërkon si aftësinë ashtu edhe aksesin te nyja e pajisjes. Një proces pa pajisjen merr një gabim leje që duket si problem rrjeti dhe nuk është.

Hapësira e emrave përcakton rrezen e dëmit

Një kontejner në rrjetin e vet të urës arrin loopback-un e vet, ndërfaqet e veta dhe tabelën e vet të rrugëtimit. Dhënia e NET_ADMIN atje i lejon klientit VPN të ndërtojë një tunel pa prekur vendimet e rrugëtimit të hostit, që është rregullimi që supozojnë shumica e imazheve të kontejnerëve.

Kalojeni atë kontejner në rrjetin e hostit dhe e njëjta dhënie tani redakton rrugët e hostit dhe firewall-in e hostit, sepse nuk ka mbetur asnjë hapësirë emrash e veçantë. Klienti që duhej të administronte një tunel të vetëm mund të ridrejtojë trafikun e të gjithë makinës, dhe një gabim në skriptin e tij të çmontimit i lë hostit rregulla që askush nuk i shkroi. Asgjë në vetë aftësinë nuk ndryshoi; ndryshoi konteksti. Prandaj i njëjti skedar compose sillet ndryshe në dy hoste.

Tre parakushte të shkrira në një

Dështimet e nisjes në kontejnerët VPN zakonisht përfshijnë një nga tre gjëra të ndara: aftësinë, pajisjen e tunelit dhe mbështetjen e kernelit për protokollin. Dhënia e të treve njëherësh funksionon, dhe gjithashtu e bën dështimin tjetër të papërkatësueshëm. Një fragment minimal compose jep aftësinë dhe kalon nyjen e pajisjes në mënyrë eksplicite:

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

Lexoni dokumentacionin e vetë imazhit për cilat sysctl ka nevojë, sepse një sysctl në një kontejner mund të kërkojë një privilegj shtesë ose një cilësim në nivel hosti. Aty ku imazhi mbështet vetëm modalitetin e hapësirës së përdoruesit, nuk nevojitet fare pajisje dhe lista e aftësive tkurret në përputhje me rrethanat.

Jepni operacionin e ngushtë, jo modalitetin

Modaliteti i privilegjuar dorëzon çdo aftësi dhe zgjeron njëkohësisht aksesin te pajisjet, kështu që fsheh cili nga tre parakushtet mungonte. Ai gjithashtu i bën mënyrat e dështimit të kontejnerit të pandashme nga ndryshimet e hostit. Preferoni një listë eksplicite edhe kur është më e gjatë për t'u shkruar.

Vendosjet rootless dhe në hapësira emrash përdoruesi ndryshojnë atë që një aftësi nënkupton në praktikë, pasi procesi mund ta mbajë atë vetëm brenda një hapësire emrash të hartuar. Kopjimi i një liste aftësish nga një shembull rootful në një mjedis rootless dhe pritja e së njëjtës shtrirje është një mënyrë e zakonshme për të humbur një pasdite.

Sekretet i takojnë një vendimi të veçantë. Mbajtja e NET_ADMIN nuk thotë asgjë për atë se çfarë identiteti partneri paraqet klienti, çfarë kredencialesh ngarkon ose si rrotullohen ato. Administrimi i rrjetit nuk ofron besim.

Verifikoni ndryshimin dhe shënoni pse ekziston dhënia

Konfirmoni çfarë ka marrë në të vërtetë kontejneri përpara se të korrigjoni tunelin. Inspektimi më poshtë raporton aftësitë e shtuara dhe modalitetin e rrjetit, pastaj tregon si duket lista e ndërfaqeve nga brenda:

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

Nëse aftësia është e pranishme dhe lista e ndërfaqeve është ende bosh, klienti ka dështuar përpara se të mund të krijonte diçka, dhe vendi tjetër për të parë janë regjistrat e kontejnerit. Nëse tuneli ekziston por trafiku nuk rrjedh, tabela e rrugëtimit brenda kontejnerit i përgjigjet pyetjes tjetër.

Provoni gjithashtu rrugën e çmontimit, sepse një klient që shkruan rregulla firewall mund t'i lërë ato pas. Ndaloni kontejnerin dhe kontrolloni përsëri grupin e rregullave të hostit nëse përdoret rrjeti i hostit. Një dhënie që nevojitet vetëm dy sekonda në nisje nuk duhet të përshkruhet në skedarin compose si kërkesë e përhershme pa një shënim që e shpjegon këtë.

Shkruani arsyen pranë çdo aftësie: cili operacion e kërkonte dhe çfarë dështon pa të. Ai shënim mbijeton përditësimet e imazhit, dhe është dallimi midis një liste privilegjesh të rishikuar dhe një liste që u rrit duke kopjuar dhe ngjitur.