Quina és la bellesa de separar el temps d'execució del contenidor en components separats de l'eina? En particular, el fet que aquestes eines es puguin començar a combinar per protegir-se mútuament.
Moltes persones se senten atretes per la idea de crear imatges OCI en contenidors o sistema similar. Suposem que tenim un CI/CD que crea imatges constantment, després alguna cosa així /Kubernetes seria molt útil pel que fa a l'equilibri de càrrega de la construcció. Fins fa poc, la majoria de la gent simplement donava als contenidors accés a un sòcol Docker i els permetia executar l'ordre de compilació docker. que això és molt insegur, de fet, és encara pitjor que donar root o sudo sense contrasenya.
Així que la gent està constantment intentant executar Buildah en un contenidor. En resum, hem creat com, segons la nostra opinió, el millor és executar Buildah dins d'un contenidor i publicar les imatges corresponents . Comencem...
ajust
Aquestes imatges es creen a partir de Dockerfiles, que es poden trobar al repositori Buildah de la carpeta .
Aquí tindrem en compte .
# 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
En lloc d'OverlayFS implementat al nivell del nucli Linux de l'amfitrió, utilitzem el programa dins del contenidor , perquè actualment OverlayFS només es pot muntar si li doneu permisos SYS_ADMIN mitjançant les capacitats de Linux. I volem executar els nostres contenidors Buildah sense cap privilegi d'arrel. La superposició de fusibles és bastant ràpida i funciona millor que el controlador d'emmagatzematge VFS. Tingueu en compte que quan feu servir un contenidor Buildah amb Fuse, s'ha de proporcionar el dispositiu /dev/fuse.
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
A continuació, creem un directori per a repositoris addicionals. admet el concepte de connexió de repositoris d'imatges de només lectura addicionals. Per exemple, podeu configurar una àrea d'emmagatzematge de superposició en una màquina i, a continuació, utilitzar NFS per muntar aquest emmagatzematge en una altra màquina i utilitzar-ne imatges sense descarregar-les mitjançant pull. Necessitem aquest emmagatzematge per poder connectar algun emmagatzematge d'imatges de l'amfitrió com a volum i utilitzar-lo dins del contenidor.
# 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
Finalment, utilitzem la variable d'entorn BUILDAH_ISOLATION per indicar al contenidor Buildah que comenci amb l'aïllament chroot per defecte. Aquí no cal un aïllament addicional, ja que ja estem treballant en un contenidor. Perquè Buildah creï els seus propis contenidors separats per espais de noms, cal el privilegi SYS_ADMIN, que requeriria afluixar les regles SELinux i SECCOMP del contenidor, cosa que entraria en conflicte amb la nostra configuració per construir des d'un contenidor segur.
Executeu Buildah dins d'un contenidor
L'esquema d'imatge de contenidors Buildah comentat anteriorment us permet variar de manera flexible com es llancen aquests contenidors.
Velocitat versus seguretat
La seguretat informàtica sempre és un compromís entre la velocitat d'un procés i la quantitat de protecció que hi ha al seu voltant. Aquesta afirmació també és certa a l'hora de muntar contenidors, de manera que a continuació considerarem opcions per a aquest compromís.
La imatge del contenidor comentada anteriorment mantindrà el seu emmagatzematge a /var/lib/containers. Per tant, hem de muntar contingut a aquesta carpeta, i com ho fem afectarà molt la velocitat de creació d'imatges de contenidors.
Considerem tres opcions.
Opció 1. Si es requereix la màxima seguretat, per a cada contenidor podeu crear la vostra pròpia carpeta per a contenidors/imatge i connectar-la al contenidor mitjançant el muntatge de volum. I, a més, col·loqueu el directori de context al propi contenidor, a la carpeta /build:
# 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
Seguretat. Un Buildah que s'executa en un contenidor d'aquest tipus té la màxima seguretat: no se li atorguen privilegis d'arrel per capacitats i s'hi apliquen totes les restriccions de SECOMP i SELinux. Aquest contenidor fins i tot es pot executar amb aïllament d'espai de noms d'usuari afegint una opció com --uidmap 0:100000:10000.
Actuació. Però el rendiment aquí és mínim, ja que les imatges dels registres de contenidors es copien a l'amfitrió cada vegada i la memòria cau no funciona des de la paraula "de cap manera". Quan acabi el seu treball, el contenidor Buildah ha d'enviar la imatge al registre i destruir el contingut de l'amfitrió. La propera vegada que es creï la imatge del contenidor, s'haurà de baixar de nou des del registre, ja que no quedarà res a l'amfitrió en aquest moment.
Opció 2. Si necessiteu un rendiment a nivell de Docker, podeu muntar el contenidor/emmagatzematge de l'amfitrió directament al contenidor.
# 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
Seguretat. Aquesta és la manera menys segura de crear contenidors, ja que permet que el contenidor modifiqui l'emmagatzematge a l'amfitrió i podria introduir una imatge maliciosa a Podman o CRI-O. A més, haureu de desactivar la separació de SELinux perquè els processos del contenidor Buildah puguin interactuar amb el dipòsit de l'amfitrió. Tingueu en compte que aquesta opció encara és millor que un sòcol de Docker, ja que el contenidor està bloquejat per les funcions de seguretat restants i no pot simplement recollir i executar cap contenidor a l'amfitrió.
Actuació. Aquí és màxim, ja que la memòria cau està totalment implicada. Si Podman o CRI-O ja han descarregat la imatge desitjada a l'amfitrió, aleshores el procés de Buildah dins del contenidor no haurà de tornar-la a descarregar, i les compilacions posteriors basades en aquesta imatge també podran agafar la necessària de la memòria cau. .
Opció 3. L'essència d'aquest mètode és combinar diverses imatges en un projecte amb una carpeta comuna per a imatges de contenidors.
# 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
En aquest exemple, no suprimim la carpeta del projecte (/var/lib/project3) entre execucions, de manera que totes les compilacions posteriors del projecte aprofiten la memòria cau.
Seguretat. Alguna cosa entre les opcions 1 i 2. D'una banda, els contenidors no tenen accés al contingut de l'amfitrió i, en conseqüència, no poden introduir alguna cosa dolenta a l'emmagatzematge d'imatges Podman / CRI-O. D'altra banda, dins del seu propi projecte, un contenidor pot interferir en el muntatge d'altres contenidors.
Actuació. Aquí és pitjor que utilitzar una memòria cau compartida a nivell d'amfitrió, ja que no podeu utilitzar imatges que ja s'han descarregat amb Podman / CRI-O. Tanmateix, un cop Buildah hagi baixat la imatge, aquesta es pot utilitzar en qualsevol compilació posterior del projecte.
Emmagatzematge addicional
У Hi ha coses tan interessants com les botigues addicionals (botigues addicionals), gràcies a les quals, quan s'inicien i es construeixen contenidors, els motors de contenidors poden utilitzar magatzems d'imatges externes en mode de superposició de només lectura. De fet, podeu afegir un o més emmagatzematges de només lectura al fitxer storage.conf, de manera que quan s'iniciï el contenidor, el motor del contenidor hi cerqui la imatge desitjada. A més, baixarà la imatge del registre només si no la troba en cap d'aquests emmagatzematges. El motor de contenidors només podrà escriure a l'emmagatzematge escrivible...
Si ens desplacem cap amunt i mirem el Dockerfile que fem servir per construir la imatge quay.io/buildah/stable, hi ha línies com aquesta:
# 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
A la primera línia, modifiquem /etc/containers/storage.conf dins de la imatge del contenidor, dient al controlador d'emmagatzematge que utilitzi "additionalimagestores" a la carpeta /var/lib/shared. I a la línia següent, creem una carpeta compartida i afegim un parell de fitxers de bloqueig perquè no hi hagi abús dels contenidors/emmagatzematge. Essencialment, només estem creant una botiga d'imatges de contenidors buides.
Si munteu contenidors/emmagatzematge a un nivell per sobre d'aquesta carpeta, Buildah podrà utilitzar les imatges.
Ara tornem a l'opció 2 comentada anteriorment, quan el contenidor Buildah pot llegir i escriure als contenidors / emmagatzemar als amfitrions i, en conseqüència, té el màxim rendiment a causa de la memòria cau d'imatges a nivell Podman / CRI-O, però ofereix un mínim de seguretat, ja que pot escriure directament a l'emmagatzematge. I ara afegirem emmagatzematge addicional aquí i obtindrem el millor dels dos mons.
# 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
Tingueu en compte que /var/lib/containers/storage de l'amfitrió està muntat a /var/lib/shared dins del contenidor en mode de només lectura. Per tant, treballant en un contenidor, Buildah pot utilitzar qualsevol imatge que ja s'hagi descarregat mitjançant Podman / CRI-O (hola, velocitat), però només pot escriure al seu propi emmagatzematge (hola, seguretat). Tingueu en compte també que això es fa sense desactivar la separació de SELinux per al contenidor.
Matisos importants
En cap cas s'ha de suprimir cap imatge del repositori subjacent. En cas contrari, el contenidor Buildah es podria bloquejar.
I això no són tots els beneficis.
Les possibilitats d'emmagatzematge addicional no es limiten a l'escenari anterior. Per exemple, podeu col·locar totes les imatges dels contenidors en un emmagatzematge de xarxa compartit i donar-hi accés a tots els contenidors de Buildah. Suposem que tenim centenars d'imatges que el nostre sistema CI/CD utilitza habitualment per crear imatges en contenidors. Concentrem totes aquestes imatges en un únic host d'emmagatzematge i després, utilitzant les eines d'emmagatzematge de xarxa preferides (NFS, Gluster, Ceph, iSCSI, S3...), compartim aquest emmagatzematge amb tots els nodes Buildah o Kubernetes.
Ara n'hi ha prou amb muntar aquest emmagatzematge de xarxa al contenidor Buildah a /var/lib/shared i això és tot: els contenidors Buildah ja no han de descarregar imatges mitjançant pull. Així, llencem la fase de prepoblació i de seguida estem preparats per desplegar els contenidors.
I, per descomptat, es pot utilitzar dins d'un sistema de Kubernetes en directe o d'una infraestructura de contenidors per llançar i executar contenidors a qualsevol lloc sense cap extracció d'imatge. A més, quan un registre de contenidors rep una sol·licitud push per carregar-hi una imatge actualitzada, pot enviar automàticament aquesta imatge a un emmagatzematge de xarxa compartit, on està disponible a l'instant per a tots els nodes.
Les imatges dels contenidors de vegades poden tenir una mida de molts gigabytes. La funcionalitat d'emmagatzematge addicional elimina la necessitat de clonar aquestes imatges per nodes i fa que el llançament de contenidors sigui gairebé instantani.
A més, actualment estem treballant en una nova funció de muntatge de volum de superposició que farà que la construcció de contenidors sigui encara més ràpida.
Conclusió
Executar Buildah dins d'un contenidor en un entorn Kubernetes/CRI-O, Podman o fins i tot Docker és molt possible, i és senzill i molt més segur que utilitzar docker.socket. Hem augmentat molt la flexibilitat de treballar amb imatges i ara les podeu executar de diverses maneres per obtenir el millor equilibri entre seguretat i rendiment.
La funcionalitat d'emmagatzematge addicional us permet accelerar o fins i tot eliminar completament la descàrrega d'imatges als nodes.
Font: www.habr.com