Gerade für Experimente und zur Entwicklung bietet sich ein lokaler Kubernetes Cluster an. Zur einfachen Umsetzung gibt es diverse Optionen wie Minikube, KinD oder auch k3s. Auch wir setzen in unseren Kubernetes Schulungen gerne auf ein Cluster Setup, dass durch die Teilnehmer mit geringem Aufwand auf dem eigenen System verwendet werden kann, um auch nach der Schulung eigenständig weiter zu lernen und Übungen nachzuvollziehen.

Wie geht man jedoch bei so einem Setup mit dem Thema TLS Zertifikaten um?
Umgehen ist nicht immer ein praktikabler Weg: Manche Browser APIs, wie zum Beispiel der Zugriff auf die Webcam erfordern schlicht den Einsatz von TLS.

Speziell für diesen Anwendungsfall bietet traefik.me eine Domain, Wildcard-DNS Service und ein durch Let’s Encrypt validiertes Zertifikat an. Dieser Beitrag zeigt die Verwendung von traefik.me in Kombination mit Kubernetes.

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.

Kubernetes eignet sich hervorragend auch für kleine Setups, z.B. in einem Homelab, und auch bei begrenzten Hardwareressourcen. Dafür gibt es beispielsweise besonders schlanke Distributionen wie k3s.
Der immense Vorteil von Kubernetes liegt in den bereitgestellten APIs und der sehr einfachen Möglichkeit, alle Konfigurationen deklarativ zu verwalten.

Um Kubernetes als gute Plattform auch für Homelab Anwendungen zu demonstrieren geht es in diesem Beitrag darum, wie der Werbeblocker Pi-Hole auf Kubernetes betrieben werden könnte.

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...

Dokumentation ist ein Thema, dass gerne hinten angestellt wird.
Quasi "wenn noch Zeit ist". Vergleichbar mit Tests wird Dokumentation von manchen Personen als schlecht investierte Zeit angesehen. Erschwerend kommt hinzu, dass die Pflege aufwendig ist: Wird die Software weiterentwickelt, so müssen oft auch Tests und Dokumentation nachgezogen werden.

Wir haben gute Erfahrungen damit gemacht, Dokumentation - wo möglich - zu generieren. Dabei kann sowohl der Java Quellcode als Quelle dienen, als auch Ergebnisse von automatisiert ausgeführten Tests.
Auf diese Weise kann die Dokumentation nah am Quellcode mitgepflegt werden, die Wahrscheinlichkeit sinkt, dass dies nicht bedacht oder vergessen wird.

In diesem Beitrag geht es darum, auch die Dokumentation der verwendeten Datenbankschemata zu dokumentieren. Dazu werden die Werkzeuge Testcontainers, Schemacrawler und JUnit miteinander verknüpft.

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.

Durch CSP Header (Content Security Policy) lassen sich verschiedene Funktionen des Webbrowsers konfigurieren, um das Verhalten von Nachladen und auch Ausführen zusätzlicher oder dynamischer Inhalte zu beeinflussen. Damit lassen sich typische Einfallstore für Angriffe wie Cross-Site-Scripting (XSS) wirksam abstellen.
Ist die Webanwendung jedoch eine Single Page Anwendung (SPA) und auf dynamische Erzeugung von Inhalten angewiesen, führt eine globale Deaktivierung der Dynamik dazu, dass die Anwendung nicht mehr funktioniert. Es stellt sich daher die Frage, wie zwischen guten und potentiell schädlichen externen und dynamischen Inhalten unterschieden werden kann.

Dazu ist in allen Browsern inzwischen ein Verfahren implementiert, mit dem Entwickler solche Inhalte, die erwünscht sind, expliziert markieren können: sogenannte "Nonce" Markierungen. Aktuelle Frameworks, so auch Angular, bringen dazu auch speziellen Support mit.
Die Implementierung wird in diesem Beitrag anhand von nginx gezeigt.

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.

Für Product Owner, Entwickler und weitere Stakeholder können Bildschirmaufnahmen hilfreich sein, um schnell und einfach einen Einblick in den Entwicklungsstand einer Webanwendung zu erlagen. In diesem Post berichte ich von meinen Erfahrungen, einen Prozess aufzusetzen, um in einer Build-Pipeline automatisch Videos und Screenshots einer Anwendung aufzunehmen und diese bereitzustellen. Realisiert habe ich dieses Vorhaben sowohl mit Playwright als auch mit Puppeteer.

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.

Heutzutage ist es wichtiger denn je, dass Anwendungen auf verschiedenen Architekturen und Plattformen reibungslos funktionieren. Man denke z.B. an den erfolgreichen Schwenk von Apple auf die ARM-Plattform und die Kosteneffizienz, die ARM auch...

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.