Cloud-Container: Ent­wick­lung von An­wen­dun­gen in der Cloud

Cloud-Container sind leicht­ge­wich­ti­ge, portable Pakete, die eine Anwendung mitsamt ihrer Ab­hän­gig­kei­ten isolieren. Im Gegensatz zu vir­tu­el­len Maschinen teilen sie sich den Be­triebs­sys­tem­kern, was sie sehr effizient macht. Sie bilden die tech­no­lo­gi­sche Basis für Mi­cro­ser­vices und moderne Cloud-Native-Ar­chi­tek­tu­ren.

Was sind Cloud-Container?

Cloud Computing spielt für zahl­rei­che Un­ter­neh­men eine immer größere Rolle. Die Vorteile der Arbeit in einer Cloud sind viel­fäl­tig und reichen von immensen Kos­ten­er­spar­nis­sen über mehr Fle­xi­bi­li­tät bis zum größeren Angebot an Software, Speicher oder Servern. Neben her­kömm­li­chen Cloud-Lösungen setzen viele große Firmen wie Google oder Microsoft immer öfter auch auf Cloud-Container.

Cloud-Container sind abstrakte und ei­gen­stän­di­ge Software-Einheiten, die An­wen­dun­gen samt ihrer Ab­hän­gig­kei­ten in einer iso­lier­ten Umgebung ausführen. Anders als virtuelle Maschinen vir­tua­li­sie­ren sie jedoch keine komplette Hardware-In­fra­struk­tur und bringen kein eigenes voll­stän­di­ges Be­triebs­sys­tem mit. Statt­des­sen arbeiten sie auf Be­triebs­sys­tem­ebe­ne: Mehrere Container teilen sich den Kernel des Host­sys­tems, laufen aber als von­ein­an­der getrennte Prozesse.

Diese Isolation wird unter Linux vor allem durch Name­spaces und cgroups er­mög­licht. Name­spaces sorgen dafür, dass ein Container nur die für ihn vor­ge­se­he­nen Prozesse, Netz­werk­be­rei­che oder Da­tei­sys­tem­an­sich­ten sieht. cgroups begrenzen und steuern dagegen den Zugriff auf Res­sour­cen wie CPU, Ar­beits­spei­cher oder I/O. Dadurch kann ein Container nicht un­be­grenzt auf die phy­si­schen Res­sour­cen des Hosts zugreifen. Die Anwendung innerhalb des Con­tai­ners bleibt dennoch weit­ge­hend un­ab­hän­gig von der Umgebung, weil benötigte Bi­blio­the­ken, Ab­hän­gig­kei­ten und Kon­fi­gu­ra­tio­nen im Container-Image gebündelt werden.

Wie funk­tio­nie­ren Cloud-Container?

Die Funk­ti­ons­wei­se von Cloud-Con­tai­nern ent­spricht wei­test­ge­hend ge­wöhn­li­chen Con­tai­nern, die bei­spiels­wei­se im Bereich der Software-Ent­wick­lung bereits seit vielen Jahren ein­ge­setzt werden. Ein Cloud-Container führt eine Anwendung als iso­lier­ten Prozess auf dem Host­sys­tem aus. Dafür enthält das Container-Image die Anwendung selbst sowie alle not­wen­di­gen Ab­hän­gig­kei­ten, Kon­fi­gu­ra­tio­nen und Bi­blio­the­ken. Aus­ge­führt wird dieses Image durch eine Container-Runtime bzw. Container-Engine.

Die Trennung zwischen den Con­tai­nern entsteht auf Be­triebs­sys­tem­ebe­ne. Der ge­mein­sa­me Host-Kernel stellt Me­cha­nis­men bereit, mit denen Prozesse von­ein­an­der ab­ge­schirmt und Res­sour­cen gezielt begrenzt werden können. So erhält jeder Container eine eigene, isolierte Sicht auf bestimmte Sys­tem­be­rei­che, ohne dass dafür ein voll­stän­di­ges Gast­be­triebs­sys­tem gestartet werden muss. Dadurch bleiben Container res­sour­cen­ef­fi­zi­ent und lassen sich schnell starten, ver­schie­ben und ver­viel­fäl­ti­gen.

Cloud-Container vs. virtuelle Maschinen: Wo liegen die Un­ter­schie­de?

Cloud-Container und virtuelle Maschinen (VMs) verfolgen ein ähnliches Ziel: An­wen­dun­gen sollen isoliert und möglichst un­ab­hän­gig von der zugrunde liegenden In­fra­struk­tur betrieben werden. Technisch un­ter­schei­den sich beide Ansätze jedoch deutlich. Bei einer VM wird die Hardware vir­tua­li­siert. Zwischen phy­si­schem Server und vir­tu­el­ler Maschine liegt ein so­ge­nann­ter Hy­per­vi­sor, der virtuelle Res­sour­cen wie CPU, Ar­beits­spei­cher, Netz­werk­schnitt­stel­len und Spei­cher­platz be­reit­stellt. Jede VM bringt dabei in der Regel ein voll­stän­di­ges Gast­be­triebs­sys­tem inklusive eigenem Kernel mit.

Cloud-Container arbeiten schlanker. Sie vir­tua­li­sie­ren nicht die komplette Hardware, sondern laufen als von­ein­an­der isolierte Prozesse auf demselben Be­triebs­sys­tem­kern des Hosts. Der Container enthält die Anwendung sowie alle be­nö­tig­ten Ab­hän­gig­kei­ten, Bi­blio­the­ken und Kon­fi­gu­ra­tio­nen, teilt sich aber den Kernel mit dem Host­sys­tem und anderen Con­tai­nern. Dadurch benötigen Container weniger Res­sour­cen, starten schneller und lassen sich dichter ne­ben­ein­an­der betreiben als klas­si­sche virtuelle Maschinen.

Besonders wichtig ist dieser Un­ter­schied für Multi-Cloud-Stra­te­gien. Ein Container-Image kann einmal erstellt und an­schlie­ßend in un­ter­schied­li­chen Um­ge­bun­gen aus­ge­führt werden – etwa in einer Private Cloud, bei einem Public-Cloud-Anbieter oder in einer Ku­ber­netes-Umgebung. Dieses Prinzip wird häufig als „Write once, run anywhere“ be­schrie­ben. Un­ter­neh­men vermeiden dadurch, An­wen­dun­gen für jede Cloud-Plattform voll­stän­dig neu pa­ke­tie­ren oder kon­fi­gu­rie­ren zu müssen.

Wofür werden Cloud-Container ein­ge­setzt?

Es gibt grund­sätz­lich sehr viele An­wen­dungs­mög­lich­kei­ten für Cloud-Container. Ihre Bauweise und Ei­gen­schaf­ten machen sie zur idealen Lösung für zahl­rei­che Workloads. Zu den gän­gigs­ten An­wen­dungs­fäl­len gehören folgende:

• Cloud-native An­wen­dun­gen: Cloud-native An­wen­dun­gen pro­fi­tie­ren von Cloud-Con­tai­nern, da diese einen sehr geringen Res­sour­cen­ver­brauch haben. So ist es möglich, sehr viele Cloud-Container res­sour­cen­scho­nend auf derselben In­fra­struk­tur zu betreiben.
• Hybrid Cloud und Multi Cloud: In einer Hybrid Cloud werden Cloud-Container dafür verwendet, Workloads in un­ter­schied­li­chen Um­ge­bun­gen aus­zu­füh­ren. Der Wechsel von einer Cloud in eine andere ist deutlich einfacher, da Container-Images Anwendung, Ab­hän­gig­kei­ten und Kon­fi­gu­ra­ti­on bereits mit sich führen. Nach dem Prinzip „Write once, run anywhere“ können An­wen­dun­gen dadurch kon­sis­ten­ter über Private Clouds, Public Clouds oder lokale In­fra­struk­tu­ren hinweg be­reit­ge­stellt werden. Gleich­zei­tig erhalten Admins eine bessere Übersicht über alle Be­reit­stel­lungs­or­te. Auch in einem Multi-Cloud-Ansatz ist dies vor­teil­haft.
• Machine Learning: Da einzelne Al­go­rith­men in un­ter­schied­li­chen Con­tai­nern aus­ge­führt werden können, ohne einander zu be­ein­flus­sen, ist die Technik die perfekte Umgebung für ef­fi­zi­en­tes Machine Learning.
• Mi­cro­ser­vices: Mi­cro­ser­vices sind kleinere Funk­tio­nen innerhalb einer größeren Anwendung. Ihre Aus­füh­rung sollte vor allem schnell sein und möglichst wenige Res­sour­cen benötigen. Genau diese An­for­de­run­gen erfüllt die Be­reit­stel­lung über einen Cloud-Container, da dieser besonders leicht­ge­wich­tig ist.
• CI/CD und DevOps-Workflows: Cloud-Container sind ein wichtiger Baustein für moderne Ent­wick­lungs- und Be­reit­stel­lungs­pro­zes­se. In CI/CD-Pipelines können An­wen­dun­gen au­to­ma­ti­siert gebaut, getestet und als Container-Image be­reit­ge­stellt werden. Dadurch lassen sich neue Funk­tio­nen, Updates oder Feh­ler­be­he­bun­gen schneller und zu­ver­läs­si­ger ausrollen. Für DevOps-Teams entsteht ein ein­heit­li­cher Workflow von der Ent­wick­lung über das Testing bis zum pro­duk­ti­ven Betrieb, da dieselbe con­tai­ne­ri­sier­te Anwendung in ver­schie­de­nen Um­ge­bun­gen genutzt werden kann.
• Migration: Wie bereits erwähnt, sind Cloud-Container ideal für die Migration, da alle Ab­hän­gig­kei­ten und die Kon­fi­gu­ra­ti­on bereits enthalten und los­ge­kop­pelt von anderen An­wen­dun­gen sind. Soll also eine Anwendung ver­scho­ben werden, eignet sich ein Cloud-Container dafür perfekt.
• Mo­der­ni­sie­rung: Da Cloud-Container immer wichtiger werden und in vielen Un­ter­neh­men bereits jetzt zum Einsatz kommen, eignet sich ihre Im­ple­men­tie­rung auch dazu, das eigene System sowie den Workflow zu mo­der­ni­sie­ren.
• Sta­pel­ver­ar­bei­tung: Auch im Bereich der Au­to­ma­ti­sie­rung von Prozessen können Cloud-Container eine wichtige Rolle spielen. Sie eignen sich für die Sta­pel­ver­ar­bei­tung, die ohne mensch­li­ches Ein­grei­fen auskommt, da ihre Ab­hän­gig­kei­ten sowie ihre Umgebung nicht extra neu definiert werden müssen.

Check­lis­te: Wann eignen sich Cloud-Container?

Cloud-Container sind nicht für jede Anwendung au­to­ma­tisch die beste Lösung. Besonders sinnvoll sind sie, wenn mehrere der folgenden Punkte zutreffen:

• Die Anwendung besteht aus Mi­cro­ser­vices: Einzelne Funk­tio­nen oder Services können un­ab­hän­gig von­ein­an­der ent­wi­ckelt, be­reit­ge­stellt und skaliert werden.
• Schnelle De­ploy­ment-Zyklen sind wichtig: Updates, neue Funk­tio­nen oder Bugfixes sollen re­gel­mä­ßig und au­to­ma­ti­siert ver­öf­fent­licht werden.
• CI/CD-Pipelines werden genutzt: An­wen­dun­gen sollen au­to­ma­ti­siert gebaut, getestet und als Container-Image be­reit­ge­stellt werden.
• Ska­lier­bar­keit spielt eine zentrale Rolle: Die Anwendung muss flexibel auf steigende oder schwan­ken­de Lasten reagieren können.
• Un­ter­schied­li­che Um­ge­bun­gen müssen kon­sis­tent bleiben: Ent­wick­lung, Test und Pro­duk­ti­on sollen möglichst auf derselben tech­ni­schen Grundlage laufen.
• Hybrid- oder Multi-Cloud-Stra­te­gien sind geplant: Workloads sollen zwischen ver­schie­de­nen Cloud-Um­ge­bun­gen, lokalen Systemen oder Cloud-Anbietern ver­scho­ben werden können.
• Res­sour­cen sollen effizient genutzt werden: Mehrere An­wen­dun­gen oder Services sollen platz­spa­rend und mit geringem Overhead betrieben werden.
• Teams arbeiten nach DevOps- oder DevSecOps-Prin­zi­pi­en: Ent­wick­lung, Betrieb und Si­cher­heit sollen enger verzahnt und stärker au­to­ma­ti­siert werden.
• An­wen­dun­gen müssen schnell re­pli­ziert werden können: Zu­sätz­li­che Instanzen sollen bei Bedarf kurz­fris­tig be­reit­ste­hen.
• Ab­hän­gig­kei­ten sollen sauber gekapselt werden: Bi­blio­the­ken, Kon­fi­gu­ra­tio­nen und Lauf­zeit­um­ge­bun­gen sollen gemeinsam mit der Anwendung be­reit­ge­stellt werden.

Welche Vorteile haben Cloud-Container?

Cloud-Container bieten für die meisten Un­ter­neh­men zahl­rei­che Vorteile und können für viele An­wen­dungs­fäl­le eine geeignete Lösung sein. Zu den wich­tigs­ten Pro-Ar­gu­men­ten zählen:

• Fle­xi­bi­li­tät: Cloud-Container sind eine sehr flexible und auch ef­fi­zi­en­te Lösung. Durch die Isolation von anderen An­wen­dun­gen können Container-Images in­di­vi­du­ell kon­fi­gu­riert und dann genutzt werden. Auch die Migration ist sehr einfach, wodurch die Arbeit in ver­schie­de­nen Um­ge­bun­gen möglich ist.
• Geringe Kosten: Auch der Kos­ten­fak­tor sollte in jedem Fall immer mit­ge­dacht werden. Hier über­zeu­gen Cloud-Container ebenfalls. Die Ausgaben lassen sich niedrig halten und gleich­zei­tig ist die Im­ple­men­tie­rung zahl­rei­cher Container ne­ben­ein­an­der möglich.
• Platz­be­darf: Da Container kein eigenes voll­stän­di­ges Be­triebs­sys­tem mit­brin­gen, benötigen sie deutlich weniger Spei­cher­platz und Sys­tem­res­sour­cen als bei­spiels­wei­se virtuelle Maschinen.
• Ska­lier­bar­keit: Steigen die Ar­beits­las­ten, können Cloud-Container schnell ver­viel­fäl­tigt und auf zu­sätz­li­che Res­sour­cen verteilt werden. In Ver­bin­dung mit Or­ches­trie­rungs­lö­sun­gen wie Ku­ber­netes ist auch Auto-Scaling möglich: Werden bestimmte Last­gren­zen erreicht, können au­to­ma­tisch weitere Container-Instanzen gestartet werden. Sinkt der Bedarf wieder, lassen sich nicht mehr benötigte Instanzen ebenso au­to­ma­tisch re­du­zie­ren.
• Isolation: Die Isolation der einzelnen Cloud-Container wirkt sich auch deshalb positiv aus, weil Probleme oder Fehler innerhalb eines Con­tai­ners keine negativen Aus­wir­kun­gen auf die um­lie­gen­den Container haben. So ist es möglich, An­wen­dun­gen ohne Gefahren zu testen und Bugs schneller zu iden­ti­fi­zie­ren.
• Si­cher­heit: Cloud-Container gelten als sichere Ar­chi­tek­tur, sofern sie korrekt kon­fi­gu­riert und betrieben werden. Dazu trägt nicht nur die Isolation bei, sondern auch die Mög­lich­keit, Si­cher­heits­be­rech­ti­gun­gen für jeden Container einzeln zu de­fi­nie­ren.
• Ent­wick­ler­freund­lich­keit: Für Ent­wick­le­rin­nen und Ent­wick­ler sind Cloud-Container besonders hilfreich, weil Ent­wick­lung, Test und Pro­duk­ti­on auf einer ein­heit­li­chen tech­ni­schen Grundlage statt­fin­den können. Eine Anwendung wird inklusive ihrer Ab­hän­gig­kei­ten als Container-Image verpackt und kann an­schlie­ßend au­to­ma­ti­siert getestet, ver­sio­niert und be­reit­ge­stellt werden. Das er­leich­tert CI/CD-Pipelines, reduziert Un­ter­schie­de zwischen Ent­wick­lungs- und Pro­duk­tiv­um­ge­bun­gen und un­ter­stützt schnelle De­ploy­ment-Zyklen.

Welche Software ist für Cloud-Container emp­feh­lens­wert?

Viele Provider bieten Container as a Service (CaaS) an. Welche Lösung am besten geeignet ist, hängt stark vom je­wei­li­gen Ein­satz­zweck, der vor­han­de­nen In­fra­struk­tur und der ge­wünsch­ten Cloud-Strategie ab. Cloud-Container basieren auf offenen Standards der Open Container In­itia­ti­ve (OCI), die ins­be­son­de­re das Image-Format und die Runtime-Spe­zi­fi­ka­ti­on de­fi­nie­ren. Aspekte wie Netzwerk, Storage oder Or­ches­trie­rung sind bewusst nicht Teil der OCI-Standards und werden durch zu­sätz­li­che Kom­po­nen­ten wie Ku­ber­netes und CNI-Plugins umgesetzt.

Container-Or­ches­trie­rung mit Ku­ber­netes

Cloud-Container sind sehr gut geeignet, um einzelne An­wen­dun­gen samt ihrer Ab­hän­gig­kei­ten be­reit­zu­stel­len. Für pro­duk­ti­ve Cloud-Um­ge­bun­gen reicht das allein jedoch meist nicht aus. Sobald viele Container parallel laufen, mehrere An­wen­dungs­ver­sio­nen verwaltet werden müssen oder Workloads dynamisch auf un­ter­schied­li­che Server verteilt werden sollen, wird eine über­ge­ord­ne­te Steue­rungs­ebe­ne benötigt. Genau hier kommt Container-Or­ches­trie­rung ins Spiel.

Eine der wich­tigs­ten Lösungen dafür ist Ku­ber­netes, oft auch K8s genannt. Ku­ber­netes arbeitet nach dem Prinzip eines de­kla­ra­ti­ven „Desired State“-Modells. Ein kon­ti­nu­ier­li­cher Control Loop (Re­con­ci­lia­ti­on Loop) ver­gleicht den ge­wünsch­ten Zustand mit dem aktuellen Zustand und kor­ri­giert Ab­wei­chun­gen au­to­ma­tisch. Dieses Prinzip wird als Self-Healing be­zeich­net. Außerdem verteilt Ku­ber­netes ein­ge­hen­de Anfragen über Services auf ver­füg­ba­re Container-Instanzen und un­ter­stützt dadurch Load Balancing. Für neue Versionen einer Anwendung lassen sich au­to­ma­ti­sier­te Rollouts nutzen, bei denen Container schritt­wei­se ersetzt werden. Treten Probleme auf, kann die vorherige Version kon­trol­liert wie­der­her­ge­stellt werden.

Damit wird Ku­ber­netes zu einem zentralen Baustein für Cloud-Container im Un­ter­neh­mens­ein­satz. Während Container die Anwendung portabel und un­ab­hän­gig von einzelnen Um­ge­bun­gen machen, übernimmt Ku­ber­netes den Betrieb im größeren Maßstab. Es verbindet De­ploy­ment, Ska­lie­rung, Ver­füg­bar­keit und Aus­fall­si­cher­heit in einer ge­mein­sa­men Plattform und macht Container dadurch für den pro­duk­ti­ven Cloud-Einsatz ska­lier­bar und zu­ver­läs­sig ver­walt­bar.

Container-Runtimes: Docker und Al­ter­na­ti­ven

Eine mögliche Im­ple­men­tie­rung zur Er­stel­lung von OCI-konformen Container-Images ist Docker. Docker wird vor allem im Ent­wick­lungs­um­feld genutzt, um Images zu bauen, zu testen und lokal aus­zu­füh­ren. In Ku­ber­netes-Clustern wird Docker al­ler­dings nicht mehr als Runtime verwendet. Statt­des­sen nutzt Ku­ber­netes das Container Runtime Interface (CRI), über das moderne Runtimes an­ge­bun­den werden, die im Cluster die ei­gent­li­che Aus­füh­rung und Ver­wal­tung von Con­tai­nern über­neh­men. Besonders beliebt sind die beiden folgenden Lauf­zei­ten:

• con­tai­nerd ist die am weitesten ver­brei­te­te Runtime und wird in vielen Cloud- und Managed-Ku­ber­netes-Um­ge­bun­gen ein­ge­setzt.
• CRI-O ist eine schlanke, Ku­ber­netes-spe­zi­fi­sche Runtime, die aus­schließ­lich für den Betrieb von Pods ent­wi­ckelt wurde.

Neben diesen Cluster-Runtimes gibt es auch Werkzeuge für die lokale Arbeit wie Podman. Hierbei handelt es sich um ein dae­mon­lo­ses Tool für die lokale Container-Ver­wal­tung mit einem Docker-kom­pa­ti­blen CLI. Podman dient vor allem der Ent­wick­lung und dem Testing außerhalb des Clusters.

Ser­ver­less Container und Managed Services

Neben selbst ver­wal­te­ten Container-Um­ge­bun­gen und Ku­ber­netes-Clustern haben sich in der Cloud weitere Abs­trak­ti­ons­ebe­nen etabliert. Bei so­ge­nann­ten Ser­ver­less Con­tai­ners starten Nut­ze­rin­nen und Nutzer con­tai­ne­ri­sier­te An­wen­dun­gen, ohne die zugrunde liegenden Server, Cluster oder Lauf­zeit­um­ge­bun­gen direkt verwalten zu müssen. Der Begriff „ser­ver­less“ bedeutet dabei nicht, dass keine Server mehr verwendet werden. Vielmehr übernimmt der Cloud-Anbieter Aufgaben wie Be­reit­stel­lung, Ska­lie­rung, In­fra­struk­tur­ver­wal­tung und Teile des Betriebs im Hin­ter­grund.

Für Ent­wick­lungs­teams kann dieser Ansatz besonders attraktiv sein, wenn An­wen­dun­gen schnell be­reit­ge­stellt werden sollen, ohne sich intensiv mit Ser­ver­kon­fi­gu­ra­ti­on, Cluster-Wartung oder Ka­pa­zi­täts­pla­nung zu be­schäf­ti­gen. Statt eine eigene In­fra­struk­tur auf­zu­bau­en, wird meist ein Container-Image be­reit­ge­stellt und mit Angaben zu Res­sour­cen, Netz­werk­zu­grif­fen oder Um­ge­bungs­va­ria­blen kon­fi­gu­riert. Die Plattform kümmert sich an­schlie­ßend darum, die Anwendung aus­zu­füh­ren und je nach Nachfrage zu­sätz­li­che Instanzen be­reit­zu­stel­len oder nicht benötigte Ka­pa­zi­tä­ten wieder zu re­du­zie­ren.

Ser­ver­less Container eignen sich vor allem für:

• Web­an­wen­dun­gen
• APIs
• Hin­ter­grund­pro­zes­se
• Er­eig­nis­ge­steu­er­te Workloads
• Dienste mit stark schwan­ken­der Aus­las­tung

Sie verbinden die Por­ta­bi­li­tät von Con­tai­nern mit dem Komfort ver­wal­te­ter Cloud-Dienste. Un­ter­neh­men behalten dadurch die Vorteile con­tai­ne­ri­sier­ter An­wen­dun­gen, müssen aber weniger operative Ver­ant­wor­tung für die dar­un­ter­lie­gen­de In­fra­struk­tur über­neh­men.

Beispiele für solche Platt­for­men sind AWS Fargate, Google Cloud Run oder Azure Container Apps. Typisch für diesen Ansatz ist, dass Res­sour­cen au­to­ma­tisch skaliert werden – inklusive so­ge­nann­ter „Cold Starts“, bei denen Container erst bei Bedarf gestartet werden. Dadurch eignen sich Ser­ver­less Container besonders für un­re­gel­mä­ßi­ge oder er­eig­nis­ge­steu­er­te Workloads.

Container Security und DevSecOps

Si­cher­heit sollte bei Cloud-Con­tai­nern nicht erst im laufenden Betrieb be­rück­sich­tigt werden, sondern von Anfang an Teil der Container-Strategie sein. In modernen DevSecOps-Workflows werden Si­cher­heits­prü­fun­gen deshalb direkt in Ent­wick­lung, Build-Prozess und De­ploy­ment in­te­griert. So lassen sich Risiken früh erkennen, bevor ein Container-Image in pro­duk­ti­ve Um­ge­bun­gen gelangt.

Wichtige Si­cher­heits­maß­nah­men sind:

• Image Scanning: Container-Images werden au­to­ma­ti­siert auf bekannte Schwach­stel­len, veraltete Pakete, unsichere Ab­hän­gig­kei­ten oder pro­ble­ma­ti­sche Kon­fi­gu­ra­tio­nen geprüft. Diese Prüfung kann bereits in der CI/CD-Pipeline statt­fin­den, sodass feh­ler­haf­te oder unsichere Images gar nicht erst frei­ge­ge­ben werden.
• Schlanke Images: Container-Images sollten nur die Kom­po­nen­ten enthalten, die für die jeweilige Anwendung tat­säch­lich benötigt werden. Je kleiner das Image, desto kleiner ist in der Regel auch die An­griffs­flä­che.
• Rootless Container: Container-Prozesse können ohne um­fas­sen­de Root-Rechte auf dem Host­sys­tem aus­ge­führt werden. Das reduziert Risiken, falls ein Container kom­pro­mit­tiert wird.
• Least-Privilege-Prinzip: Jeder Container erhält nur die Rechte, Netz­werk­zu­grif­fe und Sys­tem­funk­tio­nen, die er für seine Aufgabe wirklich benötigt.
• Secret Ma­nage­ment: Zu­gangs­da­ten, API-Schlüssel, Tokens oder Zer­ti­fi­ka­te sollten nicht fest im Container-Image oder im Quellcode ge­spei­chert werden. Statt­des­sen werden sie über dafür vor­ge­se­he­ne Me­cha­nis­men der je­wei­li­gen Plattform kon­trol­liert be­reit­ge­stellt und verwaltet.

Moderne Container-Si­cher­heit umfasst nicht nur den laufenden Container, sondern auch die gesamte Software Supply Chain inklusive Build-Prozess, Ab­hän­gig­kei­ten und Container-Images. Wichtige Bausteine sind:

• SBOM (Software Bill of Materials): Eine voll­stän­di­ge Liste aller ent­hal­te­nen Bi­blio­the­ken und Ab­hän­gig­kei­ten eines Container-Images.
• Image Signing (z. B. Cosign / Sigstore): Stellt sicher, dass ein Container-Image un­ver­än­dert und au­then­tisch ist.
• SLSA-Pro­ven­an­ce: Do­ku­men­tiert, wie und wo ein Container gebaut wurde und schützt die Build-Pipeline vor Ma­ni­pu­la­tio­nen.

Ziel dieser Ansätze ist es, si­cher­zu­stel­len, dass nur ve­ri­fi­zier­te und un­ver­än­der­te Artefakte in Pro­duk­ti­on gelangen.