Miért érdemes a konténeres végrehajtási környezetek külön eszközökre bontani? Különösen azért, mert ezeket az eszközöket kombinálni lehet, hogy védjék egymást.
Sokan vonzónak találják a konténeres OCI-képek összeállításának ötletét a vagy hasonló rendszeren belül. Tegyük fel, hogy van egy CI/CD rendszerünk, amely folyamatosan összeállítja a képeket, akkor valami ilyesmi /Kubernetes было бы весьма полезно с точки зрения распределения нагрузки при сборке. До недавних пор большинство людей просто давали контейнерам доступ к Docker-сокету и разрешали выполнять команду docker build. , hogy ez nagyon nem biztonságos, valójában ez még rosszabb, mint jelszó nélküli root vagy sudo megadása.
Ezért az emberek folyamatosan próbálnak Buildah-t futtatni egy konténerben. Röviden, létrehoztuk annak érdekében, hogy szerintünk a legjobban fussanak a Buildah konténereken belül, és közzétettük a megfelelő képeket a . Kezdjük…
Beállítás
Ezek a képek Dockerfile-okból készültek, amelyeket megtalálhat a Buildah tárolójában a .
Itt megvizsgáljuk .
# stable/Dockerfile
#
# Build a Buildah container image from the latest
# stable version of Buildah on the Fedoras Updates System.
# https://bodhi.fedoraproject.org/updates/?search=buildah
# This image can be used to create a secured container
# that runs safely with privileges within the container.
#
FROM fedora:latest
# Don't include container-selinux and remove
# directories used by dnf that are just taking
# up space.
RUN yum -y install buildah fuse-overlayfs --exclude container-selinux; rm -rf /var/cache /var/log/dnf* /var/log/yum.*
# Adjust storage.conf to enable Fuse storage.
RUN sed -i -e 's|^#mount_program|mount_program|g' -e '/additionalimage.*/a "/var/lib/shared",' /etc/containers/storage.conf
A gazda Linux-kernele által valósított OverlayFS helyett a konténeren belül a programot használjuk, mivel jelenleg az OverlayFS csak akkor képes a csatlakoztatásra, ha SYS_ADMIN jogokkal rendelkezik a Linux capabilities segítségével. Mi viszont szeretnénk futtatni a Buildah konténereinket root szintű jogosultságok nélkül. A Fuse-overlay meglehetősen gyorsan működik, és teljesítményben jobb, mint a VFS tárolómeghajtó. Vegye figyelembe, hogy a Fuse-t használó Buildah-konténer indításakor meg kell adni a /dev/fuse eszközt.
podman run --device /dev/fuse quay.io/buildahctr ...
RUN mkdir -p /var/lib/shared/overlay-images /var/lib/shared/overlay-layers; touch /var/lib/shared/overlay-images/images.lock; touch /var/lib/shared/overlay-layers/layers.lock
Ezután létrehozunk egy könyvtárat az extra tárolók számára. támogatja a kiegészítő, csak olvasható tárolók csatlakoztatásának koncepcióját. Például beállíthatunk egy overlay tárolóterületet egy gépen, majd az NFS segítségével ezt a tárolót egy másik gépre csatlakoztathatjuk, és a képeket letöltés nélkül használhatjuk belőle. Erre a tárolóra szükségünk van, hogy lehetőségünk legyen csatlakoztatni valamilyen tárolót a gazdán, és azt használni a konténeren belül.
# Set up environment variables to note that this is
# not starting with user namespace and default to
# isolate the filesystem with chroot.
ENV _BUILDAH_STARTED_IN_USERNS="" BUILDAH_ISOLATION=chroot
Végül, a BUILDAH_ISOLATION környezeti változó használatával jelezzük, hogy alapértelmezés szerint a Buildah-konténer chroot izolációval kell, hogy fusson. További izolációra itt nincs szükség, mivel már egy konténerben dolgozunk. Ahhoz, hogy a Buildah saját névtérrel rendelkező konténereket hozzon létre, SYS_ADMIN kiváltság szükséges, amihez le kell bontani a SELinux és SECCOMP szabályokat a konténer számára, ami ellentmond a biztonságos konténerből történő építési telepítésünknek.
Buildah indítása konténeren belül
A fenti Buildah-konténer kép architektúrája rugalmas variálási lehetőségeket biztosít a konténerek indításához.
Sebesség vs. biztonság
A számítógépes biztonság mindig a folyamat végrehajtási sebessége és a körülötte lévő védelem mennyiségének kompromisszuma. Ez az állítás a konténerek építésekor is igaz, ezért lentebb megvizsgáljuk az ilyen kompromisszumok lehetőségeit.
A fent tárgyalt konténerkép a tárolását a /var/lib/containers helyen fogja tárolni. Így a tartalom csatolása erre a könyvtárra nemcsak szükséges, hanem jelentősen befolyásolja a konténerek képeinek építési sebességét is.
Három lehetőséget vizsgálunk.
1. lehetőség. Ha maximális biztonságra van szükség, akkor minden konténerhez külön mappát hozhatunk létre a containers/image számára, és azt volume-mount-on keresztül csatlakoztathatjuk a konténerhez. Ezen kívül a context directory-t magában a konténerben, a /build mappában kell elhelyezni:
# mkdir /var/lib/containers1
# podman run -v ./build:/build:z -v /var/lib/containers1:/var/lib/containers:Z quay.io/buildah/stable
buildah -t image1 bud /build
# podman run -v /var/lib/containers1:/var/lib/containers:Z quay.io/buildah/stable buildah push image1 registry.company.com/myuser
# rm -rf /var/lib/containers1
Biztonság. A Buildah, amely ilyen konténerben fut, maximális biztonsággal rendelkezik: nem kap root kiváltságokat a capabilities eszközökkel, és minden SECOMP és SELinux korlátozás vonatkozik rá. Ez a konténer még User Namespace izolációval is indítható, például egy olyan opcióval, mint az --uidmap 0:100000:10000.
Teljesítmény. A teljesítmény viszont minimális, mivel a konténeregisztrák bármely képe minden alkalommal a hosztra kerül átmásolásra, és a cache-elés szó szerint „nem működik”. A Buildah-konténer befejezése után a képet feltölti a regiszterbe, és megsemmisíti a tartalmat a hoszton. Amikor a következő alkalommal a konténerkép épül, újra le kell tölteni a regiszterből, mivel a hoszton addigra már semmi nem marad.
2. lehetőség. Ha Docker szintű teljesítményre van szükséged, akkor a gazdagép container/storage könyvtárát közvetlenül a konténerhez csatolhatod.
# podman run -v ./build:/build:z -v /var/lib/containers:/var/lib/containers --security-opt label:disabled quay.io/buildah/stable buildah -t image2 bud /build
# podman run -v /var/lib/containers:/var/lib/containers --security-opt label:disabled quay.io/buildah/stable buildah push image2 registry.company.com/myuser
Biztonság. Ez a konténerek építésének legkevésbé biztonságos módja, mivel itt a konténer számára engedélyezett, hogy módosítsa a gazdagépen található tárolót, és potenciálisan rosszindulatú képet juttathat a Podmanhoz vagy a CRI-O-hoz. Ezen kívül ki kell kapcsolni a SELinux elválasztást, hogy a Buildah-konténerben található folyamatok interakcióba léphessenek a gazdagép tárolójával. Érdemes megjegyezni, hogy ez a lehetőség még mindig jobb, mint a Docker socket, mivel a konténer blokkolva van a fennmaradó biztonsági funkciókkal, és nem képes csak úgy elindítani bármilyen konténert a gazdagépen.
Teljesítmény. Itt maximális, mivel a gyorsítótár teljesen ki van használva. Ha a Podman vagy a CRI-O már letöltötte a szükséges képet a gazdagépre, akkor a Buildah-folyamatnak a konténeren belül nem kell újra letöltenie, és a későbbi építések is fel tudják venni a szükséges elemeket a gyorsítótárból.
3. opció. Ennek a módszernek a lényege, hogy több képet egyesítsünk egy projektbe, közös könyvtárral a konténer képek számára.
# mkdir /var/lib/project3
# podman run --security-opt label_level=s0:C100, C200 -v ./build:/build:z
-v /var/lib/project3:/var/lib/containers:Z quay.io/buildah/stable buildah -t image3 bud /build
# podman run --security-opt label_level=s0:C100, C200
-v /var/lib/project3:/var/lib/containers quay.io/buildah/stable buildah push image3 registry.company.com/myuser
Ebben a példában nem töröljük a projekt mappát (/var/lib/project3) a futtatások között, ezért az összes későbbi építés a projekten belül a gyorsítótár előnyeit élvezi.
Biztonság. Valami közép a 1. és a 2. lehetőség között. Egyrészt a konténerek nem férnek hozzá a gazdagépen található tartalomhoz, így nem tudnak rosszat juttatni a Podman/CRI-O képtárolójába. Másrészt a konténer a saját projektjén belül beavatkozhat más konténerek építésébe.
Teljesítmény. Itt ez rosszabb, mint a gazdagép szintű közös gyorsítótár használatakor, mivel nem lehet használni a Podman/CRI-O eszközeivel már korábban letöltött képeket. Azonban miután a Buildah letölti a képet, azt bármelyik későbbi építésnél fel lehet használni a projekten belül.
További tárolók
A Van egy nagyszerű dolog, mint az additional stores, aminek köszönhetően a konténermotorok a konténerek indítása és összeszerelése során képesek külső képtárolók használatára, olvasási engedéllyel. Lényegében a storage.conf fájlba hozzáadhatunk egy vagy több "csak olvasásra" szánt tárolót, így a konténer elindításakor a konténermotor ezeket keresve megnézi, hogy megtalálja a szükséges képet. Csak abban az esetben tölt le képet a registryből, ha nem találja meg egyetlen tárolóban sem. A konténermotor csak az írható tárolókra tud írni...
Ha visszagörgetünk, és megnézzük a Dockerfile-t, amelyet a quay.io/buildah/stable kép összeszereléséhez használunk, akkor ilyen sorokat találunk:
# Adjust storage.conf to enable Fuse storage.
RUN sed -i -e 's|^#mount_program|mount_program|g' -e '/additionalimage.*/a "/var/lib/shared",' /etc/containers/storage.conf
RUN mkdir -p /var/lib/shared/overlay-images /var/lib/shared/overlay-layers; touch /var/lib/shared/overlay-images/images.lock; touch /var/lib/shared/overlay-layers/layers.lock
Az első sorban módosítjuk a konténerképben lévő /etc/containers/storage.conf fájlt, és azt mondjuk, hogy a storage driver használja az "additionalimagestores"-t a /var/lib/shared mappában. A következő sorban közös mappát hozunk létre, és hozzáadunk néhány lock-fájlt, hogy elkerüljük a containers/storage oldalról érkező hibákat. Lényegében csak egy üres konténerképtárolót hozunk létre.
Ha a containers/storage-t egy szinttel a mappa felett csatlakoztatjuk, akkor a Buildah használhatja a képeket.
Most térjünk vissza a fent említett 2. verzióhoz, amikor a Buildah konténer olvashat és írhat a containers/store-ra a hosztokon, így maximális teljesítményt nyújt az Podman/CRI-O szintű képkészítési gyorsítótárazás révén, de minimális biztonságot, mert közvetlenül írhat a tárolókba. Most pedig kapcsoljunk hozzá további tárolókat, és megkapjuk a legjobb dolgokat a két világban.
# mkdir /var/lib/containers4
# podman run -v ./build:/build:z -v /var/lib/containers/storage:/var/lib/shared:ro -v /var/lib/containers4:/var/lib/containers:Z quay.io/buildah/stable
buildah -t image4 bud /build
# podman run -v /var/lib/containers/storage:/var/lib/shared:ro
-v >/var/lib/containers4:/var/lib/containers:Z quay.io/buildah/stable buildah push image4 registry.company.com/myuser
# rm -rf /var/lib/continers4
Ne felejtsd el, hogy a hoszt /var/lib/containers/storage könyvtárát olvasási engedéllyel csatlakoztatták a konténer belsejében lévő /var/lib/shared mappához. Ezért, mivel a konténerben dolgozik, a Buildah bármilyen képet használhat, amelyet korábban a Podman/CRI-O által letöltöttek (helló, sebesség), de csak a saját tárolójába tud írni (helló, biztonság). Szintén vegyétek észre, hogy mindez a konténer SELinux elválasztásának kikapcsolása nélkül történik.
Fontos megjegyzés
Semmiképpen ne távolíts el képeket az alsó tárolóból. Ellenkező esetben a Buildah konténer összeomolhat.
És ez még nem minden előny
A kiegészítő tárolók lehetőségei nem korlátozódnak csak a fent leírt forgatókönyvre. Például, az összes konténerképet közös hálózati tárolóban helyezhetjük el, és hozzáférést adhatunk minden Buildah-konténernek. Tegyük fel, hogy számos képet használ a CI/CD rendszerünk a konténerképek felépítéséhez. Összegyűjtjük ezeket a képeket egy adott tárolóhostra, majd a preferált hálózati tárolási eszközök (NFS, Gluster, Ceph, ISCSI, S3…) használatával megnyitjuk a közös hozzáférést minden Buildah vagy Kubernetes csomópont számára.
Most elég, ha ezt a hálózati tárolót egy Buildah konténerbe csatoljuk a /var/lib/shared útvonalon, és kész is – a Buildah-konténereknek többé nem kell képeket letölteniük pull segítségével. Így megszüntetjük az előkészítési fázist (pre-population) és azonnal készen állunk a konténerek telepítésére.
Természetesen ezeket a meglévő Kubernetes rendszeren vagy konténerinfrastruktúrán belül is felhasználhatjuk, hogy konténereket indítsunk és futtassunk bárhol anélkül, hogy bármilyen képet le kellene tölteni pull-lal. Sőt, a konténerregiszter, ha push kérelmet kap egy frissített kép feltöltésére, automatikusan elküldheti ezt a képet a közös hálózati tárolóba, ahol az azonnal elérhetővé válik minden csomópont számára.
A konténerképek mérete néha több gigabájtra is rúghat. A kiegészítő tárolók funkciója lehetővé teszi, hogy ne kelljen klónozni ezeket a képeket a csomópontokra, és a konténerek indítása gyakorlatilag azonnali lesz.
Ezen kívül jelenleg egy új overlay volume mounts funkción dolgozunk, amely még gyorsabbá teszi a konténerek építését.
Zárás
A Buildah a Kubernetes/CRI-O, Podman vagy akár Docker környezetében való végrehajtása teljesen lehetséges, ráadásul ez egyszerűbb és sokkal biztonságosabb, mint a docker.socket használata. Jelentősen megnöveltük a képek kezelésének rugalmasságát, és most különféle módokon indíthatja őket az optimális egyensúly érdekében a biztonság és a teljesítmény között.
A kiegészítő tárolók funkciója lehetővé teszi, hogy felgyorsítsuk vagy akár teljesen megszüntessük a képek letöltését a csomópontokra.
Forrás: habr.com
