Pse mënyra e privilegjuar është më e gjerë sesa i duhet një VPN

Kontejneri nuk po e hapte tunelin e vet, prandaj u shtua flamuri i privilegjuar, dhe tani funksionon. Ai sekuencë vërtetoi vetëm se mungonte të paktën një leje, dhe nuk thotë asgjë për atë se cilën. Mënyra e privilegjuar jep një grup aftësish dhe akses pajisjesh shumë më të gjerë sesa i duhet një ndërfaqe tuneli.

Çfarë ndryshon në të vërtetë flamuri

Një kontejner i privilegjuar merr aftësi të gjera dhe akses te pajisjet e hostit, që është një dhënie shumë më e madhe sesa kërkon rruga e rrjetit. Grupi i saktë dokumentohet nga mjedisi i ekzekutimit dhe nuk përcaktohet nga tradita, dhe dokumentacioni i Docker për ekzekutimin e kontejnerëve përshkruan opsionet e privilegjeve të disponueshme. Një lexim i vetëm mjafton për të parë se tuneli është një pjesë e vogël e totalit.

Dy kërkesa më të ngushta mbulojnë shumicën e kontejnerëve VPN. Konfigurimi i një ndërfaqeje kërkon aftësinë e administrimit të rrjetit, dhe hapja e pajisjes së tunelit kërkon akses te pikërisht ai nyje pajisjeje. Këto janë dhënie të ndara, dhe edhe të dyja bashkë janë më të ngushta sesa opsioni i përgjithshëm. Pjesa tjetër e grupit të privilegjuar nuk ka asgjë të bëjë me tunelin. Ajo ekziston për ngarkesa pune që kanë vërtet nevojë për akses në nivel hosti, dhe një kontejner VPN zakonisht nuk është një prej tyre.

Përputhni çdo gabim me një parakusht

Mesazhi i gabimit ju tregon cili parakusht mungon nëse e lexoni përpara se ta shtypni. Një mesazh për një nyje pajisjeje emërton pajisjen, një mesazh për një veprim të palejuar emërton një aftësi, dhe një mesazh për një modul ose sysctl emërton mbështetjen e kernelit. Secili prej tyre ka një rregullim të ndryshëm, dhe vetëm një prej tyre është aftësi.

Një skedar konfigurimi që mungon mbetet i mangët pasi jepen të gjitha aftësitë, prandaj mënyra e privilegjuar ndonjëherë nuk ndryshon absolutisht asgjë. Kontejneri niset, tuneli vazhdon të dështojë, dhe gabimi i vërtetë nuk kishte të bënte kurrë me lejet. Mbështetja e kernelit është rasti i tretë dhe më i lehti për t'u lexuar gabim. Një modul që nuk është i ngarkuar në host nuk mund të ngarkohet nga brenda një kontejneri të paprivilegjuar, dhe dhënia e më shumë aftësive brenda kontejnerit nuk e ndryshon gjendjen e hostit.

Kontrolloni kërkesën, jo simptomën

Filloni nga thirrja minimale që dokumenton imazhi, ekzekutoni atë, dhe mbani tekstin e saktë të dështimit. Më pas shtoni një dhënie në një herë dhe shënoni cila shtesë e ndryshoi rezultatin.

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

Një kontejner që e sheh pajisjen dhe e ka aftësinë por gjithsesi dështon ju tregon se problemi është diku tjetër. Ky është një rezultat i dobishëm, dhe mënyra e privilegjuar do ta kishte fshehur.

Kontrolloni edhe lejet e pajisjes në host, sepse një nyje pajisjeje e dhënë saktë me pronësi grupi të gabuar prodhon të njëjtin gabim si një dhënie që mungon.

Shënoni dhënien më të ngushtë që funksionon

Shënoni çdo pajisje dhe aftësi që i duhet vendosjes, bashkë me gabimin që i justifikoi. Ky regjistër është ai që i lejon personit tjetër të heqë diçka në mënyrë të sigurt, dhe është ai që do të kërkojë një auditues kur një kontejner raportohet si i privilegjuar.

Rishikoni edhe kontekstin përreth, sepse rrjeti i hostit, montimet e hostit dhe opsionet e mjedisit të ekzekutimit mund të zgjerojnë secili ndikimin e një dhënieje. Një thirrje e izoluar laboratori që i kombinon të gjitha nuk është konfigurim prodhimi, sado mirë që funksionoi. Testoni aplikacionin, sjelljen e tij në DNS dhe një dështim tuneli përpara se ta shpallni vendosjen të përfunduar. Leja për të krijuar një ndërfaqe nuk është politikë daljeje, dhe një kontejner që tunnon në mënyrë të përsosur gjithsesi rrugëton gjithçka që dërgon aplikacioni.