Im Rahmen eines Integrationsprojekts von Kubernetes und Vault (bzw. OpenBao ) sollten Secrets aus Vault in Kubernetes bereitgestellt werden. Dabei sollten die verschiedenen direkten Vault Integrationen durch Infrastruktur in Kubernetes abgelöst werden, und die Vault Secrets als Kubernetes Secrets im Cluster verfügbar gemacht werden, um diese dann als Volume oder Umgebungsvariablen bereitzustellen. Damit soll zum einen das Token-Zero-Problem addressiert werden, also wenn Vault zur Verwaltung von Geheimnissen dient, wie werden die Anwendungen mit einem Geheimnis zur Authentifizierung am Vault versorgt, als auch die individuelle Vault Anbindung der verschiedenen Programmiersprachen und Frameworks.

Vault bietet mit dem Vault Secrets Operator auch direkt eine Integration an, die auf unterschiedliche Weise die Authentifizierung gegenüber Vault umsetzt, als auch für das Mapping der Vault Secrets. Ziel war jedoch nicht nur, ein entsprechendes Setup zu implementieren, sondern eine automatisierte Testbarkeit herzustellen. Dazu wird ein stabiles, reproduzierbares Setup benötigt, um die Kubernetes-Vault-Integration jederzeit in der CI Umgebung frisch herzustellen.

In dem Zuge wurde ein Verfahren benötigt, JWK (JSON Web Keys) im PEM Format bereitzustellen - und das am besten automatisiert durch ein einfaches Shell Script z.B. mit der Bash. Eine Umsetzung auf Basis von Kubernetes OIDC JWKS in PEM formatiertes Material zu erhalten wird im folgenden beschrieben.

Die Absicherung von HTTP Zugriffen mittels TLS (früher SSL) ist spätestens seit den Enthüllungen von Edward Snowden auch für Anwendungen außerhalb von Banken und Medizin zum Standard geworden. Vor allem Dank des kostenlos nutzbaren Let’s Encrypt sind auch die - früher teils horrenden - Kosten kein Grund mehr, auf TLS zu verzichten.
Die meisten Zertifikatanbieter, die das durch Let’s Encrypt eingeführte ACME Protokoll unterstützen, bieten bei Verwendung der DNS Challenge auch Wildcard Zertifikate an. Wird für einen Kubernetes Cluster primär mit Hostnamen in einer Domain oder Subdomain gearbeitet, so bietet sich ein Wildcard Zertifikat entsprechend an. Damit kann unter Umständen sogar der Einsatz des häufig zusätzlich zur Ingress Implementierung betriebenen Cert Manager entfallen: Dazu würde das Wildcard-Zertifikat als Default TLS Zertifikat im Ingress Controller konfiguriert werden/

Wie das funktioniert, wird im folgenden Beitrag beschrieben.

Die W-JAX 2024 findet vom 4. bis 8. November 2024 in München statt. Das trion-Team ist vor Ort und bietet eine Vielzahl von Vorträgen sowie eine interaktive Night-Session an. Diese Formate ermöglichen es den Teilnehmenden, tief in technologische und architektonische Themen einzutauchen und anregende Diskussionen zu führen.

Supply Chain Security spielt auch im Container Umfeld eine immer wichtigere Rolle. Es gilt dabei die Sicherheit im Sinne von Echtheit und Integrität der (Docker) Images abzusichern.
Typische Supply Chain Angriffsszenarien bei Kubernetes, Docker...

Gerade für die Entwicklung und zum Testen bietet es sich im Kontext von Kubernetes an, auch eine lokale Umgebung zur Verfügung zu haben. Seit Docker Desktop für Firmen lizenzpflichtig geworden ist, ist diese Option weniger oft anzutreffen. Dabei sind nicht unbedingt die Kosten der entscheidende Faktor, sondern die mit der Beschaffung verbundene Komplexität und Aufwände.

Stattdessen bietet sich als Alternative an, mit der WSL zu arbeiten. Mit Ubuntu kommt auch eine leicht einzurichtende Kubernetest Distribution von Canonical mit: Microk8s. Microk8s bietet vergleichbar mit Minikube auch die Integration von verschiedene Addons um zum Beispiel einen Ingress einfach bereitzustellen.

Da Microk8s innerhalb der WSL läuft, ist die Integration nicht ganz so nahtlos, wie dies bei Docker Desktop gelungen ist. Wir werfen im folgenden einen Blick darauf, welche Optionen es gibt, auf den Microk8s bzw. Dienste zuzugreifen. Im Fokus steht dabei vor allem der Ingress, wird dieser schließlich auch sonst typischerweise für den Zugriff auf HTTP Dienste und Webanwendungen genutzt.

Container Image sind dank OCI Standard und Verbreitung von Docker und Kubernetes zu dem Mittel der Wahl geworden, um Anwendungen zu verteilen. Dabei verwenden Container Runtimes wie Docker ein geschicktes Verfahren zur Deduplizierung von Daten: Ein Container Image ist in Layer aufgeteilt und diese können unabhängig voneinander verteilt und gespeichert werden.
Da die Layer selbst nicht veränderlich sind, können Layer wiederverwendet werden.

Typischerweise finden sich auch viele Gemeinsamkeiten: Die verwendete Basisdistribution, Laufzeitumgebungen wie Python oder Java und ggf. auch firmenspezifische Konfigurationen wie TLS Zertifikate.

Dabei muss ein Tradeoff beachtet werden: Je mehr Layer, desto mehr Overhead entsteht durch sie. Gleichzeitig ist es um so wahrscheinlicher, dass bei feingranularen Image Layern eine gute Wiederverwendbarkeit ermöglicht wird.

Bei der Auswahl von Base-Images, auf die eigene Anwendungsimages aufgebaut werden sollen, gilt es also darauf zu achten, dass diese möglichst geschickt augeteilt sind und nicht nur aus einem Layer bestehen, der stets vollständig neu geladen und gespeichert werden muss, wenn es Aktualisierungen gibt, aber auch nicht aus zehn oder mehr Layern.

Zur Bestimmung der Anzahl der Layer gibt es verschiedene Ansätze. Am Beispiel eines Java Basisimages, openjdk, werden diese im folgenden betrachtet.

Container Images sind inzwischen etabliert, um darüber Anwendungen bereitzustellen. Durch das standardisierte Format, einheitliche Schnittstellen und das insgesamt bestehende Ökosystem wird es sehr einfach, Artefakte zu konsumieren und auch bereitzustellen. Jedoch hat das auch Konsequenzen: Die Verantwortung für Patchmanagement, Fehlerbehebungen und Security-Updates verschiebt sich zum Anbieter der jeweiligen Images, da diese mehr, als lediglich die Anwendung selbst beinhalten. Gleichzeitig obligt es dem Konsumenten bzw. Nutzer der Images, sicherzustellen, dass diese aus einer vertrauenswürdigen Quelle stammen und auch nicht zwischendurch verändert wurden.
Diese Aspekte der "Supply-Chain-Security", einem Unterbereich der IT-Sicherheit im Kontext von Containeranwendungen wollen wir uns in diesem und folgenden Artikel widmen.

Die JAX 2024 steht vor der Tür und das Team von trion ist bereits in den Startlöchern, um Wissen und Erfahrung zu teilen. Mit einer breiten Palette von Vorträgen und einem interaktiven Night-Session-Format bietet trion Teilnehmern die Möglichkeit, sowohl in Bezug auf Technologie als auch Architektur in spannende Bereiche einzutauchen und tiefgehende Diskussionen zu führen.

In einer Welt, in der technologische Innovationen das Tempo vorgeben, ist es entscheidend, stets auf dem neuesten Stand zu bleiben und aus erster Hand von den Besten zu lernen. Diesen Monat haben wir bei trion einen besonderen Grund zum Feiern: Drei unserer Top-Experten, Thomas Kruse, Karsten Sitterberg und Stefan Reuter, haben im Java Magazin einen bemerkenswerten Schwerpunkt gesetzt. Ihre Beiträge reflektieren nicht nur ihr tiefgreifendes Verständnis für moderne Softwareentwicklung, sondern bieten auch praxisnahe Lösungen für aktuelle und zukünftige Herausforderungen.

Im Beitrag Crossplane Tutorial wurde Crossplane als Werkzeug zur Infrastrukturautomatisierung vorgestellt. In diesem Beitrag wird der Einsatz von Crossplane für die Hetzner Cloud gezeigt. Dabei wird auch betrachtet, wie neue Provider für Crossplane durch Wiederverwendung bestehender Terraform Plugins bereitgestellt werden können.

Im DevOps Kontext haben sich über die Zeit verschiedene Werkzeuge entwickelt:
Waren Puppet und Chef noch frühe Vertreter mit unterschiedlichen Paradigmen (deklarativ vs. imperativ) verwendeten doch beide einen Agent. Ansible setzte sich weitgehend als imperative Lösung ohne Agent für die Provisionierung von Systemen durch, während Terraform als Infrastruktur- und Cloudwerkzeug de-factor Standard wurde.
Sowohl Ansible als auch Puppet setzen auf eine Konfiguration, die nahe an typischen Datenformaten von APIs sind (YAML bzw. JSON).

In diesem Beitrag soll es um ein neuartiges Werkzeug gehen, dass den deklarativen Ansatz verfolgt, jedoch die Kubernetes API als Schnittstelle verwendet. Crossplane geht damit einen spannenden Weg und erlaubt es, bestehende Verfahren zur Authentifizierung und Autorisierung weiter zu nutzen und sich dank zahlreicher Kubernetes Libraries auch einfach an eigene oder bestehende Anwendungen zu integrieren. Dies ermöglicht eine konsistente Verwaltung von (Cloud-)Ressourcen und Kubernetes-Workloads. Crossplane bietet somit eine engere Integration zwischen Anwendungen und Infrastruktur, was die Automatisierung und das Management vereinfacht.

Dies wird dank der erweiterbaren API von Kubernetes möglch: Alle Crossplane Ressourcen sind Custom Resource Definitions (CRDs) in Kubernetes. Die Erweiterung von Crossplane ist durch die erweiterbare API von Kubernetes ebenfalls gegeben, so können sogenannte Provider nachgerüstet werden. Dazu können vorhandene Kubernetes Konzepte wie ConfigMaps oder Secrets verwendet werden.

Aus diesem Ansatz ergeben sich folgende Vorteile von Crossplane:

Crossplane benötigt jedoch einen Kubernetes API Server als Basisinfrastruktur. Im folgenden schauen wir uns die Installation und Verwendung von Crossplane genauer an.

Die DevOpsCon ist eine internationale Konferenz für IT-Experten und Enthusiasten, wie wir, die sich für DevOps und agile Arbeitsweisen interessieren.

Die Konferenz bietet ein umfangreiches Programm mit Vorträgen, Workshops und Diskussionsrunden...