Linux LXC vs FreeBSD jail (Română)

Există diferențe notabile între LXC (containere Linux) și închisorile FreeBSD din punct de vedere al securității, stabilității & performanță?

În primul rând uite, ambele abordări arată foarte asemănător.

Comentarii

  • LXC este o tehnologie destul de nouă, așa că m-aș aștepta la o mai bună securitate și stabilitate cu închisorile. Nu chiar și o presupunere despre performanță. Există unele probleme de securitate cunoscute cu LXC care pot fi atenuate folosind selinux, de exemplu. Îmi place personal LXC, totuși.
  • @ PavelŠimerda Tocmai am auzit de LXC astăzi, dar am fost surprins să aflu că atât Heroku, cât și probabil Google App Engine folosesc deja LXC.
  • Dacă ' tocmai v-ați lovit de LXC, ar trebui să aruncați o privire la Docker care folosește LXC sub capotă: docker.io/the_whole_story
  • Docker nu nu mai folosește lxc.
  • @nwildner nu mai ' nu mai folosește liblxc, dar folosește exact aceleași concepte: spații de nume ale nucleului.

Răspuns

Indiferent de numele elegant folosit aici, ambele sunt soluții la o problemă specifică: O soluție de segregare mai bună decât clasicul Unix chroot . Virtualizarea la nivel de sistem de operare, containere, zone sau chiar „chroot cu steroizi” sunt nume sau titluri comerciale care definesc același concept de separare a spațiului utilizatorilor, dar cu caracteristici diferite.

Chroot a fost introdus la 18 martie 1982 , cu luni înainte de lansarea 4.2 BSD , ca instrument de testare a instalării și construirii sistemului, dar astăzi are încă defectele sale. Întrucât primul obiectiv al chroot a fost doar furnizarea unei căi newroot , s-au descoperit alte aspecte ale sistemului care trebuiau izolate sau controlate (rețea, vizualizare proces, randament I / O). Aici au apărut primele containere (virtualizare la nivel de utilizator).

Ambele tehnologii (FreeBSD Jails și LXC) folosesc izolarea spațiului utilizatorului pentru a oferi un alt strat de securitate. Această compartimentare va asigura că un proces determinat va comunica numai cu alte procese din același container de pe aceeași gazdă și, dacă se utilizează orice resursă de rețea pentru a realiza o comunicare „în afara lumii”, toate vor fi redirecționate către interfața / canalul atribuit pe care acest container are.

Caracteristici

Închisori FreeBSD:

  • Este considerată o tehnologie stabilă, deoarece este o caracteristică din FreeBSD începând cu 4.0;
  • Este nevoie de cele mai bune sisteme de fișiere ZFS în punctul în care ați putea clona închisori și puteți crea șabloane de închisoare pentru a implementa cu ușurință mai multe închisori. Mai multe nebunie ZFS ;
  • Bine documentat și evoluează ;
  • închisorile ierarhice vă permit să creați închisori într-o închisoare (trebuie să aprofundăm!). Combinați cu allow.mount.zfs pentru a obține mai multă putere, iar alte variabile precum children.max definesc maximum închisorile pentru copii.
  • rctl (8) va gestiona limitele resurselor închisorilor (memorie, CPU, disc, …);
  • închisorile FreeBSD gestionează Linux userpace ;
  • Izolarea rețelei cu vnet, permițând fiecărei închisori să aibă propria stivă de rețea, interfețe, tabele de adresare și rutare;
  • nullfs pentru a ajuta la conectarea folderelor la cele aflate pe serverul real în interiorul unei închisori;
  • ezjail pentru a ajuta la implementarea în masă și la gestionarea închisorilor;
  • O mulțime de tunable ale nucleului (sysctl ). Parametrii security.jail.allow.* vor limita acțiunile utilizatorului root al închisorii respective.
  • Poate că închisorile FreeBSD vor extinde unele dintre caracteristicile proiectului VPS, cum ar fi migrație în timp real într-un viitor apropiat.
  • Există un efort de integrare ZFS și Docker alergare. Încă experimental.
  • FreeBSD 12 acceptă bhyve în interiorul unei închisori și pf în interiorul unei închisori, creând o izolare suplimentară față de aceste instrumente
  • O mulțime de instrumente interesante au fost dezvoltate în ultimii ani. Unele dintre ele sunt indexate pe această postare pe blog .
  • Alternative: Proiect FreeBSD VPS

Containere Linux (LXC):

  • Noua tehnologie „în nucleu”, dar fiind susținută de cele mari (în special Canonical);
  • Containere fără privilegii începând cu LXC 1.0, face un pas mare în securitatea în interiorul containerelor;
  • maparea UID și GID în interiorul containerelor;
  • spațiile de nume ale nucleului, pentru a face separarea IPC, montare, pid, rețea și utilizatori. Aceste spații de nume pot fi tratate într-un mod detașat, unde un proces care folosește un spațiu de nume de rețea diferit nu va fi neapărat izolat în alte aspecte, cum ar fi stocarea;
  • Controlați grupurile (grupuri c) pentru a gestiona resursele și a le grupa. CGManager este cel care a realizat acest lucru.
  • Profilurile Apparmor / SELinux și capabilitățile Kernel pentru o mai bună aplicare a caracteristicilor Kernel accesibile de către containere. Seccomp este disponibil și pe containerele lxc pentru a filtra apelurile de sistem. Alte aspecte de securitate aici .
  • Se dezvoltă funcționalitatea de migrare live. Este foarte greu de spus când va fi gata pentru producție, deoarece docker / lxc va trebui să se ocupe de întreruperea procesului spațiului utilizatorilor, instantaneu, migrare și consolidare – ref1 , ref2 . Migrarea live funcționează cu containerele de bază (fără passthrough pentru dispozitiv) nici servicii de rețea complexe sau configurații speciale de stocare).
  • Legături API pentru a permite dezvoltarea în python3 și 2, lua, Go, Ruby și Haskell
  • Zona „Ce este nou” centralizată. Destul de util ori de câte ori trebuie să verificați dacă a fost remediată o eroare sau dacă a fost comisă o nouă funcție. Aici .
  • O alternativă interesantă ar putea fi lxd , care sub capotă funcționează cu lxc, dar are câteva caracteristici frumoase, cum ar fi un API REST, integrarea OpenStack etc.
  • Un alt interesant lucru este că Ubuntu pare să livreze zfs ca sistem de fișiere implicit pentru containerele de pe 16.04 . Pentru a menține proiectele aliniate, lxd a lansat versiunea 2.0 s, iar unele dintre funcții sunt legate de zfs .
  • Alternative : OpenVZ , Docker
  • Docker . Rețineți aici că Docker folosește spații de nume, grupuri de c creând izolarea „per aplicație” / „per software” . Diferențe cheie aici . În timp ce LXC creează containere cu mai multe procese, Docker reduce un container cât mai mult posibil la un singur proces și apoi îl gestionează prin Docker.
  • Efort pentru integrarea Docker cu SELinux și reducerea capacităților în interiorul unui container pentru a-l face mai sigur – Docker și SELinux, Dan Walsh
  • Care este diferența dintre Docker, LXD și LXC

Docker nu mai folosește lxc. Acum au un lib specific numit runc care gestionează integrarea directă cu caracteristicile spațiului de nume Kernel de nivel scăzut și cgroups direct.

Nici una dintre tehnologii nu este un panaceu de securitate, dar ambele sunt modalități destul de bune de a izola un mediu care nu necesită Virtualizare completă datorită infrastructurii de sisteme de operare mixte. Securitatea va veni după o mulțime de citire a documentației și implementarea kernel tunables, MAC și a izolărilor pe care vi le oferă acele virtuți la nivel de sistem de operare.

Vezi și:

Comentarii

  • Merită menționat că, din cutie, lxc nu depune eforturi pentru a oferi o izolare adecvată a oaspeților lxd , cu toate acestea, încearcă să ofere izolare, cum ar fi închisorile BSD sau zonele Solaris.
  • lxd este o " experiență mai bună " din LXC, punând alte caracteristici deasupra acestuia. Cu toate acestea, pare frumos să-l citez pe acest tip aici
  • @allquixotic vrei să spui dacă folosești configurație neschimbată creată din șabloane? Adevărat, dar containerele fără privilegii (activate pentru userns) erau disponibile cu LXC 1.x și puteau fi chiar pornite automat la pornirea sistemului, cu condiția să fie deținute de root (și astfel localizate în locația la nivel de sistem pentru containere).

Lasă un răspuns

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *