Sunt sigur că ți s-a întâmplat asta: încerci să asamblezi un recipient pentru uz personal, vrei să-l faci mai sigur atunci când îl folosești containere neprivilegiate Și dintr-o dată, te trezești prins într-un labirint de erori de permisiuni. Este frustrant să petreci ore întregi configurând foldere în directorul principal al utilizatorului, doar pentru a descoperi că containerul nu poate scrie în ele sau că, atunci când o face, fișierele rezultate de pe gazdă sunt corupte. imposibil de gestionat pentru că aparțin unui utilizator fantomă.
Realitatea este că, deși containerizarea a accelerat livrarea de software, a deschis calea către riscuri considerabile. Conform datelor recente, marea majoritate a imaginilor de producție poartă [neclar - posibil „neclar” sau „neclar”] vulnerabilități criticeAcest lucru face ca securitatea să fie un pilon nenegociabil. Nu este vorba doar de a împiedica hackerii să ne atace, ci de a înțelege cum funcționează sistemul. izolarea procesului pentru ca infrastructura noastră să nu devină o sită.
Înțelegerea ecosistemului de securitate a containerelor
Pentru a nu mai ghici permisiunile, trebuie mai întâi să știm ce protejăm. Arhitectura unui container este împărțită în mai multe straturi critice. În primul rând, avem imaginea containeruluicare este planul original; dacă acesta este vulnerabil, toate instanțele pe care le implementați vor fi nesigure. De aceea este vital să utilizați imagini de bază de încredere și mențineți-le la zi.
Apoi, timp de execuțiecare acționează ca arbitru între sistemul de operare gazdă și aplicație. Dacă runtime-ul este învechit, riscul unei evadare din container crește dramatic. La aceasta trebuie să adăugăm orchestrarea, cum ar fi Kubernetes, unde controlul accesului bazat pe rol (RBAC) Este singura barieră reală împotriva accesului neautorizat la API-ul de administrare.
Nu putem uita sistem de operare gazdăDacă un atacator reușește să compromită kernelul gazdă, acesta deține cheile întregului domeniu. Recomandarea aici este clară: utilizați un sistem de operare minim pentru a reduce suprafața de atac. În cele din urmă, rețeaua este cel mai comun punct de intrare; aproape 30% din încălcări apar din cauza erorilor de conectivitate, astfel încât segmentarea rețelei și criptarea TLS/SSL Sunt obligatorii.
Durerea de cap a permisiunilor și a utilizatorului root
Problema tipică pentru pasionații este fluxul de lucru cu volumele. Creezi un folder, îl montezi și apoi, bum!, apare o eroare. acces refuzatAcest lucru se întâmplă deoarece, în mod implicit, multe containere pornesc ca root. Când încercați să forțați UID și GID la 0 Pentru a le face să se potrivească cu utilizatorul gazdă, creezi o punte periculoasă. Dacă containerul nu îți permite să configurezi aceste ID-uri, vei pierde o după-amiază încercând să-ți dai seama ce utilizator intern folosește aplicația pentru a efectua o... chown manuală.
Soluția eficientă este aplicarea principiul cel mai mic privilegiuNu ar trebui să rulezi nimic ca root decât dacă este absolut necesar. Pentru a rezolva problema fișierelor create în container pe care nu le poți șterge de pe gazdă, este esențial să configurezi Dockerfile cu următoarele instrucțiuni: USER, definind un utilizator fără privilegii înainte de pornirea aplicației.
Dacă folosești Podman, conceptul de containere fără rădăcini Este nativ și foarte util, dar necesită să înțelegeți cum sunt mapați utilizatorii gazdă la utilizatorii containerului. Pentru a preveni scăparea permisiunilor de sub control, în mod ideal, aplicația ar trebui să fie proiectată să scrie pe rute specifice și ca maparea volumului Se face luând în considerare UID-ul real al utilizatorului care lansează procesul.
Strategii pentru construirea de imagini blindate
Dacă vrei să nu mai suferi, trebuie să schimbi modul în care îți construiești imaginile. O tehnică extrem de eficientă este... construcții în mai multe etapePractic, folosești o imagine complexă cu toate instrumentele de construire pentru a genera fișierul binar, apoi copiezi doar acel fișier într-o imagine finală. extrem de ușoară.
Poți merge chiar mai departe folosind imaginea zgâriaAceasta creează un container care nu are absolut nimic: nicio shell, niciun manager de pachete, doar aplicația ta. Acest lucru face practic imposibilă executarea comenzilor rău intenționate de către un atacator dacă reușește să intre, deoarece Nu există un interpretor de comenzi disponibile.
O altă măsură de securitate este curățarea imaginii de orice fișier binar cu permisiuni. setuid sau setgidAceste permisiuni permit ca un fișier să fie executat cu privilegiile proprietarului fișierului și nu ale utilizatorului care îl lansează, ceea ce reprezintă o autostradă pentru... escaladarea privilegiilorO comandă simplă pentru a căuta și elimina acești biți în timpul construirii imaginii vă poate scuti de multe probleme.
Pericolele modului privilegiat și capacitățile Linux
Uneori, din disperarea de a nu putea rezolva o problemă de permisiuni, cădem în tentația de a folosi steagul -privilegiatUită de asta. Modul privilegiat rupe izolarea containerului și îți oferă acces complet la dispozitivele gazdei. E ca și cum ai da cheile casei tale unui străin doar pentru că nu știa cum să deschidă poarta grădinii.
În schimb, ar trebui să te joci cu Capacități LinuxDocker atribuie un set de permisiuni implicite (cum ar fi CAP_CHOWN sau CAP_NET_RAW). Dacă aplicația dvs. nu are nevoie să manipuleze rețeaua la un nivel scăzut, cea mai inteligentă abordare este eliminați capacitățile inutile și adăugați doar pe cele strict cerute de --cap-add.
Pentru cei care gestionează medii mai serioase, există plugin-uri de autorizare cum ar fi opa-docker-authz. Acestea permit interceptarea apelurilor către API-ul daemonului Docker și blocarea oricărei încercări de lansare a unui container în mod privilegiat, asigurându-se că nimeni, nici măcar din greșeală, nu lasă ușa deschisă gazdei.
Optimizarea și întreținerea mediului
Nu vă obsedați de dimensiunea imaginii de 5 MB atunci când utilizați Alpine Linux, dacă aceasta cauzează probleme de compatibilitate cu bibliotecile. Uneori, o imagine Debian puțin mai mare este preferabilă. stabilizat și cunoscut de către echipă. Ceea ce este esențial este implementarea unui scanarea vulnerabilităților Canalizare CI/CD automatizată pentru detectarea CVE-urilor înainte ca imaginea să ajungă în producție.
În ceea ce privește stocarea, aceasta împiedică aplicația să scrie în sistemul de fișiere rădăcină. Configurați sistem de fișiere doar pentru citire (rootfs) și definește volume specifice doar pentru datele care trebuie să persiste. Acest lucru nu este doar mai sigur, ci impune și o arhitectură mai curată și fără moșiefacilitând scalarea orizontală.
Pentru procesele programate, nu plasați un cron job în containerul site-ului web. Regula de aur este un proces per containerCea mai curată abordare este să folosești imaginea aplicației tale pentru a lansa un container efemer care execută sarcina și apoi se autodistruge sau să gestionezi cron-ul de pe gazdă apelând motorul containerului folosind comenzi.
Securitatea containerelor este un proces continuu care implică eliminarea accesului root, restricționarea capacităților kernelului și eliminarea instrumentelor inutile din imaginile containerelor. Prin combinarea utilizatorilor neprivilegiați cu consolidarea runtime-ului și monitorizarea constantă, se obține un mediu în care funcționalitatea nu compromite integritatea sistemului gazdă.
Scriitor pasionat despre lumea octeților și a tehnologiei în general. Îmi place să îmi împărtășesc cunoștințele prin scriere și asta voi face în acest blog, să vă arăt toate cele mai interesante lucruri despre gadgeturi, software, hardware, tendințe tehnologice și multe altele. Scopul meu este să vă ajut să navigați în lumea digitală într-un mod simplu și distractiv.