Názory k článku Sandboxing se systemd: zesílení ochrany služeb pomocí namespaces
-
Naopak tohle řešení mi připadá systémově lepší, řeší se na nižší úrovni a oproti kontejnerům bude mít parně menší overhead a vyšší výkonnost.
Pro větší prostředí je správa stejná jako pro cokoliv jiného - v playbooku budou předem připravená pravidla.
Bohužel poslední dobou často vídám přístup, kdy se vše spouští v dockeru a víc se bezpečnost neřeší, protože to už je přece vše od sebe oddělené :-(
-
Ne to nebude, overhead bude uplne stejnej ale navic si budete muset resit po vlastni ose spravu a mgmt tech namespacu, cgroup, pripadne selinuxovejch kontextu a to fakt nechcete. Jedina nevyhoda kontejneru je jejich image, overhead s nema spojenej pri startu a jejich mgmt a tam uznavam ze treba vladtni sprava prinasi dalsi level komplexity. Nicmene muj pocit z tohoto reseni je, proc to delat jednoduse, kdyz to jde i slozite. Ale proti gustu... :)
-
Filip JirsákStříbrný podporovatelAle někdo provozuje i ten jeden dva systémy a nepotřebuje si do nich tahat kanóny vhodné pro tisíc instalací.
-
Vsak jsem taky psal, ze pro jeden dva systemy/aplikace to chapu. Nicmene reseni pro mgmt kontejneru je spousta a nemyslim si, ze pouziti treba dockeru nebo podmana je nejaka raketova veda. Naopak i pro par instanci je to vcelku pohoda, spis mi prijde jako cirej masochismus to delat v 21 stoleti rucne. Ale jak pisu, proti gustu zadnej disputat.
-
pro větší prostředí je to nepodstatné, náklady na automatizaci se rozloží daleko lépe. Doba, kdy se vše udržovalo ručně je pryč.
U konteinerů nemám snadnou možnost jak jednotlivá oprávnění granulovat pro různé aplikace. Zvyšuje to výrazně pak komplexitu, kdy musím provozovat ještě další nástroj nad to. Containerový systémy neřeší skoro vůbec závislosti služeb navzájem a události, kdy která služba může startovat (ne, k8s nechci prozovat na jednom serveru).
-
> pro větší prostředí je to nepodstatné, náklady na automatizaci se rozloží daleko lépe. Doba, kdy se vše udržovalo ručně je pryč.
Musite ale mit i v ramci automatizace nejakou logiku ktera Vam dela spravu ns pripadne dalsich veci jako cgroupy apod (pokud to chcete).
> U konteinerů nemám snadnou možnost jak jednotlivá oprávnění granulovat pro různé aplikace.
priznam se ze tenhle argument moc nechapu. Kontejner = samdbox. Co potrebujete vic ?
> Containerový systémy neřeší skoro vůbec závislosti služeb navzájem a události, kdy která služba může startovat
ok s tim souhlas.
-
Systemd přece dělá sám správu ns a cgroup. Mně z pohledu infrastruktury je asi jedno, jestli budu generovat service.unit nebo servise.compose. Větší infrastrukturu je čímdál složitější spravovat bez automatizace.
Podívej se na článek, pod kterým diskutujeme, např. kapitola "Prohlídka konkrétní služby" a features, které tam jsou, o tom mluvím. Tohle stejně potřebuje nastavovat u konteinerů. Nelze prostě jít a vše spustit do rootem v kontaineru.
-
> Tohle stejně potřebuje nastavovat u konteinerů. Nelze prostě jít a vše spustit do rootem v kontaineru.
s tim souhlas, nicmene imho bude automatizovane prehlednejsi spravovat kontejnery nez systemd. A to co autor clanku tady vytvari je v podstate kontejner, jen tomu tak nerika :).
Ale ok, pokud Vam prijde snazsi spravovat ns pres systemd, pak se proti tomu neda asi nic namitnout :)
-
:) Dobrej dotaz, asi bych ji mel ulozenou v nakym yamlu jako manifest, pripadne bych tuto konfiguraci vubec neresil a nechal ji na defaultnich hodnotach danyho nastroje nebo jeho politik. Uznavam, ze jsem hodne ovlivnen filosofii k8s.
Jen sem chtel poukazat na to, ze autor dela v podstate kontejner rucne a mozna by stalo za to popremyslet, jestli nejit nejakou standartni cestou nez se pachtit se systemd.
-
Filip JirsákStříbrný podporovatel
Kontejner má tu nevýhodu, že pro něj potřebujete obraz. Pokud už máte aplikaci v systému a potřebujete ji jenom spustit, je jednodušší ta omezení nastavit pomocí systemd než kvůli tomu vyrábět celý image. Když tu aplikaci chcete spustit rovnou a ne jako službu, použijete
systemd-nspwan. Takže máte všechny možnosti, jaké vám pro oddělení procesů dávají kontejnerové technologie, jenom nepotřebujete ty obrazy. -
To zalezi na tom jak to prostredi vypada, pokud budete potrebovat treba vice verzi a ruznych instanci jedne aplikace pak se vam imho kontejnery uz vyplati. Jinak ano, image ma svuj overhead pri startu, ale zase jste schopen tu aplikaci rychle a bezpecne spustit, nezavisle na ostatnich
21. 1. 2022, 15:48 editováno autorem komentáře
-
Filip JirsákStříbrný podporovatel
Aplikacím se samozřejmě ponechávají oprávnění, která potřebují, takže se neočekávaně chovat nebudou.
Výpis modifikovaných systémových jednotek získáte tak, že si vypíšete obsah adresáře
/etc/systemd/system. -
Dobrý den všem.
Děkuji Vám Petře za článek. Je to velmi zajímavé téma.
Rozhodně by se mi líbila celá řada, nebo lépe série článků s tímto tématem.
Například na serverech (ale i stanicích) provozujeme celkem stálou, řeknu základní řadu služeb a líbil by se mi rozbor nastavení, případné praktické tipy, či okolnosti, jak je pomocí tohoto nástroje nastavit bezpečněji.
Mám na mysli namátkou ntp, ssh, ifup, ale zajímaly by mne i další, pokročilejší služby, jako jsou exim, postfix, zabbix, apache, open-vm-tools, apod. Těmi by jistě nebylo špatné se také podrobněji zabývat.
Pak by se nabízelo postup nějak seskriptovat, aby šel aplikovat či exportovat, zálohovat, případně alespoň zaznamenat.21. 1. 2022, 14:47 editováno autorem komentáře
-
Zajímavý článek. Ale píše mi to:
# systemd-analyze security
Unknown operation 'security'.# systemd-analyze --version
systemd 219
+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD +IDNcentos 7 na VMware
Poradíte ? -
Filip JirsákStříbrný podporovatel
Máte starou verzi systemd – v článku je napsáno, že je to podporováno až od verze 240. Nejlepší bude přejít na novější verzi CentOS – vaše verze 7 už přes rok nedostává plné aktualizace, jenom maintenance updaty.
24. 1. 2022, 09:48 editováno autorem komentáře
-
Filip JirsákStříbrný podporovatel
Nejnovější varianta je CentOS Stream 9, který rozhodně má novější systemd i ostatní software.
-
Filip JirsákStříbrný podporovatel
Ne, stabilita určitě nižší není. Nesmysl to není, pokud má někdo problém s tím, že má starý systemd a má ho starý kvůli tomu, že používá CentOS 7, který už je za zenitem, je nejlepší řešení přejít na podporovaný CentOS Stream 8 nebo 9.
-
Stabilita určitě nižší není? Jakým zázrakem, když jsou tam nejnovější verze všeho, což automaticky znamená kratší testování a méně času na opravování chyb (které vždy v novém kódu jsou)?
A proč když by CentOS Stream byl tak úžasně stabilní ho RedHat nedodává platícím zákazníkům?
Stále mě nepřestává udivovat jak moc pomýlené názory se dají najít v diskusích na internetu...
-
Filip JirsákStříbrný podporovatel
Jakým zázrakem, když jsou tam nejnovější verze všeho, což automaticky znamená kratší testování a méně času na opravování chyb (které vždy v novém kódu jsou)?
K testování a opravě chyb dochází ještě před tím, než se programy dostanou do CentOS Stream.A proč když by CentOS Stream byl tak úžasně stabilní ho RedHat nedodává platícím zákazníkům?
Vždyť jim ho prakticky dodává. RHEL vzniká z CentOS Stream. Co je CentOS Stream a jaký má vztah k RHELu si můžete přečíst např. v článku Odpovědi na nejčastější otázky kolem CentOS Stream: co se přesně děje?Stále mě nepřestává udivovat jak moc pomýlené názory se dají najít v diskusích na internetu...
To není dobré, když vás udivují vaše vlastní komentáře. -
K testování a opravě chyb dochází ještě před tím, než se programy dostanou do CentOS Stream.
Ano, k nějakému testování dochází ještě před tím, než se programy dostanou do CentOS Stream. Ale plně otestované (a zpřístupněné včetně podpory platícím zákazníkům RHEL) je vše až mnohem později. To je naprosto zásadní rozdíl mezi starým CentOS (kde postup byl kompletní testování -> RHEL -> CentOS) a novým CentOS Stream (kde je postup částečné testování -> CentOS Stream -> dotestování -> RHEL).
A proč když by CentOS Stream byl tak úžasně stabilní ho RedHat nedodává platícím zákazníkům?
Vždyť jim ho prakticky dodává. RHEL vzniká z CentOS Stream.Toto je velmi nestandardní použití slova prakticky. RHEL vzniká z CentOS Stream další stabilizací (testy+opravy) což je hlavní důvod proč není možné o CentOS Stream tvrdit "stabilita určitě nižší není."
Co je CentOS Stream a jaký má vztah k RHELu si můžete přečíst např. v článku Odpovědi na nejčastější otázky kolem CentOS Stream: co se přesně děje?
Není důvod znovu procházet celý dlouhý článek - výstižnější je citace autora z diskuse: CS9 je teď taková RHEL 9 beta s aktualizacemi. CS9 je myšleno CentOS Stream 9, což je to co jste doporučoval jako náhradu za stabilní CentOS 7 - a to je z mého pohledu naprosto nesmyslné doporučení.
-
Filip JirsákStříbrný podporovatel
Kdybyste si ten článek přeci jen přečetl, nepsal byste pak třeba do diskuse takové pomýlené názory. Když chcete stabilitu a nechcete za ni platit, pořád můžete používat CentOS Stream 8, kde máte prakticky to samé, jako je v RHEL 8. Nevím, proč by si RedHat podle vás komplikoval práci a část testování si nechával až před RHEL. Aktuální náhradou za CentOS 7 je stabilní CentOS Stream 8.
-
Podle changelogu k systemd je volba security k dispozici od verze 240:
systemd-analyze also gained a new verb "security" for analyzing the security and sand-boxing settings.
ČLÁNKY DO MAILU