Stačí říct ne rootovi (v kontejnerech)

Neustále se mě ptají na různá bezpečnostní opatření používaná k řízení toho, co mohou kontejnerové procesy v systému dělat. Většinu z nich jsem popsal v předchozích článcích na Opensource.com:

• Jsou kontejnery Docker skutečně bezpečné?
• Přivedení nových funkcí zabezpečení do Dockeru
• Zabezpečení dockeru v budoucnu

Téměř všechny výše uvedené články se týkají ovládání toho, co může privilegovaný proces v systému dělat v kontejneru. Například:Jak spustím root v kontejneru a nedovolím, aby se prolomil?

Linuxové kontejnery

• Co jsou kontejnery systému Linux?
• Úvod do terminologie kontejnerů
• Stáhnout:Containers Primer
• Operátoři Kubernetes:Automatizace platformy pro orchestraci kontejnerů
• eKniha:Vzory Kubernetes pro navrhování cloudových nativních aplikací
• Co je Kubernetes?

Uživatelský jmenný prostor je o spouštění privilegovaných procesů v kontejnerech, takže pokud se prolomí, nebudou již privilegované mimo kontejner. Například v kontejneru je moje UID 0 (nula), ale mimo kontejner je moje UID 5 000. Kvůli problémům s nedostatečnou podporou souborového systému nebyl uživatelský jmenný prostor tím všelékem, jak se rozlouskl. Až do teď.

OpenShift je kontejnerová platforma společnosti Red Hat, postavená na kontejnerech Kubernetes, Red Hat Enterprise Linux a OCI a má skvělou bezpečnostní funkci:Ve výchozím nastavení není povoleno žádné kontejnery spouštět jako root. Administrátor to může přepsat, jinak všechny uživatelské kontejnery poběží, aniž by kdy byly root. To je důležité zejména v clusterech OpenShift Kubernetes s více nájemci, kde jeden cluster může obsluhovat více aplikací a více vývojových týmů. Není vždy praktické nebo dokonce vhodné, aby správci spouštěli samostatné clustery pro každý z nich. Je smutné, že jednou z největších stížností na OpenShift je to, že uživatelé nemohou snadno spustit všechny obrázky komunitních kontejnerů dostupné na docker.io. Je to proto, že velká většina obrázků kontejnerů na světě dnes vyžaduje root.

Proč všechny tyto obrázky vyžadují root?

Pokud skutečně prozkoumáte důvody, proč být root v systému, jsou poměrně omezené.

Upravte hostitelský systém:

• Jedním z hlavních důvodů, proč být root v systému, je změnit výchozí nastavení systému, jako je úprava konfigurace jádra.
• Ve Fedoře, CentOS a Red Hat Enterprise Linux máme koncept systémových kontejnerů , což jsou privilegované kontejnery, které lze nainstalovat do systému pomocí atomic příkaz. Mohou běžet plně privilegovaně a mohou upravovat systém i jádro. V případě systémových kontejnerů používáme obrázek kontejneru jako systém doručování obsahu, ve skutečnosti nehledáme oddělení kontejnerů. Systémové kontejnery jsou spíše pro hlavní hostitelské služby operačního systému, na rozdíl od služeb uživatelských aplikací, které spouští většina kontejnerů.
• V aplikačních kontejnerech téměř nikdy nechceme, aby procesy v kontejneru upravovaly jádro. Ve výchozím nastavení to rozhodně není vyžadováno.

Tradice Unix/Linux:

• Prodejci softwaru operačního systému a vývojáři již dlouhou dobu věděli, že spouštění procesů je nebezpečné, proto jádro přidalo spoustu schopností Linuxu, které umožňují spustit proces jako root a poté co nejrychleji zahodit oprávnění. Většina funkcí UID/GID umožňuje procesům, jako je webová služba, aby se spustily jako root a poté se staly bez root. To se provádí pro vazbu na porty pod 1024 (více o tom později).
• Běhové moduly kontejneru mohou spouštět aplikace nejprve jako uživatelé bez oprávnění root. Po pravdě řečeno, může to být i systemd, ale většina softwaru, který byl vytvořen za posledních 20 let, předpokládá, že začíná jako root a ztrácí oprávnění.

Vazba na porty <1024

• V 60. a 70. letech 20. století, kdy bylo málo počítačů, byla neschopnost neprivilegovaných uživatelů vázat se na síťové porty <1024 považována za bezpečnostní prvek. Protože to mohl udělat pouze správce, můžete aplikacím naslouchajícím na těchto portech důvěřovat. Porty> 1024 mohou být svázány kterýmkoli uživatelem v systému, takže jim nelze důvěřovat. Bezpečnostní výhody z toho jsou z velké části pryč, ale stále žijeme s tímto omezením.
• Největším problémem tohoto omezení jsou webové služby, kde lidé milují, když jejich webové servery naslouchají na portu 80. To znamená, že hlavním důvodem, proč Apache nebo nginx začínají běžet jako root, je to, že se mohou navázat na port 80 a poté stát se non-root.
• Tento problém mohou vyřešit běhové moduly kontejnerů využívající přesměrování portů. Můžete nastavit kontejner tak, aby naslouchal na libovolném síťovém portu, a poté nechat běhový modul kontejneru namapovat tento port na port 80 na hostiteli.

V tomto příkazu by běhové prostředí podman spustilo apache_unpriv kontejner na vašem počítači naslouchající na portu 80 na hostiteli, zatímco proces Apache uvnitř kontejneru nebyl nikdy root, spouštěný jako apache a řekli mu, aby naslouchal na portu 8080.

podman run -d -p 80:8080 -u apache apache_unpriv

Případně:

docker run -d -p 80:8080 -u apache apache_unpriv

Instalace softwaru do obrazu kontejneru

• Když společnost Docker představila stavební kontejnery s docker build , obsah v kontejnerech byl pouze standardní zabalený software pro distribuce. Software obvykle přišel prostřednictvím balíčků rpm nebo balíčků Debian. No, distribuce balí software, který má nainstalovat root. Balíček očekává, že bude schopen dělat věci, jako je manipulace s /etc/passwd přidáním uživatelů a k uložení obsahu do systému souborů s různými UID/GID. Mnoho softwaru také očekává, že bude spuštěn prostřednictvím systému init (systemd) a spustí se jako root a poté, co se spustí, zahodí oprávnění.
• Pět let po kontejnerové revoluci je to bohužel stále status quo. Před několika lety jsem se pokusil získat balíček httpd, aby věděl, kdy jej instaluje uživatel bez oprávnění root, a aby měl jinou konfiguraci. Ale upustil jsem na tohle. Potřebujeme, aby baliči a systémy pro správu balíčků začaly chápat rozdíl, a pak bychom mohli vytvořit pěkné kontejnery, které běží bez nutnosti root.
• Jedna věc, kterou nyní můžeme udělat, abychom tento problém vyřešili, je oddělit sestavovací systémy od instalujících systémů. Jedním z mých problémů s #nobigfatdaemons je, že démon Docker vedl k tomu, že kontejnery běžely se stejnými oprávněními pro spouštění kontejneru jako pro vytváření obrazu kontejneru.
• Pokud změníme systém nebo použijeme jiné nástroje, řekněme Buildah, pro vytvoření kontejneru s volnějšími omezeními a CRI-O/Kubernetes/OpenShift pro spuštění kontejnerů v produkci, pak můžeme vytvářet se zvýšenými oprávněními, ale poté spustit kontejnery s mnohem užšími omezeními, nebo doufejme jako non-root uživatel.

Sečteno a podtrženo

Téměř veškerý software, který používáte ve svých kontejnerech, nedělá vyžadovat root. Vaše webové aplikace, databáze, nástroje pro vyrovnávání zátěže, číselníky atd. nefungují musí být vždy spuštěn jako root. Když přimějeme lidi, aby začali vytvářet obrázky kontejnerů, které vůbec nevyžadují root, a ostatní, aby své obrázky zakládali na neprivilegovaných obrázcích kontejnerů, viděli bychom obrovský skok v zabezpečení kontejnerů.

Stále je potřeba udělat hodně osvěty ohledně zakořenění uvnitř kontejnerů. Bez vzdělání mohou chytří správci dělat špatná rozhodnutí.