"Je zvykem, že webový server běží s právy roota."
Ehm, fakt? A to je zvykem kde? Mně tedy HTTP servery běží pod zvláštními uživateli a pod rootem ledatak startují a zahajují poslech na privilegovaných portech. Nenapadlo mě, že to někdo vážně na produkčních prostředích prasí jinak. S takovou by mi musely pod rootem běhat tři čtvrtiny služeb. Jenže to bych asi musel nejdříve zešílet.
Tiez nejak nechapem v com je to toto riesenie "bezpecnejsie".
pod rootom bezi len prvy proces Nginx tie co pracuju z okolim uz pod inim uzivatelom. (Standard od prvej verzie Nginx co bola pouzitelna)
Takto len spravime konfiguraciu ktora na inich unix-like systemoch nepojde. A vyrobime si problemy ktore by sme standardne nemuseli riesit (pidfile, pristup k certifikatom, portom)
Vyhoda je ze uz od zaciatku spustas sluzbu iba s takymi pravami ake potrebuje. Cize napriklad keby ti niekto podstrcil inu binarku alebo koli zlej konfiguracii alebo z ineho dovodu by nginx nezmenil toho pouzivatela tak system garantuje ze bude stale sluzba spustena len s pravami ake potrebuje. Keby sa napriklad v nginx objavila zranitelnost v casti kodu ktora sa vykonava este pod pravami roota (napriklad pri otvarani portov) tak opat tym zabranis niekomu zneuzit sluzbu k eskalacii prav.
Tiez je to vyhoda z pohladu manazmentu nastaveni. Je tym explicitne priamo definovane ze sluzba ma bezat s takymi a takymi pravami. Nemusis byt odbornik na nginx aby si videl ze sluzba sa spusta s nejakymi obmedzeniami a otvaranie privilegovanych portov ma vyslovene dovolene. To sa hodi zvlast ked sprava systemu a prava sluzby je v rukach samostatnej skupiny ludi.
Vseobecne si myslim, ze clanok sa prilis zameriava na toho non-root pouzivatela. Systemd ma kopec inych nastaveni ktore ti umoznia obmedzit prava a dosah tej konkretnej sluzby omnoho viac. Napriklad cez DevicePolicy=strict
vies obmedzit pristup k zariadeniam, vies nastavit limit na vyuzitie CPU/RAM. PrivateUsers
ti umozni spustit proces v samostatnom user namespace, takze sluzba bude mat vsetkych ostatnych pouzivatelov mapovanych na "nobody". PrivateTmp
da sluzbe privatny /tmp, co je inak pomerne casty vektor pouzivany na eskalaciu prav. Vies kompletne skryt obsah adresarov a povolit iba tie ktore aplikacia realne potrebuje aj ked samotny pouzivatel by inak mal pravo k takym adresarom pristupovat.. Tych moznosti je vela a konkretne zmena pouzivatela z root na nobody je jedna z tych co vie nginx spravit aj sam o sebe, tak to vyznie ako zbytocna vec.
To záleží na komplexnosti potřeb toho či kterého řešení. Když třeba zrovna ten nginx používáte jen jako reverzní proxy, vyrábět si na to kontejner je jednoduše zbytečně náročný overkill. Totéž platí třeba pro thttpd bez CGI a jiné službičky.
Když tam naopak máte deset děravých webů v PHP co tam provádějí radši nikdo nechce vědět co, dává to samozřejmě podstatně lepší smysl. Ale vyrábět si image pro každou drobnost je fakt zbytečně komplikované o tom, že je pak docela fajn ještě si navíc udržovat repository třeba kvůli migracím nebo o starostech se storage ani nemluvě. A to jsme se ještě nedostali k mikroserverům, kde je pár mega paměti a minimální storage.
Nedá se to tedy úplně paušálně říci. Za to lze paušálně říci, že hned ta první věta článku je nesmysl.
Jsou pro to případy užití, ale generalizovat to nejde. Taky jde o to, co považujete za kontejner. Jestli něco, co je připraveno s podobnou péčí a důrazem na bezpečnost, jako holá distribuce, nebo jestli kontejner, který stáhnete od třetí strany. Pokud od třetí strany, tak jak důvěryhodná je, jaké má nastavené procesy kvality atp.
Veškerý přínos kontejnerů bývá ve výsledku hodně diskutabilní. Nejčastěji se potkávám s tím, že to zlevní vývoj a deployment projektu, ale za cenu škod při následné správě.
Jako o bezpečnostním opatření bych o tom moc neuvažoval. Na Linuxu máte capabilities, na BSD chroot a jails. Pokud je Vás zájem zaostřen na bezpečnost, tak toto jsou ty správné nástroje. Kontejnery jsou proti tomu z hlediska bezpečnosti jen z nouze ctnost.