Containerisatie & DevOps
Waarom de Standaard Container Engine Onder Druk Staat
In het afgelopen decennium is Docker synoniem geworden met containerisatie. Het heeft de manier waarop we software verpakken, distribueren en implementeren fundamenteel getransformeerd door het beruchte “it works on my machine” probleem te elimineren. Echter, in enterprise-omgevingen met strenge security-eisen en grootschalige Kubernetes-clusters beginnen de architectonische beperkingen van Docker zichtbaar te worden. De kern van deze beperkingen ligt in de Docker Daemon (dockerd). Dit is een zwaar achtergrondproces dat continu draait en bovendien, standaard, volledige ‘root’-rechten vereist op het host-besturingssysteem. Dit introduceert aanzienlijke beveiligingsrisico’s. De industrie verschuift daarom steeds meer naar modernere alternatieven zoals Podman (ontwikkeld door Red Hat).
Podman biedt een ‘daemonless’ en ‘rootless’ architectuur die qua gebruik (CLI-commando’s) 100% compatibel is met Docker, maar fundamenteel veiliger en efficiënter opereert onder de motorkap. Voor systeembeheerders en DevOps-engineers is dit een cruciale evolutie.
Het Gevaar van de Docker Daemon
In de traditionele Docker-architectuur communiceert de Docker CLI (wat de ontwikkelaar intypt) met de Docker Daemon via een REST API over een Unix-socket. Deze daemon is verantwoordelijk voor het bouwen van images, het starten van containers en het beheren van netwerken. Het probleem is dat deze daemon als ‘root’ draait. Als een kwaadwillende gebruiker of een gecompromitteerde applicatie toegang krijgt tot de Docker-socket, kan deze via een zogenaamde ‘container breakout’ volledige controle krijgen over de onderliggende fysieke server (de host). Dit maakt Docker ongeschikt voor multi-tenant omgevingen waar strikte isolatie vereist is.
Bovendien zorgt de daemon-architectuur voor een ‘single point of failure’. Als het dockerd-proces crasht of herstart moet worden wegens een update, verliezen alle draaiende containers op de host hun ouder-proces, wat leidt tot instabiliteit in de diensten.
Podman: Daemonless en Rootless by Design
Podman elimineert deze daemon volledig. Wanneer u podman run uitvoert, start Podman de container direct als een child-process van de gebruiker die het commando uitvoerde. Er draait geen centraal proces op de achtergrond. Nog belangrijker is dat Podman standaard ‘rootless’ is. Een ontwikkelaar kan containers draaien met zijn of haar eigen, beperkte gebruikersrechten via Linux ‘user namespaces’. Als een hacker onverhoopt ontsnapt uit een rootless Podman-container, heeft deze op de host-server enkel de rechten van een standaard, onbevoorrechte gebruiker, wat de potentiële schade minimaliseert.
Systeemintegratie: Systemd en Pods
Omdat Podman geen eigen achtergrond-daemon heeft om containers draaiende te houden na een server-reboot, integreert het naadloos met ‘systemd’, de standaard service manager van Linux. Podman kan automatisch systemd unit-files genereren voor uw containers, waardoor deze zich gedragen als volwaardige native Linux-services, compleet met automatische herstarts en afhankelijkheidsbeheer.
Daarnaast introduceert Podman het concept van ‘Pods’ lokaal op uw machine, exact hetzelfde concept als Kubernetes gebruikt. In plaats van containers aan elkaar te knopen via virtuele Docker-netwerken, groepeert u met Podman meerdere containers (zoals een frontend, een backend en een database) in één Pod die een localhost netwerk en resources deelt. Dit maakt de transitie van lokale ontwikkeling naar een productie Kubernetes-cluster veel natuurlijker. Podman kan zelfs Kubernetes YAML-manifests exporteren van lokale pods. Ontdek meer over veilige software cycli op AG Connect.
Volgende: GitOps en ArgoCD: De Declaratieve Evolutie van Kubernetes Deployments
