De ce modul privilegiat este mai larg decât are nevoie un VPN

Containerul nu voia să își deschidă tunelul, așa că s-a adăugat fanionul privilegiat, iar acum funcționează. Acea secvență a stabilit doar că lipsea cel puțin o permisiune, și nu spune nimic despre care. Modul privilegiat acordă un set de capabilități și acces la dispozitive mult mai larg decât are nevoie o interfață de tunel.

Ce schimbă de fapt fanionul

Un container privilegiat primește capabilități largi și acces la dispozitivele gazdei, ceea ce este o acordare mult mai mare decât cere calea de rețea. Setul exact este documentat de mediul de execuție și nu stabilit de tradiție, iar documentația Docker despre rularea containerelor descrie opțiunile de privilegiu disponibile. O singură citire este suficientă pentru a vedea că tunelul este o parte mică din total.

Două cerințe mai înguste acoperă majoritatea containerelor VPN. Configurarea unei interfețe necesită capabilitatea de administrare a rețelei, iar deschiderea dispozitivului de tunel necesită acces la exact acel nod de dispozitiv. Acestea sunt acordări separate, iar chiar ambele împreună sunt mai înguste decât opțiunea generală. Restul setului privilegiat nu are nicio legătură cu tunelul. Există pentru sarcini de lucru care au într-adevăr nevoie de acces la nivel de gazdă, iar un container VPN de obicei nu este unul dintre ele.

Asociați fiecare eroare cu o singură condiție prealabilă

Mesajul de eroare vă spune care condiție prealabilă lipsește dacă îl citiți înainte de a-l suprima. Un mesaj despre un nod de dispozitiv numește dispozitivul, un mesaj despre o operație nepermisă numește o capabilitate, iar un mesaj despre un modul sau un sysctl numește suportul kernelului. Fiecare dintre ele are o remediere diferită, și doar unul dintre ele este o capabilitate.

Un fișier de configurare lipsă rămâne lipsă după ce toate capabilitățile sunt acordate, motiv pentru care modul privilegiat uneori nu schimbă absolut nimic. Containerul pornește, tunelul eșuează în continuare, iar eroarea reală nu a fost niciodată despre permisiuni. Suportul kernelului este al treilea caz și cel mai ușor de citit greșit. Un modul care nu este încărcat pe gazdă nu poate fi încărcat din interiorul unui container neprivilegiat, iar acordarea mai multor capabilități în interiorul containerului nu schimbă starea gazdei.

Verificați cerința, nu simptomul

Începeți cu invocarea minimă pe care o documentează imaginea, rulați-o și păstrați textul exact al eșecului. Apoi adăugați o acordare pe rând și notați care adăugare a schimbat rezultatul.

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

Un container care vede dispozitivul și deține capabilitatea dar tot eșuează vă spune că problema este în altă parte. Acesta este un rezultat util, iar modul privilegiat l-ar fi ascuns.

Verificați și permisiunile dispozitivului pe gazdă, deoarece un nod de dispozitiv acordat corect cu proprietatea de grup greșită produce aceeași eroare ca o acordare lipsă.

Notați cea mai îngustă acordare care funcționează

Notați fiecare dispozitiv și capabilitate de care are nevoie implementarea, împreună cu eroarea care le-a justificat. Această evidență este cea care îi permite următoarei persoane să elimine ceva în siguranță, și ea este ce va cere un auditor atunci când un container este raportat ca privilegiat.

Revedeți și contextul din jur, deoarece rețeaua gazdei, montările gazdei și opțiunile mediului de execuție pot fiecare lărgi impactul unei acordări. O invocare izolată de laborator care le combină pe toate nu este o configurație de producție, oricât de bine ar fi funcționat. Testați aplicația, comportamentul ei DNS și un eșec de tunel înainte de a declara implementarea terminată. Permisiunea de a crea o interfață nu este o politică de ieșire, iar un container care poate tunela perfect direcționează în continuare tot ce trimite aplicația.