Seite wählen

NETWAYS Blog

Kubernetes 101: Aufbau eines K8s-Cluster und die Möglichkeiten der API

This entry is part 2 of 7 in the series Alles rund um Kubernetes

In meinem ersten Blogpost ging es zuerst einmal darum zu klären, was Kubernetes denn eigentlich ist. Jetzt, wo wir ergründet haben, welche Ansätze und Ideen Kubernetes verfolgt und warum diese sinnvoll sein können, gehen wir einen Schritt weiter, und schauen uns an, wie diese umgesetzt werden. Dafür wollen wir zwei Aspekte betrachten: Zum Einen der Aufbau eines Kubernetes-Clusters selbst, inklusive aller Teilbausteine, die für den reibungslosen Betrieb benötigt werden. Zum Anderen die im letzten Blogpost bereits mehrfach erwähnte API, wir als Schnittstelle nutzen und die uns eine ganze Bandbreite an API-Ressourcen anbietet, mit denen wir auf Kubernetes arbeiten können. Let’s get going!

Aufbau eines Kubernetes-Clusters

Beginnen wir mit einem sog. „Ten-Thousand Foot View„, um uns den groben Aufbau eines Clusters auf Infrastrukturebene vor Augen zu führen:

Überblick eines Clusteraufbaus, bestehend aus Dataplane, Workernodes und Loadbalancer

Wir sehen hier ein Cluster bestehend aus 8 Nodes – drei sog. Leader-Nodes und fünf Follower-Nodes. Die Leader-Nodes bilden zusammen die sog. Controlplane des Clusters und stellen Dienste wie clusterinternes DNS und die Kubernetes-API bereit. Um die API und damit letzten Endes das Cluster hochverfügbar zu machen, wird der Controlplane ein Loadbalancer vorgelagert. In Cloud-Umgebungen ist dies oft per Default die bereitgestellte Lösung des jeweiligen Providers, in eigenen Rechenzentren oder on-premise kann hierfür auf Lösungen wie HAProxy oder MetalLB zurückgegriffen werden. Best Practices diktieren, dass auf den Leader-Nodes möglichst keine Anwendungen deployed werden sollten, die nicht für den Betrieb des Clusters selbst benötigt werden.

Hierfür sind die fünf Follower-Nodes gedacht, die mit der Kubernetes-API ebenfalls via Loadbalancer interagieren und die für den jeweiligen Node gescheduleten Anwendungen ausführen. Auf diesen Nodes können beliebige Anwendungen entsprechend der jeweils verfügbaren Ressourcen deployed werden. Die API in der Controlplane kümmert sich hierbei um ein passendes Scheduling, damit Ressourcen auf den Follower-Nodes nicht erschöpft werden und angegebene Voraussetzungen wie bspw. spezielle benötigte Hardware (GPU, SSD, etc.) auf dem jeweiligen Node erfüllt werden.
Die letzte im Schaubild dargestellte Komponente stellt eine lokale Terminalsession auf Seiten eines Endnutzers dar. Dieser kommuniziert via kubectl mit der Softwareschnittstelle, dem de-facto Standardtool für Interaktion mit der API von außerhalb des Clusters.

Doch welche Komponenten laufen denn nun auf den jeweiligen Node-Klassen? Gehen wir doch einmal etwas weiter ins Detail:

Wir sehen hier exemplarisch jeweils einen Leader und Follower-Node als VMs in der Detailansicht, mit all den Anwendungen, die auf den jeweiligen Node-Klassen typischerweise installiert sind. Gehen wir die verschiedenen Anwendungen doch einmal durch:

  • etcd – Key/Value-Store für den Zustand und die Historie der Kubernetes-API; Wird normalerweise auf den Leader-Nodes installiert, kann allerdings auch auf externe Maschinen ausgelagert werden
  • kube-apiserver – PI-Server des Kubernetes-Clusters; Wird für Hochverfügbarkeit auf allen Leader-Nodes installiert
  • kube-scheduler – Kümmert sich um das Scheduling der in das Cluster deployten Anwendungen; Wird auf Leader-Nodes installiert
  • kube-controller-manager – Ein Bündel an sog. Kubernetes-Controllern, das sich um die Verwaltung verschiedener Kubernetes-Ressourcen kümmert; Wird auf Leader-Nodes installiert
  • kubeletKommuniziert mit der API und der lokalen Container-Runtime, um Container auf den Nodes auszuführen; Wird auf allen Nodes installiert
  • kube-proxyRoutet Netzwerk-Traffic zu Containern, sobald dieser auf den jeweiligen Nodes ankommt; Wird auf allen Nodes installiert
  • Container Runtime – Im Beispiel containerd; andere Implementierungen sind möglich, bspw. CRI-o; Wird auf allen Nodes installiert

Zu erwähnen ist, dass nicht alle Cluster so aussehen müssen. Beispielsweise ließe sich auch eine Controlplane umsetzen, auf der keinerlei Container ausgeführt werden – in diesem Fall könnte man auf die Installation von kubelet, kube-proxy und containerd auf Leader-Nodes verzichten (für eine Referenzinstallation s. Kubernetes the Hard Way auf GitHub). Auf Clustern in der Cloud wird man außerdem fast immer einen sog. cloud-controller-manager auf Leader-Nodes finden, der gewisse Funktionalitäten im Cloud-Bereich integriert, bspw. automatische Provisionierung benötigter Loadbalancer in der hostenden Cloud.

Auch können sich die genauen Ausprägungen einer Kubernetes-Installation je nach Kubernetes-Distribution unterscheiden – momentan listet die CNCF 59 zertifizierte Distributionen. K3s bspw. bündelt die verschiedenen Komponenten in eine Binary, was den Betrieb im Alltag etwas erleichtern kann und den Ressourcen-Fußabdruck des Clusters senkt.

Die Kubernetes‘ API – endlose Weiten

Haben wir unser Cluster nun wie oben skizziert (oder ganz anders) installiert, möchten wir natürlich mit ihm interagieren – hierfür gibt es verschiedene Möglichkeiten, angefangen bei cURL über das offizielle Kubernetes Dashboard bis zu Wrappern für das lokale Terminal. Letzteres ist der gängigste Weg – fast alle Tutorials und technische Dokumentationen zu Kubernetes und darauf zu installierende Anwendungen erwähnen kubectl, was sich auf jedem gängigen Betriebssystem paketiert installieren lassen sollte. Haben wir kubectl lokal installiert und eingerichtet (wir benötigen eine sog. kubeconfig, die Verbindungsinformationen für unser(e) Cluster enthält), können wir uns zum ersten Mal die API anschauen:

beispielhafter Aufruf von kubectl api-resources mit wordcount nach Zeilen: 70

Je nach Cluster (im Beispiel ein Rancher Desktop Cluster) scheint uns Kubernetes zwischen 60 und 70 verschiedene API-Objekte anzubieten! Wo also anfangen und wo aufhören? Oder gleich alle 70 behandeln? Fangen wir doch einfach mit der kleinsten Einheit an Workload an, die K8s für uns bereit hält – dem Pod. Ein Pod kapselt einen oder mehrere Container in einem Bündel, das sich Netzwerk- und Speicherressourcen teilt.

Daraus folgt, dass alle Container eines Pods immer auf demselben Node gescheduled werden. Ein Pod alleine profitiert allerdings noch nicht von Kubernetes‘ Orchestrierungsmöglichkeiten – ist bspw. der hostende Node nicht erreichbar, können wir auch die in unserem Pod laufenden Anwendungen nicht mehr erreichen.

Wir benötigen also eine weitere Abstraktionsebene, die es uns erlaubt, mehrere identische Pods auf verschiedene Nodes zu schedulen: das sog. Deployment. Ein Deployment definiert ein Pod-Template, sowie eine Anzahl an gewünschten Repliken und weitere Konfiguration, die von Kubernetes zur Orchestrierung des Deployments genutzt wird. Unter der Haube wird dann vom API-Server ein ReplicaSet erzeugt, das die gerenderte Version des Pod-Templates enthält.

Auf diese Weise ermöglicht eine Deployment-Ressource uns nicht nur die Ausführung mehrerer Repliken eines einzelnen Pods, sondern auch eine Versionierung verschiedener ReplicaSets – wieviele genau von der API gespeichert werden, hängt von den Einstellungen des API-Servers zusammen. Hier nochmal ein Schaubild zu den Zusammenhängen:

Ein Überblick der Zusammenhänge zwischen Deployments, ReplicaSets und Pods in Kubernetes

Zu sehen ist ein Deployment mit drei dazugehörigen ReplicaSets, die sich in der Anzahl der definierten Replicas unterscheiden (Kubernetes erstellt bei jeglicher Änderung eines Deployments ein neues ReplicaSet, nicht nur bei Änderung der Replicas). Das momentan aktive ReplicaSet wiederum verwaltet der Konfiguration entsprechend fünf Pods.

Möchte man seine deployten Anwendungen nun untereinander oder für Endnutzer außerhalb des Clusters verfügbar machen, kommen Services ins Spiel. Ein Service ist eine API-Ressource, die einen gewissen Pool an Pods als Endpoints definiert und für diese als Round-Robin Loadbalancer fungiert. Auf diese Weise benötigt man nur eine IP, um zuverlässig einen funktionalen Pod eines Deployments zu erreichen. Kubernetes kümmert sich hierbei automatisch darum, Traffic nur zu funktionalen Pods weiterzuleiten.
Es gibt drei Arten von Services:

  • ClusterIP – der Service erhält eine innerhalb des Clusters erreichbare IP-Adresse, ist von außerhalb des Clusters aber nicht ohne Weiteres zu erreichen
  • NodePort – der Service wird auf jedem Node auf einem zufälligen, hohen Port (ca. 30.000+) verfügbar gemacht
  • Loadbalancer – eine Erweiterung des NodePort-Typs, wobei den Ports ein Loadbalancer vorgelagert wird; funktioniert am reibungslosesten in Public Clouds

Zusätzlich gibt es die Möglichkeit, HTTP-Traffic anstatt mittels Loadbalancer auf L4 mit einem sog. Ingress auf L7 zu routen – die Konfiguration unterscheidet sich hierbei abhängig vom genutzten IngressController.

Weitere nennenswerte, grundlegende API-Ressourcen innerhalb von Clustern wären bspw. Namespaces zur Trennung von anwendungslogisch zusammenhängenden Deployments etc. sowie zur Umsetzung von role-based access control (RBAC), Secrets zur Bereitstellung vertraulicher Daten wie bspw. Passwörtern, Zertifikaten, oder Token, und ConfigMaps für häufig genutzte Konfigurationssnippets. Wer mitgezählt hat wird merken, dass wir gerade erst bei 7 von den oben angezeigten 70 Ressourcentypen angekommen sind – und das ist noch lange nicht das Ende der Fahnenstange, da eine der Stärken der Kubernetes-API schließlich ihre Erweiterung durch sog. CustomResourceDefinitions (CRDs) ist. Für einen ersten Einblick soll der momentane Stand trotzdem fürs Erste genügen.

kubectl – das Schweizer Taschenmesser für Kubernetes

Bereits im letzten Absatz eingangs erwähnt, ist jetzt der Moment für kubectl gekommen, das offizielle Kommandozeilentool für den täglichen Umgang mit Kubernetes und seiner API. Ich könnte an dieser Stelle mehrere 1000 Wörter über den Gebrauch schreiben und trotzdem noch sehr viel unerwähnt lassen, und genau aus diesem Grund folgt nun gemäß dem Motto „Ein Bild sagt mehr als tausend Worte“ lediglich eine Auflistung einiger gängiger und oft genutzter kubectl Kommandos, um einen ersten Eindruck von der Nutzung des Tools zu bekommen.

Screenshot eines Terminals mit mehreren Ausgaben von kubectl

Hier zu sehen sind einige der häufigsten Kommandos, zu denen neben get und create wohl auch noch apply, logs und describe gehören dürften. Neben dem expliziten (imperativen) Erstellen von API-Ressourcen via CLI können mit kubectl auch bestehende Kubernetes-Manifeste (in YAML oder JSON) in das Cluster „gepusht“ werden, was einem deklarativen Ansatz entspricht und in der Praxis der gängigere Weg ist.

Für heute war das aber genug trockene Theorie rund um Architektur, API-Aufbau und Clusterkomponenten – im nächsten Teil der Serie werden wir uns genauer anschauen, wie wir uns denn nun basierend auf der in diesem Artikel erläuterten Architektur unser eigenes Cluster installieren können, entweder auf lokaler Infrastruktur, in der Cloud (z.B. Managed Kubernetes bei NMS), oder auf deinem persönlichen Rechner! Abonniere also gerne auch den RSS-Feed unseres Blogs und sei bereit für den nächsten Artikel der Kubernetes 101 Reihe!

Daniel Bodky
Daniel Bodky
Platform Advocate

Daniel kam nach Abschluss seines Studiums im Oktober 2021 zu NETWAYS und beriet zwei Jahre lang Kunden zu den Themen Icinga2 und Kubernetes, bevor es ihn weiter zu Managed Services zog. Seitdem redet und schreibt er viel über cloud-native Technologien und ihre spannenden Anwendungsfälle und gibt sein Bestes, um Neues und Interessantes rund um Kubernetes zu vermitteln. Nebenher schreibt er in seiner Freizeit kleinere Tools für verschiedenste Einsatzgebiete, nimmt öfters mal ein Buch in die Hand oder widmet sich seinem viel zu großen Berg Lego. In der wärmeren Jahreszeit findet man ihn außerdem oft auf dem Fahrrad oder beim Wandern.

DockerCon 2022: Wie geht Containersecurity?

Buzzwords wie Software Supply Chain, Container Security Scanning oder Software Bill of Materials (SBOM) sind in den vergangenen zwei Jahren vermehrt in aller Munde, nicht zuletzt aufgrund des anhaltenden Trends zur Containerisierung vormals monolithischer Anwendungen und deren Betrieb als sog. Microservices. Allerdings kann nach wie vor nicht jeder, der auf die ein oder andere Weise mit Docker oder Containern im Allgemeinen zu tun hat, etwas mit diesen Begriffen anfangen. Aus diesem Grund habe ich den Fokus meines virtuellen Besuchs der diesjährigen DockerCon auf genau diesen Themebereich – Containersecurity – gelegt und möglichst viele Best Practices für Dich zusammengefasst.

 

Die Ausgangslage

Die großen Sicherheitslücken der vergangenen zwei Jahre, sei es der Solarwinds-Breach oder die Log4J/Log4Shell-Exploits haben einmal mehr schmerzlich bewusst gemacht: In fast jedem Softwareprodukt, egal ob proprietär oder Open Source, befinden sich zahlreiche mehr oder weniger gut gepflegte Abhängigkeiten verschiedenster Maintainer – in vielen Applikationen stecken bis zu 80% Open Source Code, die es „auf dem Schirm“ zu behalten gilt. Dies gilt natürlich auch für Container(-images), die letzten Endes nichts anderes tun, als die Applikation zu bündeln und (weitestgehend) losgelöst vom ausführenden Hostsystem ausführbar zu machen.

Dennoch gelten Container paradoxerweise oft als besonders sicher, sei es aufgrund der von außen wahrgenommenen „Kapselung“ oder der geringen Größe – soviel potentiell vulnerable oder bösartige Software kann da doch gar nicht drinstecken, oder? Mögen diese Wahrnehmungen in der Theorie und im Bestfall auch stimmen, sieht die Praxis in den allermeisten Fällen anders aus, wie die ein oder andere Keynote im Rahmen der DockerCon gezeigt hat.

Laut SysDig, einem Spezialisten für Cloudsecurity, laufen 58% der in den einschlägigen Containerregistries (DockerHub, Google, Github, etc.) verfügbaren Containerimages als root, anstatt einen geeigneteren, unprivilegierten Nutzer zu verwenden. Außerdem beinhalten selbst die offiziellen, von den Registries kuratierten Containerimages beliebter Frameworks oder Distributionen dutzende detektierbare Schwachstellen.

Offensichtlich gibt es also zum Einen ein falsches Gefühl von Sicherheit innerhalb der Nutzergemeinschaft von Containern, zum Anderen aber schlichtweg keine Blaupause oder „OneFitsAll“-Lösung, die für beliebige Container(-images) absolute Sicherheit verspricht. Nur eine Sache ist klar: „Hinten“ anzufangen, ist nicht rentabel – Container einfach zu deployen und dann im Betrieb nach Sicherheitslücken zu suchen, ist teuer, erzeugt vermeidbaren zusätzlichen Aufwand und nimmt Flexibilität. Die Absicherung der Container muss „nach links“ geschoben werden, möglichst an den Beginn der Containerisierung. Doch wo ansetzen?

 

Die Möglichkeiten

Um den Ursprung für Schwachstellen in Container(-images) und damit einhergehend mögliche Ansatzpunkte zur Absicherung zu identifizieren, muss man die „Lebensphasen“ eines Container(-images) verstehen. Diese lassen sich kurz und bündig wie folgt darstellen:

 

  • Bau des Images (lokal oder via CI/CD)
  • Distribution des Images – Push in eine Registry (Self-hosted oder bei einem Anbieter), Pull von Usern/Programmen
  • Deployment des Images (Openshift, (Managed) Kubernetes, etc.) und Betrieb des Containers

 

An dieser Stelle wird hoffentlich klar, warum ich permanent „Container(-image)“ schreibe – abhängig von der betrachteten Lebensphase haben wir es beim Thema Containersicherheit entweder mit einem erstellten Image oder mit einem laufenden Container, quasi einer Instanziierung dieses Images zu tun. Mit dieser Aufschlüsselung in verschiedene Abschnitte können wir uns nun mögliche Schritte zur Absicherung unserer Container anschauen.

Containerimages werden entweder lokal von Entwickler:innen, DevOps-Engineers, etc. auf Grundlage eines sog. Dockerfiles gebaut – alternativ lässt sich dieser Vorgang aber auch von CI/CD Pipelines umsetzen, wenn man den Dockerfile und andere benötigten Ressourcen bspw. in GitLab eincheckt. Die meisten Möglichkeiten zur Absicherung des späteren Container(-images) ergeben sich bereits in diesem ersten Schritt – der Quellcode der zu containerisierenden Applikation liegt vor, ebenso die Definition des Containers selbst, und auch möglicherweise vulnerable oder bösartige Abhängigkeiten wurden noch nicht in das spätere Containerimage eingebettet.

Ist das Containerimage lokal oder in einer Pipeline gebaut worden, muss man es zur späteren Nutzung in Produktion in eine Containerregistry übertragen. Diese kann entweder selbst gehosted werden, als private, aber gemanagte Instanz in der Cloud laufen oder öffentlich von jedem beliebigen Nutzer einsehbar sein. Auch bei diesem Vorgang gibt es Möglichkeiten, die Supply Chain zwischen Entwickler und Endnutzer abzusichern.

Auch wenn im Dockerfile gewisse Best Practices befolgt werden, kann der Container diese in vielen Fällen beim Deployment überschreiben – das letzte Wort haben hierbei immer Kubernetes, Openshift, Docker Desktop und Konsorten. Aus diesem Grund müssen einige der Überlegungen, die in der Build-Phase des Containerimages stattgefunden haben, auch hier noch einmal herangezogen, betrachtet und evaluiert werden, um die für die konkrete Nutzung besten Einstellungen und Kompromisse zu finden.

Ist der Container erst einmal deployed, gibt es nicht mehr viele Möglichkeiten, ihn „von innen“ weiter abzusichern. Dennoch kann und sollte man sich fortlaufend Gedanken bspw. um die Erreichbarkeit innerhalb des Clusters, des Netzwerkes, der Cloud etc. machen, Regeln nachziehen wo nötig und natürlich auch Update- und Backupstrategien im Hinterkopf behalten. Am Ende des Tages merkt man spätestens jetzt: Nach dem Deployment eines Containers seine Sicherheit zu überprüfen und zu garantieren, ist nicht sinnvoll – wir brauchen einen Left Shift.

 

Die Umsetzung

Buildphase

Nach viel Theorie und Konjunktiv können wir uns jetzt konkrete Umsetzungsmöglichkeiten der besprochenen Ansätze anschauen. Beginnen werden wir „ganz links“ beim Bau der Containerimages. Vieles lässt sich hier über verschiedene Direktiven im genutzten Dockerfile festlegen – Docker listet alle möglichen Direktiven sowie sinnvolle Best Practices und Caveats in der Docker Dokumentation auf. Für uns besonders interessant sind die Direktiven ADD, COPY und USER. Wie eingangs erwähnt, nutzen mehr als die Hälfte aller Containerimages per Default den root Nutzer innerhalb des Containers, obwohl das in vielen Fällen gar nicht notwendig wäre – auf einem klassischen Server läuft ein Apache2 Webserver schließlich auch als User apache, warum sollte/müsste das innerhalb eines Containers bspw. auf Debian-Basis anders sein?

Die anderen beiden erwähnten Direktiven beziehen sich auf die Abwägung, ob man gewisse Verzeichnisse und Dateien aus seiner Entwicklungsumgebung denn tatsächlich im endgültigen Container braucht – oder ob man die Applikation direkt lokal baut, und lediglich die fertige Binary via COPY in das Containerimage überträgt. In diesem Fall muss man natürlich darauf achten, dass etwaige zur Laufzeit benötigte Tools (ich meine dich, curl) und Bibliotheken sich auch im endgültigen Containerimage befinden. Alternativ kann man innerhalb eines Dockerfiles eine build und eine run Umgebung schaffen – auf diese Weise kann man die Applikation innerhalb des Containers bauen und im Anschluss lediglich die benötigten binären Artefakte und andere benötigten Ressourcen in das Lauzeitimage kopieren. Für diese Vorgehensweise würde es sich anbieten, das Entwicklungsrepository via ADD in die build Umgebung des Containerimages zu übertragen.

Diese Vorgehensweise bringt uns direkt zur nächsten „beliebten“ Unsicherheit in Container(-images): Lokal hinterlegte Credentials, Entwicklertokens, Cloudzugänge etc. Es gibt vermutlich keine Art von geheimen Daten, die nicht bereits versehentlich in Containerimages „vergessen“ wurde. Das kann schnell passieren – ein Entwickler nutzt ein Shellscript mit Zugangsdaten, um von seiner Entwicklungsumgebung in ein Testcluster zu deployen, eine .yaml-Datei, um Daten aus einer Entwicklerdatenbank zu lesen etc. Im „schlimmsten Fall“ überträgt er wissentlich eine Datei mit Zugangsdaten, die die containerisierte Applikation später in Produktion nutzen soll, oder hinterlegt sensible Daten im Containerimage als Umgebungsvariable mittels ENV.

Zur Bewältigung dieser Problematik gibt es die Möglichkeit, ähnlich wie eine .gitignore Datei für Git-Repositories eine .dockerignore Datei für den Buildvorgang eines Containerimages zu hinterlegen. Alle in dieser Datei aufgeführten Dateien und Verzeichnisse werden vom Dockerdaemon bei der Verarbeitung des Build-Contexts, von ADD und von COPY Direktiven ignoriert und finden sich somit zu keinem Zeitpunkt im Containerimage wieder. Dringend benötigte Umgebungsvariablen zur Konfiguration der containerisierten Applikation können auch zum Zeitpunkt des Deployments noch übergeben werden, bspw. mittels des Parameters -e via Docker-CLI oder dem Einlesen von Secrets als Umgebungsvariablen in Kubernetes.

Grundlegende Maßnahmen wie die Nutzung eines passenden Base-Images in der FROM Direktive (es muss nicht immer debian:buster oder ubuntu:20.04 sein), das Vermeiden der Öffnung unbenötigter Ports via EXPOSE sowie der Nutzung sog. Kannibalen-Tags (latest zeigt nach jedem Imageupdate auf eine neue Version) sollten darüber hinaus natürlich immer befolgt und beachtet werden.

Distributionsphase

Haben wir nun lokal oder in der Pipeline ein in sich möglichst sicheres Containerimage gebaut, muss es auf die eine oder andere Art und Weise seinen Weg in eine Containerregistry finden, um von anderen Nutzern heruntergeladen und deployed werden zu können. Für diese Vorgänge werden einem von den meisten Containerregistries Werkzeuge an die Hand gegeben, mit deren Hilfe wir den Prozess des Up-/Downloads von Containerimages absichern können.

Letzten Endes sind Containerregistries nichts anderes als APIs mit der Fähigkeit, Nutzer zu authentifizieren und zu authorisieren, Containerimages in Empfang zu nehmen, zu speichern und deren Versionierung im Blick zu behalten. Wie immer, wenn man über das Internet mit einer API spricht, gilt: HTTPS ist Pflicht! Darüber hinaus bieten Registries verschiedene Möglichkeiten, zusätzliche Maßnahmen gegen die Verbreitung unsicherer Images oder die Manipulation vorhandener Containerimages zu treffen. So können Imageregistries oftmals alle verwalteten Containerimages auf bekannte Schwachstellen scannen und den Download solcher Images durch Endnutzer untersagen. Auch die digitale Signierung von verwalteten Containerimages ist oftmals möglich, z.B. mittels sigstore und cosign.

Deploymentphase

Wird unser Containerimage nun im Rahmen eines Kubernetes-Deployments oder Docker-CLI-Befehls aus der Registry gepulled und deployed, haben wir einmal mehr die Möglichkeit, Sicherheit zu forcieren: Wie bereits erwähnt, können wir zum Einen die Voreinstellungen in Hinblick auf Umgebungsvariablen, User- und Gruppenkontext uvm. überschreiben, zum Anderen bietet natürlich auch die Absicherung der ausführenden Infrastruktur selbst die Möglichkeit, dass Deployment so sicher wie möglich zu gestalten.

Hierzu zählen z.B. die Nutzung sog. rootless Container, die von einem Container Runtime Interface (CRI) wie Docker oder containerd ausgeführt werden, die selbst nicht im root Kontext laufen. Auch die Nutzung restriktiver Netzwerk- und Firewallpolicies kann dabei helfen, die Risiken durch möglicherweise vulnerable oder bösartige Container zu minimieren. Konfiguration und Forcierung dieser Maßnahmen innerhalb eines Clusters können schnell zur Sisyphusarbeit werden – hier kann ein gemanagtes Kubernetes-Cluster von Vorteil sein, bspw. Managed Kubernetes von NETWAYS Web Services. Darüber hinaus sollte man eine nachhaltige Update-Strategie für seine Containerimages verfolgen: Es gilt, einen guten Kompromiss zwischen regelmäßigen Updates zu finden, aber nicht sofort jede neue Version (und deren evtl. neu eingeführte Schwachstellen) in Produktion zu deployen.

 

Das Fazit

Container(-images) sicher zu erstellen, zu verwalten und zu deployen ist ein langer Weg voller Stolpersteine. Wie so oft beim Thema Sicherheit wird man die 100% aller Voraussicht nach nicht erreichen – Nichtexistenz von Sicherheitslücken lässt sich nun einmal nicht beweisen. Dennoch habe ich Dich hoffentlich für das Thema und die teils falschen, gängigen Annahmen und Praktiken sensibilisieren können und nebenbei einige Best Practices an die Hand gegeben, die das Risiko durch vulnerable Container deutlich verringern.

Solltest Du nun mehr über den Vorgang des Imagebaus, den Betrieb von Containern in Kubernetes oder Containerisierung im Allgemeinen erfahren wollen, schau Dir doch einmal unser Kubernetes Schulungsangebot von NETWAYS an. In diesem eintägigen Workshop vermittle ich Dir praxisnah und einsteigerfreundlich alles, was Du für die ersten eigenen Schritte mit Docker und Kubernetes wissen musst. Ich freue mich auf Dich!

Daniel Bodky
Daniel Bodky
Platform Advocate

Daniel kam nach Abschluss seines Studiums im Oktober 2021 zu NETWAYS und beriet zwei Jahre lang Kunden zu den Themen Icinga2 und Kubernetes, bevor es ihn weiter zu Managed Services zog. Seitdem redet und schreibt er viel über cloud-native Technologien und ihre spannenden Anwendungsfälle und gibt sein Bestes, um Neues und Interessantes rund um Kubernetes zu vermitteln. Nebenher schreibt er in seiner Freizeit kleinere Tools für verschiedenste Einsatzgebiete, nimmt öfters mal ein Buch in die Hand oder widmet sich seinem viel zu großen Berg Lego. In der wärmeren Jahreszeit findet man ihn außerdem oft auf dem Fahrrad oder beim Wandern.

Evolution of a Microservice-Infrastructure by Jan Martens | OSDC 2019

This entry is part 2 of 6 in the series OSDC 2019 | Recap

YouTube player

 

At the Open Source Data Center Conference (OSDC) 2019 in Berlin, Jan Martens invited to audience to travel with him in his talk „Evolution of a Microservice-Infrastructure”. You have missed him speaking? We got something for you: See the video of Jan‘s presentation and read a summary (below).

The former OSDC will be held for the first time in 2020 under the new name stackconf. With the changes in modern IT in recent years, the focus of the conference has increasingly shifted from a mainly static infrastructure approach to a broader spectrum that includes agile methods, continuous integration, container, hybrid and cloud solutions. This development is taken into account by changing the name of the conference and opening the topic area for further innovations.

Due to concerns around the coronavirus (COVID-19), the decision was made to hold stackconf 2020 as an online conference. The online event will now take place from June 16 to 18, 2020. Join us, live online! Save your ticket now at: stackconf.eu/ticket/


 

Evolution of a Microservice-Infrastructure

Jan Martens signed up with a talk titled “Evolution of a Microservice Infrastructure” and why should I summarize his talk if he had done that himself perfectly: “This talk is about our journey from Ngnix & Docker Swarm to Traefik & Nomad.”

But before we start getting more in depth with this talk, there is one more thing to know about it. This is more or less a sequel to “From Monolith to Microservices” by Paul Puschmann a colleague of Jan Martens, but it’s not absolutely necessary to watch them in order or both.

YouTube player

 

So there will be a bunch of questions answered by Jan during the talk, regarding their environment, like: “How do we do deployments? How do we do request routing? What problems did we encounter, during our infrastructural growth and how did we address them?“

After giving some quick insight in the scale he has to deal with, that being 345.000 employees and 15.000 shops, he goes on with the history of their infrastructure.

Jan works at REWE Digital, which is responsible for the infrastructure around services, like delivery of groceries. They started off with the takeover of an existing monolithic infrastructure, not very attractive huh? They confronted themselves with the question: “How can we scale this delivery service?” and the solution they came up with was a micro service environment. Important to point out here, would be the use of Docker/Swarm for the deployment of micro services.

Let’s skip ahead a bit and take a look at the state of 2018 REWE Digital. Well there operating custom Docker-Environment consists of: Docker, Consul, Elastic Stack, ngnix, dnsmasq and debian

Jan goes into explaining his infrastructure more and more and how the different applications work with each other, but let’s just say: Everything was fine and peaceful until the size of the environment grew to a certain point. And at that point problems with nginx were starting to surface, like requests which never reached their destination or keepalive connections, which dropped after a short time. The reason? Consul-template would reload all ngnix instances at the same time. The solution? Well they looked for a different reverse proxy, which is able to reload configuration dynamically and best case that new reverse proxy is even able to be configured dynamically.

The three being deemed fitting for that job were envoy, Fabio and traefik, but I have already spoiled their decision, its treafik. The points Jan mentioned, which had them decide on traefik were that it is dynamically configurable and is able to reload configuration live. That’s obviously not all, lots of metrics, a web ui, which was deemed nice by Jan and a single go binary, might have made the difference.

Jan drops a few words on how migration is done and then invests some time in talking about the benefits of traefik, well the most important benefit for us to know is, that the issues that existed with ngnix are gone now.

Well now that the environment was changed, there were also changes coming for swarm, acting on its own. The problems Jan addresses are a poor container spread, no self-healing, and more. You should be able to see where this is going. Well the candidates besides Docker Swarm are Rancher, Kubernetes and Nomad. Well, this one was spoiled by me as well.

The reasons to use nomad in this infrastructure might be pretty obvious, but I will list them anyway. Firstly, seamless consul integration, well both are by HashiCorp, who would have guessed. Nomad is able to selfheal and comes in a single go binary, just like traefik. Jan also claims it has a nice web UI, we have to take his word on that one.

Jan goes into the benefits of using Nomad, just like he went into the benefits of ngnix and shows how their work processes have changed with the change of their environment.

This post doesn’t give enough credit to how much information Jan has shared during his talk. Maybe roughly twenty percent of his talk are covered here. You should definitely check it out the full video to catch all the deeper more insightful topics about the infrastructure and how the applications work with each other.

Alexander Stoll
Alexander Stoll
Consultant

Alex hat seine Ausbildung zum Fachinformatiker für Systemintegration bei NETWAYS Professional Services abgeschlossen und ist nun im Consulting tätig. Vereinzelt kommt es auch vor das er an Programmierprojekten mitarbeitet. Auch privat setzt er sich sehr viel mit Informationstechnologie auseinander, aber jenseits davon ist auch viel Zeit für Fußballabende, Handwerkerprojekte und das ein oder andere Buch.

Docker – ein erster Eindruck!

Ich habe in den letzten Monaten meiner Ausbildung schon viel über verschiedene Software, Strukturen und Programiersprachen gelernt. Seit einigen Wochen arbeite ich in der Managed Services-Abteilung mit Docker und bin wirklich fasziniert, was Docker alles kann und wie es funktioniert.

Was genau ist Docker?

Docker ist eine Containerisierungstechnologie, die die Erstellung und den Betrieb von Linux-Containern ermöglicht, die man nicht mit virtuellen Maschinen verwechseln sollte.

Docker vereinfacht die Bereitstellung von Anwendungen, weil sich Container, die alle nötigen Pakete enthalten, leicht als Dateien transportieren und installieren lassen. Container gewährleisten die Trennung und Verwaltung der auf einem Rechner genutzten Ressourcen. Das beinhaltet laut Aussage der Entwickler: Code, Laufzeitmodul, Systemwerkzeuge, Systembibliotheken – alles was auf einem Rechner installiert werden kann.

Welche Vorteile bringt Docker?

Ein Vorteil ist, dass man diese Container sehr flexibel erstellen, einsetzen, kopieren und zwischen Umgebungen hin- und her verschieben kann. Sogar ein Betrieb in der Cloud ist dadurch möglich und eröffnet viele neue Möglichkeiten. Das Ausführen verschiedener Container bietet zusätzlich einige Sicherheitsvorteile. Wenn man Anwendungen in verschiedenen Containern ausführt, hat jeder Container nur Zugriff auf die Ports und Dateien, die der andere Container explizit freigibt.

Darüber hinaus bieten Container ein höheres Maß an Kontrolle darüber, welche Daten und Software auf dem Container installiert sind. Schadsoftware, die in einem Container ausgeführt wird, wirkt sich nicht auf andere Container aus.

Was ist der Unterschied zwischen Docker-Containern und virtuellen Maschinen?

Virtuelle Maschinen enthalten von der simulierten Hardware, über das Betriebssystem bis zu den installierten Programmen eine große Menge an Informationen. Die Folge: Sie verbrauchen viel Speicherplatz und Ressourcen.

Der große und schöne Unterschied zu herkömmlichen virtuellen Maschinen ist, dass die Container kein Betriebssystem beinhalten und booten müssen, sondern lediglich die wichtigen Daten der Anwendung enthalten. Wollten wir früher beispielsweise eine Datenbank und einen Webserver getrennt voneinander starten, benötigen wir zwei VMs. Mit Docker werden hier nur noch zwei Container benötigt, ohne dass man die VMs booten muss, die kaum Ressourcen verbrauchen – im Vergleich zu den virtuellen Maschinen.

Virtuelle Maschinen jedoch haben nach wie vor ihre Daseinsberechtigung: zum Beispiel wenn auf einem Host mehrere Maschinen mit jeweils unterschiedlichen Betriebssystemen oder Hardware-Spezifikationen simuliert werden müssen. Denn ein Docker-Container enthält kein eigenes Betriebssystem und keine simulierte Hardware. Hier wird auf das System des Hosts zugegriffen, so dass alle Container Betriebssystem und Hardware gemeinsam nutzen.

Fazit zum Thema Docker:

Den Einsatz von Docker betrachte ich als sinnvoll. Es ergeben sich viele Vorteile und so ist es inzwischen möglich, eine Softwareumgebung rascher aufzubauen, ohne viel Speicherplatz und Ressourcen zu verbrauchen.