Linux LXC vs FreeBSD-fængsel

Er der bemærkelsesværdige forskelle mellem LXC (Linux-containere) og FreeBSDs fængsler med hensyn til sikkerhed, stabilitet & ydeevne?

Først se, begge tilgange ser meget ens ud.

Kommentarer

  • LXC er en ret ny teknologi, så jeg forventer bedre sikkerhed og stabilitet med fængsler. Ikke endda et gæt om ydeevne. Der er nogle kendte sikkerhedsproblemer med LXC, som f.eks. kan afhjælpes ved hjælp af selinux. Jeg kan dog personligt lide LXC.
  • @ PavelŠimerda Jeg har lige hørt om LXC i dag, men overrasket over at finde ud af, at både Heroku og sandsynligvis Google App Engine allerede bruger LXC.
  • Hvis du ' lige er stødt på LXC, skal du se på Docker, som bruger LXC under motorhjelmen: docker.io/the_whole_story
  • Docker gør n ot bruger lxc længere.
  • @nwildner det ' bruger ikke liblxc længere, men det bruger nøjagtigt de samme begreber: kernenavneområder.

Svar

Ligegyldigt hvilket fancy navn der bruges her, begge er løsninger på et specifikt problem: En bedre segregeringsløsning end klassisk Unix chroot . Virtualisering på operativsystemniveau, containere, zoner eller endda “chroot med steroider” er navne eller kommercielle titler, der definerer det samme koncept med brugerrumsseparation, men med forskellige funktioner.

Chroot blev introduceret den 18. marts 1982 , måneder før frigivelsen af 4.2 BSD , som et værktøj til at teste dets installations- og buildsystem, men i dag har det stadig sine mangler. Da det første mål med chroot kun var at tilvejebringe en newroot -sti, blev andre aspekter af systemet, der skulle isoleres eller kontrolleres, afdækket (netværk, procesvisning, I / O-gennemstrømning). Det var her, de første containere (virtualisering på brugerniveau) dukkede op.

Begge teknologier (FreeBSD Jails og LXC) gør brug af isolering af brugerrummet for at give et andet lag af sikkerhed. Denne opdeling vil sikre, at en bestemt proces kun kommunikerer med andre processer i den samme container på den samme vært, og hvis der bruges en netværksressource til at opnå “omverden” -kommunikation, vil alle blive videresendt til det tildelte interface / kanal, som denne container har.

Funktioner

FreeBSD-fængsler:

  • Betragtes som stabil teknologi, da det er en funktion i FreeBSD siden 4.0;
  • Det tager det bedste af ZFS-filsystem på det punkt, hvor du kunne klone fængsler og oprette fængselsskabeloner for nemt at implementere flere fængsler. Noget mere ZFS-galskab ;
  • Godt dokumenteret og under udvikling ;
  • Hierarkiske fængsler giver dig mulighed for at oprette fængsler inde i et fængsel (vi er nødt til at gå dybere!). Kombiner med allow.mount.zfs for at opnå mere magt, og andre variabler som children.max definerer maks. Fængsler til børn.
  • rctl (8) håndterer ressourcegrænser for fængsler (hukommelse, CPU, disk, …);
  • FreeBSD-fængsler håndterer Linux brugerområde ;
  • Netværksisolering med vnet, så hver fængsel kan have sin egen netværksstak, grænseflader, adressering og routing af tabeller;
  • nullfs for at hjælpe med at linke mapper til dem, der er placeret på den virkelige server til inde i et fængsel;
  • ezjail værktøj til at hjælpe masseudrulning og styring af fængsler;
  • Masser af kernetunables (sysctl ). security.jail.allow.* parametre begrænser handlingerne fra rodbrugeren af det fængsel.
  • Måske vil FreeBSD-fængsler udvide nogle af VPS-projektfunktionerne som live migration i en nær fremtid.
  • Der er en vis indsats for ZFS og Docker integration kører. Stadig eksperimentel.
  • FreeBSD 12 understøtter bhyve inde i et fængsel og pf inde i et fængsel, hvilket skaber yderligere isolering af disse værktøjer
  • Der er udviklet mange interessante værktøjer i de sidste år. Nogle af dem er indekseret på dette blogindlæg .
  • Alternativer: FreeBSD VPS-projekt

Linux-containere (LXC):

  • Ny “i kernel” -teknologi men godkendt af store (specielt Canonical);
  • Ikke-privilegerede containere startende fra LXC 1.0, gør et stort skridt ind i sikkerhed inde i containere;
  • UID- og GID-kortlægning inde i containere;
  • Kernens navneområder for at adskille IPC, mount, pid, netværk og brugere. Disse navneområder kan håndteres adskilt, hvor en proces, der bruger et et andet netværksnavneområde ikke nødvendigvis vil blive isoleret på andre aspekter som opbevaring;
  • Kontrolgrupper (cgroups) til at styre ressourcer og gruppere dem. CGManager er den fyr, der opnår det.
  • Apparmor / SELinux-profiler og kernefunktioner til bedre håndhævelse af kernefunktioner, der er tilgængelige med containere. Seccomp er også tilgængelig på lxc-containere til filtrering af systemopkald. Andre sikkerhedsaspekter her .
  • Live migrationsfunktionalitet udvikles. Det er virkelig svært at sige, hvornår det vil være klar til produktionsbrug, da docker / lxc bliver nødt til at håndtere pause i brugerområdet, øjebliksbillede, migrere og konsolidere – ref1 , ref2 . Live migration fungerer med grundlæggende containere (ingen gennemgang af enhed hverken komplekse netværkstjenester eller specielle lagringskonfigurationer).
  • API-bindinger for at muliggøre udvikling i python3 og 2, lua, Go, Ruby og Haskell
  • Centraliseret “Hvad er nyt” -området. Temmelig nyttigt, når du skal kontrollere, om en eller anden fejl er rettet, eller om en ny funktion blev begået. Her .
  • Et interessant alternativ kunne være lxd , der under emhætten fungerer med lxc, men den har nogle gode funktioner som en REST-API, OpenStack-integration osv.
  • En anden interessant ting er, at Ubuntu ser ud til at sende zfs som standardfilsystem til containere på 16.04 . For at holde projekterne tilpasset lancerede lxd den 2.0 version, og nogle af funktionerne er zfs relaterede .
  • Alternativer : OpenVZ , Docker
  • Docker . Bemærk her, at Docker bruger navneområder, cgroups opretter “per app” / “pr. Software” isolation Nøgleforskelle her . Mens LXC opretter containere med flere processer, reducerer Docker en container så meget som muligt til en enkelt proces og administrerer den derefter gennem Docker.
  • Bestræbelser på at integrere Docker med SELinux og reducere kapaciteter inde i en container for at gøre det mere sikkert – Docker og SELinux, Dan Walsh
  • Hvad er forskellen mellem Docker, LXD og LXC

Docker bruger ikke længere lxc. De har nu en specifik lib kaldet runc , der håndterer integrationen med lavt niveau Kernenavne og cgroups-funktioner direkte.

Ingen af teknologierne er et sikkerhedsmiddel, men begge er ret gode måder at isolere en miljø, der ikke kræver fuld virtualisering på grund af blandet operativsystemsinfrastruktur. Sikkerhed vil komme efter en masse dokumentation læsning og implementering af kernel tunables, MAC og isolationer, som disse OS-Level virt tilbyder dig.

Se også:

Kommentarer

  • Det er værd at nævne, at der ikke er nogen indsats fra lxc for at give ordentlig gæstesolation. lxd forsøger dog at give isolering som BSD-fængsler eller Solaris-zoner.
  • lxd er en " bedre oplevelse " fra LXC, hvor du placerer andre funktioner ovenpå. Det virker dog rart at citere denne lille fyr her
  • @allquixotic, du mener, hvis du bruger uændret konfiguration oprettet fra skabeloner? Sandt, men uprivilegerede (brugernes-aktiverede) containere var tilgængelige med LXC 1.x og kunne endda startes automatisk ved systemstart, forudsat at de var ejet af root (og dermed placeret på det systemomfattende sted for containere).

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *