Előrebocsátom: semmi offense, csak hitvallás, nem ismerem a cloudlinuxot btw.
Lássuk... Konténer.. különben pofára egy az egyben a JAIL FreeBSD alatt, szóval az sem kizárt, hogy onnan jött az ötlet, mert JAIL elég régóta van, sőt talán találkoztam is egy cikkel ami azt taglalja valahol, hogy a FreeBSD JAIL-ből számrazik a konténer explicit módon, majd megkeresem, így ilyen értelemben már támadható, hogy rossz választás lenne a BSD.
Én most abból indulok ki, hogy biztonságos legyen egy osztott tárhely, védem a PHP -val és védem fájlrendszer jogokkal (POSIX), nincs még chroot sem, csak annyi, hogy minden tárhely kap egy unique user -t, (ezt anno linuxon MPM_ITK -val oldottam meg, itt POSIX userekkel), a webtárhely mappája olvasható/írható csak user által és olvasható a WWW -vel, a PHP user-el fut és a group NEM www.
Az összes rendszerfájl és tanúsítvány és mappa és a logok minden el van szeparálva és egy normál user nem tud hozzáférni (ellenben a legtöbb tárhelykezelővel).
A rendszer figyel és javítja a jogokat, "ismerjük ugye a chmod 755: problem solved" mechanizmust.. Ez egyszerű mint a faék és működik jól kb. 1992 óta.
Konténer: relatíve friss és egy borzasztó bonyolúlt dolog, alapból van privileged és unprivileged konténer, a kettő között a különbség az, hogy a privileged konténerből lehet piszkálni a kernelt az unprivileged konténerből meg nehezebben. Na most itt jön egy kis hitvallás is, tehát az alábbiakat szokták elkövetni:
1. szarok a biztonságra mert úgy is konténerből csinálok mindent, tehát mindent a konténerre bízunk. Csak, hogy sűrűn kilehet exploitolni rootba velük és hello world!
2. szarok a biztonságra mert van konténerem, valami nyígja van az usernek a python scripjével, stackoverflowról random/vakon bemásolgatom a kódokat rootként és problem megoldva, és máris lett egy unprivileged konténer.
3. foglalkozok a biztonsággal és konténert használok, így biztosítom a legjobb védelmet a teljesítmény rovására. <- helyes út.
Auto-deploy, nodejs, composer, DevOPS, és társai, itt a közös az, hogy egy nagyon összetett és gyorsan fejlődő valamiről van szó akár csak a DevOPS szócskát nézve és ember legyen a talpán aki követi a változásokat, ergó: rábízzuk sokszor magunkat a scriptekre, amik az internetről töltenek le random dolgokat és updatelnek és fogalmunk sincs mi a lószar van, de bízunk benne.
Én meg pont ettől riadok meg, ha éles szerveren nekem önnáló életet élnek a szoftverek, vagy egyik napról a másikra változik valami és lekell követni az összes konténerre.
Különben chroot és konténer ide-oda, a levelezés és adatbázis nem lesz elszeparálva így megette a fene, pont a kettő legfontosabb.
Nem mondom, hogy a konténer szar, azt se, hogy az a helyes amit az én hitem diktál, alapvetően a probléma az, hogy tudás nélkül veszélyes bármi ami production és kint van a neten, a konténer és a linux manapság annyira divatcikk lett, hogy minden boldog boldogtalan nyomkodja, de még fejleszt is hozzá, ami rendben van, csak valahogy ez már nyomonkövethetetlen megtanulhatatlan katyvasz ahol nincs időnk se energiánk kitanulni, de még is ezzel fejlesztünk és ezt használjuk és ott hagyjuk a biztonsági réseket, melyek jócskán szaporodnak.
Én akkor vagyok boldog ha a lehető legkevesebb szoftver van feltelepítve, az is kézzel fordítva biztonságos forrásból a FreeBSD ezt garantálja, abban a pillanatban, hogy tutorialt kell nézni és hozzákell adni a sources.list -hez valamit, nem biztonságos, hacsak nem a komplett rendszer jön onnan amit én választok pl: ProxMox.
Scripteket utálom, van belőlük 120.000 elég egyet találni ami "véletlenül" írható és átírni és lehet máris rootal rohangálni.
Ha én most a konténerekhez értenék a legjobban, biztosan azzal nyomulnék, de nem értek hozzájuk, legalább is olyan szinten nem mint az egyszerű rég működő dolgohoz, amire van C API és script se kell.
Így én itt megtámadom azt a pontot, hogy a FreeBSD rossz választás mert a konténerben van a jövő, valakiknek biztosan én konzervatív lettem az idők során, rengeteg szervert üzemeltetek és egyszerűen nem volt probléma FreeBSD -vel, nyilván ehhez az is hozzájárul, hogy kevesebb számban van jelen és egy picivel jobban kell hozzá érteni.
A másik: amelyik rendszer engedi, hogy hibázz ott lehet is, ezért sem szeretem a permisszív programnyelveket pl: PHP, bár PHP mesterien megy, de mai napig belefutok a "shadow variable" dologba: pl:
foreach($tmp as $k=>$v)
{
blablablabla
$tmp = $i + 1; <- és máris felülírtam a $tmp -t, pici figyelmetlenség, de nem biztos, hogy kiderül, happy debugging része.
}
Az ilyenekből is vannak CVE -k és ha rákeresel, hogy Docker breakout, Container escape, Jailbreak Exploit akkor láthatod, hogy van abból is bőven.
Tehát biztos védelmet a mai világban SEMMI NEM AD, csak meg lehet nehezíteni ha olyan rendszert használsz ami "egyedi" vagy arra alapozol, hogy kevesebb az esélye annak, hogy a PHP és a konténer is egyszerre legyen sebezhető, mindenesetre ez: "mivel a konténer a jövő (és már a jelen is) biztonság szempontjából." már is transzlogikus, hiszen a konténer csak egy plussz sebezhetőség és nem néztük a függőségeket, mindenesetre
"Ja, és persze ha úgy döntenék hogy a usereknek PHP-n kivül mást is adok, az is a konténerben lesz" ez nekem máris hasonlít arra az opcióra, hogy IDC I HAVE CONTAINER whatever.
Konténernek is van overheadje, nem annyi mint egy KVM, de van.
Nem feltétlenül működik minden a konténer alatt, és vannak dolgok amik kifejezetten instabilak tehát sajnos nem minden esetben lehet őket használni.
EPOLL például kernel syscall amit linuxon használ az NGINX is, a konténer ha nem engedi akkor lassú lesz, ha engedi akkor máris a kernelt túrjuk vele, ha ez technikailag le van választva a kernelben (nem tudom), akkor már is csak egy POLL() -t kapunk sebességben ha nem rosszabbat, így alacsonyan nézve a dolgokat, legalább 3-12% -os overheadre tippelek, ami nem egy borzasztó dolog.
Az elmúlt években sokszor kellett 8ms válaszidő alá vinni oldalakat, mert ezt kívánták SEO szempontjából vagy realtime API miatt, azt biztosan nem tudnám adni konténer alól.