Seite wählen

NETWAYS Blog

Kubernetes 101: Wie sichere ich Kubernetes ab?

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

In meinen bisherigen Blogposts habe ich dir bereits einige wichtige Aspekte von Kubernetes näher gebracht. Von „Was ist Kubernetes“ über „Wie richte ich Kubernetes auf Linux ein“ zu „Wie installiere ich eine Anwendung in Kubernetes“. Im besten Fall hast du nun bereits Erfahrung in einer laufenden Umgebung sammeln können und bist bei der sogenannten „Day 2 Operation“, also dem alltäglichen, laufenden Betrieb angekommen. Eine Sache, die ich bisher allerdings ein wenig vernachlässigt habe, ist die Absicherung eines Kubernetes Clusters und der darin befindlichen Workloads.
In diesem Punkt ist Kubernetes‚ offener Standard Fluch und Segen gleichzeitig: Während die einfach erweiterbare Funktionalität ein großes Plus von Kubernetes ist, ist das Fehlen (fast) jeglicher Konfiguration von Security und Policing „out of the box“ definitiv ein großes Minus.
Deswegen zeige ich dir in diesem Beitrag, wie du in diesem Bereich nachbesserst!

Wie ist Kubernetes aufgebaut?

Wenn du meine bisherigen Blogposts verfolgt hast (oder bereits Erfahrung mit Kubernetes gesammelt hast) weißt du: Kubernetes ist ein verteiltes System.
Auf mehreren Nodes werden containerisierte Workloads geplant, die dann die eigentlichen Anwendungen ausführen. Hinzu kommen je nach Kubernetes-Distribution mehrere lokal auf dem jeweiligen Node laufende Services (bspw. Kubelet, kube-apiservercontainerd, etc.) sowie Container, die aufgrund ihrer Aufgaben manchmal erweiterte Privilegien auf den Nodes genießen. Etwa um den clusterinternen Netzwerkverkehr zu regeln oder im Cluster verteilten Speicher bereitstellen zu können.
Es gibt also eine einigermaßen klare Trennung zwischen Clusterinfrastruktur und Workloads, die in einer idealen Welt auch nur wenig miteinander zu tun haben (sollten). Eine Anwendung sollte schließlich in der Lage sein, ordnungsgemäß laufen zu können, ohne dass sie Kenntnisse über ihre Laufzeitumgebung (in diesem Fall Kubernetes) besitzt.
Wie klar diese Trennung in der Realität auch ausfallen mag, im Folgenden werde ich die zwei Welten und mögliche Ansatzpunkte für mehr Sicherheit getrennt voneinander betrachten.

Clustersicherheit bei Kubernetes

Wie bereits eingangs erwähnt, ist ein Kubernetes Cluster nach seiner Installation nicht unbedingt umfassend abgesichert – das beginnt bereits beim Zugriff auf das Kubernetes Cluster. Die kubeconfig, mit der du als Admin normalerweise arbeitest, ist mit maximalen Privilegien ausgestattet und sollte unter keinen Umständen verteilt oder von anderen Nutzern verwendet werden.
Deshalb solltest du weiteren User:innen einen alternativen Clusterzugriff (und damit verknüpfte Regeln) einrichten.

Zugriff und Zugriffskontrolle einrichten

Von Haus aus besitzt Kubernetes ein feingranular einstellbares RBAC-System (Role-based Access Control), mit dem sich grundsätzlich gut arbeiten lässt: Mittels (Cluster-)Roles, (Cluster-)RoleBindings und Usern bzw. ServiceAccounts lassen sich Verknüpfungen zwischen beliebigen Sets an Privilegien und einzelnen, im Cluster agierenden, Identitäten herstellen.
Für jede Gruppe an existierenden API-Objekten können durch Verbs die Privilegien entweder auf Namespace– oder auf Cluster-Ebene eingestellt werden. Die verfügbaren Verbs sind getlistcreateupdatepatchwatchdelete, und deletecollection und implizieren verschiedene Privilegien für die verknüpften API-Objekte.

Möchtest du eine hierarchische Struktur mehrerer Rollen erreichen, kannst du mehrere Clusterrollen zu einer übergeordneten Clusterrolle aggregieren. Auf diese Weise behältst du den Überblick, auch wenn die Anzahl an verfügbaren Rollen mit der Zeit wachsen sollte.
Überblick ist zudem ein gutes Stichwort, denn ab einer gewissen Anzahl an Rollen, Nutzern und Verknüpfungen zwischen den beiden Konzepten leidet unweigerlich die Übersichtlichkeit des Berechtigungskonstrukts. Zwar liefert Kubernetes‘ CLI kubectl mit dem Cmdlet auth can-i eine Möglichkeit des Auditings mit (siehe Auflistung aller Berechtigungen des Standard-Adminusers für den Namespace default unten), das Gelbe vom Ei ist dieser Ansatz der Nutzerverwaltung ab einer gewissen Clustergröße nicht mehr.

Oder möchtest du regelmäßig für alle User deines Clusters manuell die Berechtigungen prüfen?

kubectl auth can-i --list --namespace=default
Resources                                       Non-Resource URLs   Resource Names   Verbs
*.*                                             []                  []               [*]
                                                [*]                 []               [*]
selfsubjectaccessreviews.authorization.k8s.io   []                  []               [create]
selfsubjectrulesreviews.authorization.k8s.io    []                  []               [create]
                                                [/api/*]            []               [get]
                                                [/api]              []               [get]
                                                [/apis/*]           []               [get]
                                                [/apis]             []               [get]
                                                [/healthz]          []               [get]
                                                [/healthz]          []               [get]
                                                [/livez]            []               [get]
                                                [/livez]            []               [get]
                                                [/openapi/*]        []               [get]
                                                [/openapi]          []               [get]
                                                [/readyz]           []               [get]
                                                [/readyz]           []               [get]
                                                [/version/]         []               [get]
                                                [/version/]         []               [get]
                                                [/version]          []               [get]
                                                [/version]          []               [get]

 

Eine bessere Verwaltungsmöglichkeit für unsere Kubernetes Cluster User ist also dringend angeraten, sowohl aus Gründen der Übersichtlichkeit als auch der Sicherheit. Bei immer mehr Nutzern und komplexeren Berechtigungsstrukturen ist es sonst nur eine Frage der Zeit, bis bei einem Nutzer die falschen Berechtigungen gesetzt werden. Schaut man sich das Angebot an verfügbaren Lösungen für Zugriffskontrolle auf Kubernetes an, stechen ein paar Projekte heraus:

Als SUSE Partner setzen wir bei mehreren Kunden erfolgreich Rancher ein, ein Open-Source Tool zur ganzheitlichen Verwaltung von Clustern in der Cloud und on premise. Rancher setzt mit seinem Berechtigungskonzept direkt auf Kubernetes‘ RBAC-Modell auf und erweitert es um Projekte, die eine Abstrahierung um einen oder mehrere Namespaces bilden.
Das Web-Frontend bietet die Möglichkeit, (Cluster-)Rollen mit einzelnen Usern oder Usergruppen aus der in Rancher integrierten Benutzerverwaltung zu verknüpfen, zu auditieren und sich einen schnellen Überblick darüber zu verschaffen, welcher User in welchem Cluster welche Berechtigungen hat.

Grundlage für das Berechtigungskonzept sowohl in Rancher’s WebUI als auch in den verwalteten Clustern bieten die vielen verschiedenen Authentifizierungsplugins: Rancher unterstützt LDAP (z.B. Active Directory, OpenLDAP, AzureAD), OAuth (z.B. Google, GitHub), OIDC (z.B. Keycloak) und SAML (z.B. Okta, Shibboleth, ADFS).

Ein weiteres bewährtes Tool zur Zugriffskontrolle für u.A. Kubernetes ist Teleport, das ebenfalls eine Open-Source Software ist und kostenlos genutzt werden kann. Teleport fungiert als vorgelagerter Proxy, der die Anfragen an das Cluster terminiert, den Nutzer authentifiziert und authorisiert und diese Anfragen dann weitergibt. Stärken von Teleport sind zum Beispiel Policy-as-Code, umfangreiche Auditierbarkeit aller Zugriffe und vergangenen Sitzungen sowie die Kompatibilität nicht nur mit Kubernetes, sondern auch anderen gemanagten oder selbst betriebenen Services und Cloudressourcen.

Netzwerkabsicherung bei Kubernetes

Die Zugriffskontrolle für Endnutzer und Serviceaccounts, also handelnde Identitäten, haben wir nun abgearbeitet. Doch wie steht es mit Zugriffsversuchen, die von Services inner- und außerhalb des Clusters stammen und anderweitig beschränkt werden müssen? Schließlich besteht je nach Architektur und genutzten Dritt-Tools selbst ein „leeres“ Cluster aus (bis zu) mehreren hundert Containern, die untereinander kommunizieren (wollen), sich Updates aus dem Internet ziehen oder andere Services innerhalb der Infrastruktur deines Unternehmens (z.B. AD-Server) erreichen müssen.

Per Default können all diese Container das auch erst einmal ungestört. Kubernetes besitzt out-of-the-box kein Konzept einer „Firewall“ oder ähnlicher Maßnahmen, die den Netzwerkverkehr einschränken könnte. Weder in Ost-West, noch in Nord-Süd-Richtung, übrigens. Hierfür bedarf es eines Container Network Interfaces (CNI), das in der Lage ist, NetworkPolicies zu interpretieren und umzusetzen.
NetworkPolicies sind ein natives Konzept der Kubernetes-API, deren Umsetzung aber an externe CNIs übergeben wird. Ohne passendes CNI also keine Einschränkung des Netzwerkverkehrs.

Das Angebot an verfügbaren CNIs ist recht groß, beliebte Lösungen mit Support für NetworkPolicies auf Namespaceebene und teilweise einer ganzen Bandbreite weiterer Features (BGP-Routing, Nodefirewall, Networkpolicies auf Clusterebene) sind bspw. Cilium bzw. Calico.

„Best Practices“ für das Einrichten von Networkpolicies in Kubernetes gibt es wie Sand am Meer. Welche Blaupause für dein Unternehmen sinnvoll und geeignet sein könnte, ist meist eine Einzelfallentscheidung. Ein oft gesehenes Muster ist eine „globale“ NetworkPolicy über alle Namespaces hinweg (das CNI muss dieses Feature mitbringen!), die keinerlei Ingress bzw. Egress bis auf Anfragen an den clusterinternen DNS-Service erlaubt.
Auf diese Weise sperrst du sämtlichen Netzwerkverkehr, der nicht innerhalb eines einzigen Namespaces stattfindet und etablierst ein „Opt-in“-Modell, bei dem die Operatoren der Anwendungen bei Deployment die benötigten Networkpolicies mitdeployen müssen. Einziges Caveat hierbei ist, dass eventuell bereits vorhandene Infrastruktur im Cluster natürlich ebenfalls von den Regelungen betroffen ist.  Es ist deshalb ratsam, dass also ein etwas genauerer Namespace-Filter als „alle Namespaces“ zum Einsatz kommt.

Ressourcenverwaltung in Kubernetes

Ein weiterer wichtiger Punkt neben Zugriffskontrolle und Netzwerkpolicies ist das Verwalten der im Cluster vorhandenen Ressourcen. Der Grund hierfür ist einfach – hat ein Pod die Möglichkeit, alle Ressourcen eines Nodes für sich zu beanspruchen, nimmt er allen anderen Workloads auf diesem Clusternode buchstäblich die Luft zum Atmen. Doch nicht nur „herkömmliche“ Ressourcen wie Arbeitsspeicher und CPUs sollten reguliert sein – auch abstraktere Dinge wie PIDs oder Sockets können zum Problem werden – die in Pods laufenden Container befinden sich schließlich nach wie vor in Namespaces des jeweiligen Nodes. Spielt ein Container verrückt, kann das unangenehme Nachwirkungen für den gesamten Node nach sich ziehen. So kann beispielsweise mit einer Fork Bomb ein Denial of Service (DoS) erreicht werden.

Fälle wie oben beschrieben gilt es natürlich zu unterbinden – für Arbeitsspeicher und CPUs lässt sich das entweder auf Container– oder Namespaceebene umsetzen: Für Container innerhalb eines Pods können unterhalb des Felds resources sowohl requests als auch limits gesetzt werden. Was hier konkret eingetragen werden sollte, um einen möglichst reibungslosen Betrieb bei möglichst kompletter Auslastung eines Nodes durch die dort geschedulten Workloads herzustellen, ist eine seit Jahren diskutierte Frage. Die inzwischen häufigste Antwort lautet:

Für CPUs sollten Requests, aber keine Limits gesetzt werden. Für Arbeitsspeicher sollten Requests==Limits gesetzt werden.

Die Gründe für diese Richtlinie mögen etwas unklar sein, ohne tiefer darauf einzugehen, deswegen verlinke ich an dieser Stelle zwei Blogposts – einen zum Thema CPU-Limits und einen zu Memory-Limits, inklusive lustiger Vergleiche 😉.

An dieser Stelle neben den gängigsten Verwaltungseinstellungen für CPUs und Arbeitsspeicher auf all die anderen zu berücksichtigenden Stellschrauben für sichere Workloads in Kubernetes einzugehen, würde den Rahmen dieses als Überblick gedachten Posts sprengen – deswegen hier nur eine kurze Auflistung einiger Dinge, die man im Hinterkopf behalten sollte:

  • PID Limits für Pods, Nodes und PID-based eviction
  • (un)privilegierte Container
  • Sicherheitskontexte für Container
  • zusätzliche Policies (bspw. Nutzung von ausschließlich signierten Images)
  • Handhabe von Secrets (bspw. Verschlüsselung at rest)

Nodesicherheit sicherstellen

Neben den einzelnen Workloads und Netzwerkverkehr im Cluster muss man natürlich auch die Nodes, aus denen das Cluster besteht, ordentlich absichern. Insbesondere gilt es, die Nodes des Controlplanes, auf denen typischerweise auch etcd mitläuft, abzusichern – Zugriff auf etcd ist gleichzusetzen mit unbegrenztem schreibenden Zugriff auf das Cluster selbst.

Für die Absicherung von Nodes können klassische Technologien wie lokale Firewalls, SELinux oder AppArmor und beliebige weitere Härtungsmaßnahmen zum Einsatz kommen. Doch auch hier gibt es einige Cloud-Native-Technologien, die helfen können:
So unterstützen einige CNIs das Einrichten von Networkpolicies auf Node-Level. Mit nur einem Tool kann also nicht nur Netzwerkverkehr im Cluster reguliert werden, sondern in erweitertem Rahmen auch schon auf den vorgelagerten Nodes selbst.

Darüber hinaus gibt es einige Tools, die in der Lage sind, die komplexen Abläufe, die im Kontext von Kubernetes im Kubelet, den Pods und der Containerlaufzeitumgebung vor sich gehen, zu durchleuchten und ungewünschtes Verhalten zu unterbinden. Oftmals kommt hierbei eBPF zum Einsatz, eine Technologie, die die modulare Erweiterung des Betriebssystemkernels mit kleinen Programmen ermöglicht.

Anwendungssicherheit erhöhen

Ist das Cluster erst einmal abgesichert, kann man sich den darauf betriebenen Anwendungen widmen – auch wenn einige Mechanismen aus dem vorherigen Abschnitt bereits greifen sollten, beispielsweise Netzwerkpolicies und Ressourcenverwaltung.
Damit ist es jedoch in vielen Organisationen nicht getan – vielleicht gibt es Richtlinien, welche Images genutzt werden dürfen, aus welchen Registries sie bezogen werden sollen, ob gewisse Scans laufen müssen oder ob gewisse Signaturen erforderlich sind. Und übrigens dürfen auch anfangs grob geschätzte Ressourcenlimits anhand der tatsächlichen Leistungsdaten angepasst werden 😉.

Für viele dieser Zwecke gibt es Werkzeuge, die das Einrichten individueller Policies im Cluster ermöglichen. Die am weitesten verbreiteten sind zum Einen der Open Policy Agent und zum Anderen Kubewarden. Mit solchen Tools lassen sich verschiedenste Policies entsprechend den Vorgaben eurer Organisationen und Prozesse definieren die -as-Code vorliegen, versioniert und deployed werden können.

Für das Scannen von Workloads und deren Konfiguration gibt es ebenfalls etablierte Lösungen zum Beispiel Trivy oder Kubescape.
Beide Lösungen ermöglichen die Integration von CI/CD-Pipelines, um Sicherheitsrisiken und Misskonfigurationen noch vor Deployment zu bemerken und darauf reagieren zu können.
Trivy bietet darüber hinaus einen Operator, der in regelmäßigen Abständen aus dem Cluster herausselbstständig nach Sicherheitslücken suchen kann.

Für das Finetuning von Ressourcenrequests oder -limits benötigst du hingegen in erster Linie Metriken. Diese können aus verschiedenen Quellen stammen, die sich unter dem Begriff Observability zusammenfassen lassen. Mit Hilfe von Prometheus können so zum Beispiel Performancedaten wie genutzter Arbeitsspeicher, CPU-Last, Netzwerkverkehr auf Anwendungsebene nachvollzogen werden, sofern die Anwendung entsprechend instrumentalisiert wurde.
Mithilfe dieser Daten lassen sich dann Rückschlüsse ziehen ob wir mit unseren initial gewählten Ressourcerequests/limits zu großzügig oder doch eher zu optimistisch umgegangen sind und nun nachbessern.

Ein weiteres Tool zur Erkennung von zu lockeren oder fehlenden Ressourcerequests/limits ist KRR (Kubernetes Resource Recommender), das ebenfalls anhand von Prometheus-Daten die bestehenden Konfigurationen für Pods analysiert und Verbesserungen vorschlägt.

Zu voll umfänglicher Anwendungssicherheit gehört jedoch auch die Absicherung und Überwachung der CI/CD-Pipeline mit der die Anwendung erstellt bzw. ausgeliefert wird. Hier empfiehlt sich die Orientierung an Frameworks wie SLSA (Supplychain Levels for Software Artifacts), eine von Google veröffentlichte Sammlung an Empfehlungen für Software-Entwickler, wie und wo sie ihre Anwendungen härten sollten.
Zusätzlich lassen sich Anwendungen auch im Betrieb in Kubernetes (automatisiert) überwachen. So erlauben Tools wie NeuVector, in Containern ausgeführte Prozesse und versuchte/erfolgte Netzwerkaufrufe zu protokollieren, gewünschtes Verhalten zu „erlernen“ und nicht vorgesehene Aufrufe in Echtzeit zu unterbinden.

Fazit

Am Ende eines weiteren Blogposts in unserer „Kubernetes 101“ Reihe angekommen stellen wir einmal mehr fest: Kubernetes ist komplex.

Eine Vielzahl an Tools können in Sachen Security in Betracht gezogen haben und welcher „Stack“ letzten Endes für eure Anforderungen ausreichend und passend ist muss sich oft erst einmal herausstellen. Nicht zur Diskussion steht, dass eben aufgrund dieser Komplexität eine voll umfängliche Absicherung des Clusters als Plattform und der darin laufenden Anwendungen (ab dem Moment ihrer Entwicklung) oberste Priorität haben sollte. Denn ist erst einmal „der Wurm drin“ kann es ansonsten schwierig werden, Sicherheitslücken klar zu benennen, „den Schuldigen“ zu finden und das Ausmaß der Kompromittierung einzuschätzen.

Sollte dir dieser Blogpost gefallen haben, schau doch gerne noch die anderen in dieser Serie erschienenen Artikel an.
Und solltest du auf den Geschmack gekommen sein, aber an manchen Stellen noch Hilfe in Sachen Kubernetes brauchen, schau entweder einmal bei unseren Trainings zum Einstieg in Kubernetes vorbei oder buche direkt Consulting zu (fast) Allem rund um Kubernetes bei mir oder meinen Kolleg:innen.

Daniel Bodky
Daniel Bodky
Consultant

Daniel kam nach Abschluss seines Studiums im Oktober 2021 zu NETWAYS und berät nun Kunden zu den Themen Icinga2 und Kubernetes. 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.

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

This entry is part 2 of 6 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
Consultant

Daniel kam nach Abschluss seines Studiums im Oktober 2021 zu NETWAYS und berät nun Kunden zu den Themen Icinga2 und Kubernetes. 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.

NWS-ID for your Managed Kubernetes!

First Cloud, now Kubernetes – the integration of NWS-ID with our portfolio continues! As a next step, we will merge your Managed Kubernetes clusters with NWS-ID. Credit goes to Justin for extending our cluster stack with OpenID-Connect (OIDC), the base for NWS-ID!

How can you use your Kubernetes Cluster with NWS-ID?

All you need is kubelogin, a plugin for kubectl, and a customized kubeconfig, which can be downloaded in the NWS Customer Interface. But: this applies to newly started clusters only. Older installations need some action from you! Let’s go and see, what other scenarios there are!

If you have a cluster running with a Kubernetes v1.23 or greater, just enable NWS-ID in the Customer Interface. This will restart the kube-apiserver with some new parameters which will authenticate your requests against NWS-ID using OpenID-Connect.

For clusters in version v1.22 or less you need to update your cluster at least to v1.23 and enable NWS-ID in the Customer Interface. After your cluster is ready for NWS-ID you need to pimp your kubectl for OpenID-Connect.

kubectl and kubelogin

kubelogin is a plugin for kubectl, which enables authentication via OIDC. It is easily installed with brew, krew, choco or Github Releases as described in the official documentation. After the installation, just download your kubeconfig for NWS-ID from the Customer Interface and start using kubectl as usual!

If you have multiple Managed Kubernetes clusters it is easy to switch the context with kubectl config use-context MyCluster.

Permissions and Roles

If you’re not an admin in your organization, they must authorize your NWS-ID. This happens as usual in the user group management in the Customer Interface. As admin you can grant two different roles to your colleagues. Choose between admin and reader which will be mapped the to corresponding Kubernetes cluster role.

If you need some more detailed help, just have a look into our docs for User and Groups and Permissons.

What are the advantages of integrating our Managed Kubernetes with NWS-ID?

Combining these two services makes your daily work easier, because now you can:

  1. use a single login for the NWS Customer Interface, the Cloud Interface and your Kubernetes clusters
  2. effortless switch between your Managed Kubernetes clusters with a single kubeconfig
  3. use two-factor authentication for your Kubernetes clusters
  4. authorise your colleagues to access your clusters in the NWS-ID group management

What happens to the existing certificate authentication?

The authentication with the X509 client certificate is still available for everybody with the appropriate permissions in your organization.

 

Thanks again to Justin for expanding our Kubernetes stack! If you have any questions along the way, please feel free to contact us – we’re always there to help answer any open questions.

Achim Ledermüller
Achim Ledermüller
Senior Manager Cloud

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.

Sommer, Sonne, Software – Rückblick CIVO NAVIGATE 2023

Anfang Februar durfte ich nach Tampa, Florida reisen, um auf der IT-Konferenz Civo Navigate zu sprechen, die in diesem Rahmen zum ersten Mal stattfand. Mit Beiträgen rund um Kubernetes, Edge Computing, Machine Learning, DevOps, GitOps, Observability, Security und Cloud Native Transformation war das Angebot an Themen breit gefächert. Sicherlich vor allem aus diesem Grund (und nicht nur wegen Temperaturen bis zu 30 Grad und toller Location) fanden sich zusätzlich zu 50 angekündigten Speakern, u. a. von ARM, GitLab, oder SUSE auch ca. 300-350 Teilnehmer vom 7.-8. Februar in Tampa ein.

Eingeleitet wurde die Konferenz durch einen Keynote-Block auf der Main Stage, wo nach einem Grußwort von Civo’s CEO Mark Boost ein ca. einstündiger Schwenk aus Steve Wozniak’s Leben folgte für viele Besucher bereits das erste Highlight. Im Anschluss ging es dann los mit den verschiedenen Beiträgen, vorgetragen auf drei separaten Tracks – zwei für klassische Talks und einer für praxisbezogenere Workshops. Für mich hieß es direkt ‚Showtime!‘, ich hatte den ersten Slot auf dem Workshop-Track erwischt, wo ich eine einstündige Einführung in Acorn gab.

Kubernetes-Deployments einfacher gestalten!

Acorn ist ein Tool in erster Linie für Entwickler, die ihre Anwendungen in ihre Kubernetes-Cluster deployen möchten, ohne direkt allzu tief in Kubernetes als Framework einsteigen zu wollen. Mein Kollege Markus hatte Acorn vor Kurzem bereits in seinem Blogpost über Application Management in Kubernetes erwähnt, und ich hatte nun die Gelegenheit, einem interessierten Publikum von ca. 20 Teilnehmern die Software näher zu bringen. Ziel des Workshops war es, eine Gästebuch-Anwendung von einem Docker-basierten Deployment mithilfe von Acorn auf Kubernetes umzustellen. Die Folien zu meinem Workshop finden sich unter slides.dbokdy.me, und in Kombination mit den Workshop-Unterlagen auf GitHub könnt ihr den Workshop bei Interesse auch daheim durchgehen. 😉

Auf den erfolgreichen Workshop folgte analog zu Markus‘ Blogartikel eine angeregte Diskussion, welche Tools für Application/Deploy Management auf Kubernetes denn nun am geeignetsten seien. Darauf gibt es natürlich keine eindeutige Antwort, geschweige denn eine Patentlösung, aber im Laufe der Gespräche wurden immer wieder Epinio, entwickelt von SUSE, und Namespace von Namespace Labs genannt – zu Epinio gab es am Folgetag sogar einen weiteren Workshop. Persönlich habe ich mir bisher keine der beiden Lösungen angeschaut, werde das aber nun schleunigst nachholen, und wer weiß, evtl. folgt ja demnächst ein weiterer Blogpost. Die Nachfrage nach Möglichkeiten, Kubernetes und seine Bedienung für den alltäglichen Gebrauch zu abstrahieren, ist auf Entwicklerseite allem Anschein nach auf jeden Fall vorhanden.

GitOps, Security und KI

Im Anschluss hatte ich jedenfalls gut lachen – zwei Stunden nach Konferenzbeginn war ich bereits „nur noch Teilnehmer“ und konnte nach Lust und Laune verschiedene andere Talks besuchen, mich mit interessierten Teilnehmern unterhalten und die sommerlichen Temperaturen von bis zu 30 Grad genießen. Für mich war interessant zu sehen, in welche Schwerpunkte sich der Großteil der Beiträge würde einordnen lassen, und für mich stachen dabei zwei Dinge heraus – GitOps und Absicherung von Kubernetes-Clustern. Zu diesen Themen gab es einige interessante Talks, angefangen bei Best Practice Sammlungen zu GitOps und Tools, die eine Kombination von GitOps und ClickOps ermöglichen, bis hin zum Einsatz von Service Meshes in Kubernetes zur Absicherung von Netzwerkverkehr in Kubernetes-Clustern.

Auch ein sehr interessanter Beitrag über das Hacken von Kubernetes-Clustern war im Programm enthalten, sodass man sich dem Thema „Sicherheit“ auch einmal aus Sicht des Angreifers widmen konnte. Doch auch andere Themen fanden Beachtung – so gab es nicht nur einige Beiträge zu den Themen ML/AI auf Kubernetes und Edge Computing, der Veranstalter Civo stellte im Rahmen seiner Konferenz auch neue Produkte in diesen Bereichen vor, was beispielhaft für die momentanen Trends rund um „Cloud Native“ und Kubernetes gesehen werden kann.

See you later, alligator!

Größter Pluspunkt der Konferenz als Ganzes waren für mich definitiv die Workshops, die durchgängig im Ablauf zu finden waren – so konnte man seinen persönlichen Talk-Marathon über 48 Stunden zwischendurch immer mal wieder mit praktischeren Fingerübungen und Case Studies auflockern und nebenbei noch sein bestehendes Wissen zu bestimmten Tools aufbessern oder komplett neu erwerben. Das nächste Mal stattfinden wird Civo Navigate im September 2023 in London, und wer weiß, evtl. werde ich euch auch dann wieder von meinem Beitrag und der Konferenz allgemein berichten dürfen.

Daniel Bodky
Daniel Bodky
Consultant

Daniel kam nach Abschluss seines Studiums im Oktober 2021 zu NETWAYS und berät nun Kunden zu den Themen Icinga2 und Kubernetes. 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.

Announcing Kubernetes v1.24 and v1.25

We’d finally like to announce the release of Kubernetes v1.24 and v1.25 on our Kubernetes Platform. Since 1.24 brought many under the hood changes, our deployment process had to be refactored as well. While Version 1.24 and 1.25 were available on our platform for some time now, we can now safely say that both versions are completely stable and safe to use. For the various changes coming with the new version we recommend creating a test cluster to test your applications. But what are these big changes? Let’s go through some of the highlights.

Deprecation of the docker shim

Easily the biggest change is the deprecation of the docker shim that broke our current deployment method where every component and workload runs in Docker containers. But with this release the docker integration is no more. Kubernetes now officially only supports Container Runtimes implementing the CRI specification. Container Runtimes that implement said spec would be Containerd, CRI-O, Kata and gVisor for example.

Since Containerd is the most common runtime, we settled for it. Even though docker internally uses Containerd, the migration was pretty tricky, as it involved installing and configuring Containerd, as well as making sure that Kubernetes uses it. Finally when kubelet restarts, all containers will be recreated.

Containerd

We initially thought Containerd would behave exactly like docker since Containerd runs the docker containers after all. But for one reason or another that is not the case. Through the CRI interface the containers get created based on a CRI-spec. Unfortunately, the default configuration of Containerd does not set the ulimit properly, which results in some application working and others will be killed by the OOMKiller. It turns out that some application try to check the ulimit by „trial and error“ and since the limit is set too high, the kernel will eventually kill the respective process. Weirdly enough, almost exclusively older applications were effected. For example mysql:8 would work fine, but mysql:5.7 will crash almost instantly. The same problem can be observed with the nfs-server-provisioner and rabbitmq for example.

API Deprecations

Like with any other Kubernetes release, there were a lot of API deprecations that needed us to move the Flannel CNI and other deployments to a new release gracefully. The official Kubernetes Blog has a great write-up on this topic.

Configuration

Another problem we faced is the change in configuration. The core Kubernetes component kubelet now only supports being configured with a special configuration file, which in turn meant that we had to rebuild the configuration from scratch, as all of our configuration involved command line flags that now no longer work. CoreDNS as well had some new configuration options helping to conquer overloading the pod with many concurrent DNS queries. We even support adding new static host entries in CoreDNS. The ConfigMap coredns-extra-hosts sets the entries. This entry hosts.list is empty by default, but can the modified like any other hosts file ( 1.2.3.4 example.com ). After restarting the coredns deployment the host can be queried.

Deprecation of PodSecurityPolicy

PodSecurityPolicies have been deprecated since 1.21. But since 1.24 is the last release with it still active, it’s the last chance to get started with PodSecurityAdmission. However, they don’t provide the same feature set, as it enforces the policy based on 3 Pod Security Standards namespace wide. This means, in order to get the same and even more features solutions like OPA Gatekeeper or Kyverno have to be implemented.

ServiceAccount Tokens

Another noteworthy change is the changed behaviour in token creation. Until now, every ServiceAccount automatically gets a new secret including a token to access the Kubernetes api. This is no longer the case. If you need to create a token, make sure to use the kubectl create token command instead.

Happy upgrading!

Justin Lamp
Justin Lamp
Systems Engineer

Justin hat 2022 die Ausbildung zum Fachinformatiker für Systemintegration im "echten" Norden abgeschlossen. Durch seine große Verbundundenheit zu Open Source hat er aber schnell gemerkt, dass ihm Themen im Kubernetes und OpenStack Bereich mehr liegen als im propreritären Microsoft/ VMWare Umfeld. So hat er beschlossen den Schritt zu wagen und andere Teile Deutschlands zu erkunden, um NETWAYS im Team Web Services tatkräftig zu unterstützen. Wenn er nicht in den Untiefen des Linux-Universum unterwegs ist, macht er leidenschaftlich Leichtathletik, geht Wandern und Mountainbiking.