- Alapvető különbségek a rootful és rootless végrehajtás között a gazdarendszer biztonságossá tétele érdekében.
- Keményítő technikák a kernel képességeinek eltávolításával és írásvédett fájlrendszerek használatával.
- Felhasználói névtér-kezelés és azonosító-leképezés a folyamatok elkülönítéséhez korlátozott környezetekben.
- Biztonsági stratégiák az ellátási láncban és a konténerek valós idejű monitorozása.
Manapság szinte minden fejlesztőcsapat konténereket használ alkalmazásai telepítéséhez. Van azonban egy kulcsfontosságú szempont, amelyet sokan figyelmen kívül hagynak: a valódi biztonság. Egy szolgáltatás alapértelmezett konfigurációval történő indítása gyakran a leggyorsabb út, de egyben a legveszélyesebb is, mivel a konténerek nyitva hagyása egy apró kódhibát is teljes katasztrófává változtathat a szerver infrastruktúra számára.
Az önelégültség elkerülésének kulcsa annak megértése, hogy az izoláció nem varázslat, hanem egy precíz konfiguráció. A nem privilegizált felhasználók használatától a kernelhívások kimerítő szabályozásáig a támadási felület csökkentése az egyetlen módja annak, hogy garantáljuk, hogy ha egy támadónak sikerül behatolnia egy konténerbe, egy áthatolhatatlan falba ütközik, amely megakadályozza a gazdagéphez való hozzáférést.
Podman és a gyökeres vs. gyökértelen dilemma
Amikor a Podmanról beszélünk, két nagyon eltérő végrehajtási filozófiával találkozunk. Egyrészt a rootful konténer mód a klasszikus megközelítés: a folyamat a gazdagép root felhasználójaként indul. Ez azt jelenti, hogy a konténer abszolút kontrollal rendelkezik a rendszer felett, ami egy ketyegő időzített bomba, ha bármilyen sebezhetőség létezik, amely lehetővé teszi a támadó számára a jogosultságok eszkalálását.
Ezen ijesztő helyzetek elkerülése érdekében létezik a root nélküli konténer mód . Itt a motor működéséhez nincs szükség szuperképességekkel rendelkező démonra. Fontos megérteni, hogy bár a konténeren belüli felhasználó rootnak tűnik, a gazdagépen valójában egy privilégium nélküli felhasználó . Ez egy jelentős biztonsági akadályt hoz létre, mivel minden behatolás a korlátozott felhasználó kontextusára korlátozódik.
A root nélküli mód azonban nem csupa pompa és pompa, mivel bizonyos technikai korlátozásokkal jár , amelyeket kezelni kell. Például nem nyithatunk meg privilegizált portokat (1024 alattiakat), és egyes hálózati funkciók, például a külső szerverek pingelése, problémákat okozhatnak, ha nincsenek megfelelően konfigurálva. A portprobléma megoldása egyszerű: a magas portokat , például a 8080-at, a szolgáltatás belső portjához kell rendelni.
A névterek és az azonosító-leképezés titka
Annak érdekében, hogy egy átlagos hosztfelhasználó rootként működhessen egy konténeren belül a rendszer feltörése nélkül, a Linux felhasználói névtereket használ . Ez a technológia lehetővé teszi a kernel számára, hogy egy sor elszigetelt azonosítót rendeljen hozzá, megfeleltetést hozva létre a konténer és a hoszt UID-jai között.
Ha megnézzük az /etc/subuid és /etc/subgid fájlokat , látni fogjuk, hogy minden felhasználóhoz egy azonosítótartomány tartozik. Például egy 1000-es UID-val rendelkező felhasználó több ezer további azonosítót is leképezhet. Ez azt jelenti, hogy amikor egy folyamatot a konténeren belül 'sync' felhasználóként (UID 5) futtatunk, a gazdagép egy nagyon magas UID-ként látja, jogosultságok nélkül , így a rendszer teljesen biztonságban van.
Ha meg kell vizsgálnunk, hogy mi történik a háttérben anélkül, hogy egy teljes konténert elindítanánk, használhatjuk a `podman unshare` parancsot . Ez az eszköz lehetővé teszi számunkra, hogy belépjünk a felhasználó névterébe, megvizsgáljuk az ID-térképet, és ellenőrizzük, hogy az izoláció megfelelően működik-e.
Docker Hardening: A végrehajtás biztosítása
Ha a környezeted Docker, a biztonsági stratégiádnak agresszívnek kell lennie. Az első lépés a minimális jogosultságok elvének alkalmazása . Ne engedd, hogy a konténer többet tegyen, mint amennyi feltétlenül szükséges. Az erős konfiguráció magában foglalja a képfájl elindítását a `--read-only` opcióval , amely írásvédetté teszi a fájlrendszert, és megakadályozza, hogy a támadó rosszindulatú programokat telepítsen vagy bináris fájlokat módosítson.
Továbbá létfontosságú a kernel képességeinek törlése. A `--cap-drop ALL` használatával eltávolíthatók a konténerből minden speciális jogosultság, és ha bármilyen speciális jogosultságra van szüksége (például egy adott port megnyitásához), akkor azokat a `--cap-add` segítségével állíthatjuk vissza . Ha ezt hozzáadjuk a `--security-opt no-new-privileges` opcióhoz , akkor blokkoljuk a jogosultságok eszkalációjára tett kísérleteket a folyamaton belül.
Azok számára, akik összetettebb telepítéseket kezelnek, az ideális megközelítés az, ha mindezt a compose.yaml fájlban tárolják . A folyamatkorlátok pids_limit segítségével történő meghatározása , valamint a CPU- és memória-használat korlátozása megakadályozza, hogy egy rosszul működő vagy feltört konténer feleméssze a szerver összes erőforrását, ami szolgáltatásmegtagadási hibát okozna a többi alkalmazás számára.
Biztonság az arculatban és az ellátási láncban
Hiábavaló egy biztonságos futásidejű környezet, ha a letöltött képfájl tele van sebezhetőségekkel. A kulcs a hivatalos, könnyűsúlyú képfájlok használata. A teljes Ubuntu disztribúció használata helyett sokkal bölcsebb a slim vagy Alpine Linux verziókat választani , amelyek drasztikusan csökkentik a támadó által kihasználható telepített eszközök számát.
Kritikus hiba, ha az alkalmazást root felhasználóként futtatjuk a Dockerfile-on belül. A helyes megközelítés egy adott felhasználó létrehozása a `RUN adduser` paranccsal , majd a kontextus megváltoztatása a `USER` direktívával . Így az alkalmazás soha nem fér hozzá a rendszerhez rendszergazdai jogosultságokkal, függetlenül attól, hogy a konténer hogyan indult el.
A ciklus befejezéséhez elengedhetetlen az automatikus sebezhetőségi vizsgálat megvalósítása a CI/CD folyamatban. Azok az eszközök, amelyek a képrétegeket elemzik, mielőtt azok elérnék a beállításjegyzéket, megakadályozzák az ismert kritikus hibákat tartalmazó kód telepítését. A biztonság nem az utolsó lépés; azt a teljes szoftver életciklusába integrálni kell.
Hozzáférés-kezelés és fejlett felügyelet
Azokban a környezetekben, ahol több fejlesztőnek kell Dockert használnia, nagy a kísértés, hogy root jogosultságokat adjunk nekik. Egy tisztább alternatíva a felhasználók hozzáadása a Docker csoport mediante usermod -aG dockerAzonban fontos tudni, hogy ez jelentős hatalmat biztosít, ezért tanácsos módosítani a jogosultságokat. Docker aljzat sebészeti úton.
Vállalati szintű védelemhez a statikus konfiguráció nem elegendő. Seccomp, AppArmor vagy SELinux profilok megvalósítása szükséges . Ezek a mechanizmusok kapuőrként működnek, szűrik a konténer által a Linux kernelnek küldött rendszerhívásokat, blokkolva a gyanús vagy jogosulatlan kéréseket.
A kirakós utolsó darabja a valós idejű láthatóság . Mivel a konténerek múlandóak, a hagyományos naplók elégtelennek bizonyulnak. A naplók központosítása és az olyan monitorozó eszközök használata, amelyek észlelik a rendellenes viselkedést, például a semmiből felbukkanó furcsa folyamatokat vagy a jogosulatlan külső hálózatokhoz való csatlakozási kísérleteket, kulcsfontosságú.
Az operációs rendszer szintű virtualizációs biztonság a képhigiénia, a szigorú végrehajtási korlátozások és az állandó monitorozás kombinációján alapul. A nem privilegizált felhasználók használatának, az intelligens azonosító-leképezésnek és a felesleges kernel-képességek eltávolításának kombinálásával infrastruktúra-rugalmasságot érünk el, és teljes mértékben semlegesítünk minden potenciális behatolást anélkül, hogy ez befolyásolná az alkalmazások teljesítményét.
Szenvedélyes író a bájtok és általában a technológia világáról. Szeretem megosztani tudásomat írásban, és ezt fogom tenni ebben a blogban, megmutatom a legérdekesebb dolgokat a kütyükről, szoftverekről, hardverekről, technológiai trendekről stb. Célom, hogy egyszerű és szórakoztató módon segítsek eligazodni a digitális világban.